TL;DR: ચાર વર્ષ પહેલાં મેં નવા સર્વર મોનિટરિંગ ટૂલ માટેના વિચાર સાથે Google છોડી દીધું હતું. સામાન્ય રીતે અલગ પડેલા કાર્યોને એક સેવામાં જોડવાનો વિચાર હતો સંગ્રહ અને લોગ વિશ્લેષણ, મેટ્રિક્સ સંગ્રહ, ચેતવણીઓ અને ડેશબોર્ડ. એક સિદ્ધાંત એ છે કે સેવા સાચી હોવી જોઈએ ઝડપી, devops ને સરળ, અરસપરસ, આનંદપ્રદ અનુભવ પ્રદાન કરે છે. આના માટે બજેટની અંદર રહીને સેકન્ડના અપૂર્ણાંકમાં મલ્ટિ-ગીગાબાઈટ ડેટા સેટની પ્રક્રિયા કરવાની જરૂર છે. હાલના લોગ મેનેજમેન્ટ ટૂલ્સ મોટાભાગે ધીમા અને અણઘડ હોય છે, તેથી અમને એક સારી પડકારનો સામનો કરવો પડ્યો હતો: વપરાશકર્તાઓને નવો અનુભવ આપવા માટે એક ટૂલને સ્માર્ટ રીતે ડિઝાઇન કરવું.

આ લેખ વર્ણવે છે કે કેવી રીતે અમે Scalyr ખાતે જૂની શાળા પદ્ધતિઓ, એક બ્રુટ ફોર્સ એપ્રોચ, બિનજરૂરી સ્તરોને દૂર કરીને અને જટિલ ડેટા સ્ટ્રક્ચર્સને ટાળીને આ સમસ્યાને હલ કરી. તમે તમારી પોતાની એન્જિનિયરિંગ સમસ્યાઓ માટે આ પાઠ લાગુ કરી શકો છો.

ઓલ્ડ સ્કૂલ પાવર

લોગ વિશ્લેષણ સામાન્ય રીતે શોધ સાથે શરૂ થાય છે: ચોક્કસ પેટર્ન સાથે મેળ ખાતા બધા સંદેશાઓ શોધો. Scalyr માં, આ ઘણા સર્વર્સમાંથી દસ અથવા સેંકડો ગીગાબાઇટ્સ લોગ છે. આધુનિક અભિગમો, એક નિયમ તરીકે, શોધ માટે ઑપ્ટિમાઇઝ કરેલ કેટલાક જટિલ ડેટા સ્ટ્રક્ચરના નિર્માણનો સમાવેશ કરે છે. મેં ચોક્કસપણે આ Google પર જોયું છે, જ્યાં તેઓ આ પ્રકારની વસ્તુમાં ખૂબ સારા છે. પરંતુ અમે વધુ ક્રૂડર અભિગમ પર સ્થાયી થયા: લોગનું રેખીય સ્કેનિંગ. અને તે કામ કર્યું - અમે એક શોધી શકાય તેવું ઈન્ટરફેસ પ્રદાન કરીએ છીએ જે અમારા સ્પર્ધકો કરતાં વધુ ઝડપથી ઓર્ડર આપે છે (અંતમાં એનિમેશન જુઓ).

મુખ્ય આંતરદૃષ્ટિ એ હતી કે આધુનિક પ્રોસેસર્સ ખરેખર સરળ, સીધી કામગીરીમાં ખૂબ જ ઝડપી છે. જટિલ, મલ્ટિ-લેયર સિસ્ટમ્સમાં આ ચૂકી જવાનું સરળ છે જે I/O સ્પીડ અને નેટવર્ક ઑપરેશન્સ પર આધાર રાખે છે, અને આવી સિસ્ટમો આજે ખૂબ જ સામાન્ય છે. તેથી અમે એક ડિઝાઇન વિકસાવી છે જે સ્તરો અને વધારાના કાટમાળને ઘટાડે છે. બહુવિધ પ્રોસેસર્સ અને સર્વર સમાંતર સાથે, શોધ ઝડપ 1 TB પ્રતિ સેકન્ડ સુધી પહોંચે છે.

આ લેખમાંથી મુખ્ય પગલાં:

• બ્રુટ-ફોર્સ સર્ચ એ વાસ્તવિક-વિશ્વ, મોટા પાયે સમસ્યાઓ ઉકેલવા માટે એક સક્ષમ અભિગમ છે.
• બ્રુટ ફોર્સ એ ડિઝાઇન તકનીક છે, કામ-મુક્ત ઉકેલ નથી. કોઈપણ તકનીકની જેમ, તે અન્ય કરતાં કેટલીક સમસ્યાઓ માટે વધુ સારી રીતે અનુકૂળ છે, અને તેને નબળી અથવા સારી રીતે લાગુ કરી શકાય છે.
• બ્રુટ ફોર્સ હાંસલ કરવા માટે ખાસ કરીને સારું છે સ્થિર ઉત્પાદકતા.
• જડ બળના અસરકારક ઉપયોગ માટે કોડને ઑપ્ટિમાઇઝ કરવાની અને યોગ્ય સમયે પૂરતા સંસાધનોનો ઉપયોગ કરવાની જરૂર છે. જો તમારા સર્વર્સ ભારે બિન-વપરાશકર્તા લોડ હેઠળ હોય અને વપરાશકર્તા કામગીરી અગ્રતા રહે તો તે યોગ્ય છે.
• પ્રદર્શન ફક્ત આંતરિક લૂપ અલ્ગોરિધમ પર નહીં, સમગ્ર સિસ્ટમની ડિઝાઇન પર આધારિત છે.

(આ લેખ મેમરીમાં ડેટા શોધવાનું વર્ણન કરે છે. મોટા ભાગના કિસ્સાઓમાં, જ્યારે વપરાશકર્તા લોગ શોધ કરે છે, ત્યારે Scalyr સર્વર્સ તેને પહેલેથી જ કેશ કરે છે. આગળનો લેખ અનકેશ્ડ લૉગ્સ શોધવાની ચર્ચા કરશે. સમાન સિદ્ધાંતો લાગુ પડે છે: કાર્યક્ષમ કોડ, બ્રુટ ફોર્સ મોટા કોમ્પ્યુટેશનલ સંસાધનો સાથે).

બ્રુટ ફોર્સ પદ્ધતિ

પરંપરાગત રીતે, કીવર્ડ ઇન્ડેક્સનો ઉપયોગ કરીને મોટા ડેટા સેટની શોધ કરવામાં આવે છે. જ્યારે સર્વર લૉગ્સ પર લાગુ કરવામાં આવે છે, ત્યારે તેનો અર્થ લોગમાં દરેક અનન્ય શબ્દની શોધ થાય છે. દરેક શબ્દ માટે, તમારે બધા સમાવેશની સૂચિ બનાવવાની જરૂર છે. આનાથી આ શબ્દ સાથેના તમામ સંદેશાઓ શોધવાનું સરળ બને છે, ઉદાહરણ તરીકે 'એરર', 'ફાયરફોક્સ' અથવા "ટ્રાન્ઝેક્શન_16851951" - ફક્ત અનુક્રમણિકામાં જુઓ.

મેં Google પર આ અભિગમનો ઉપયોગ કર્યો અને તે સારી રીતે કામ કર્યું. પરંતુ Scalyr માં આપણે લોગ બાઈટ બાય બાઈટ શોધીએ છીએ.

શા માટે? અમૂર્ત અલ્ગોરિધમિક દૃષ્ટિકોણથી, કીવર્ડ ઇન્ડેક્સ બ્રુટ ફોર્સ શોધ કરતાં વધુ કાર્યક્ષમ છે. જો કે, અમે અલ્ગોરિધમ્સ વેચતા નથી, અમે પ્રદર્શન વેચીએ છીએ. અને પ્રદર્શન એલ્ગોરિધમ્સ વિશે જ નહીં, પણ સિસ્ટમ એન્જિનિયરિંગ વિશે પણ છે. આપણે બધું ધ્યાનમાં લેવું જોઈએ: ડેટાનું પ્રમાણ, શોધનો પ્રકાર, ઉપલબ્ધ હાર્ડવેર અને સૉફ્ટવેર સંદર્ભ. અમે નક્કી કર્યું કે અમારી ચોક્કસ સમસ્યા માટે, 'ગ્રેપ' જેવું કંઈક ઇન્ડેક્સ કરતાં વધુ યોગ્ય હતું.

સૂચકાંકો મહાન છે, પરંતુ તેમની મર્યાદાઓ છે. એક શબ્દ શોધવા માટે સરળ છે. પરંતુ 'googlebot' અને '404' જેવા બહુવિધ શબ્દોવાળા સંદેશાઓ શોધવાનું વધુ મુશ્કેલ છે. 'અનકેચ અપવાદ' જેવા શબ્દસમૂહની શોધ કરવા માટે વધુ બોજારૂપ અનુક્રમણિકાની જરૂર છે જે ફક્ત તે શબ્દ સાથેના તમામ સંદેશાઓ જ નહીં, પણ શબ્દના ચોક્કસ સ્થાનને પણ રેકોર્ડ કરે છે.

ખરી મુશ્કેલી ત્યારે આવે છે જ્યારે તમે શબ્દો ન શોધી રહ્યા હો. ચાલો કહીએ કે તમે જોવા માંગો છો કે બૉટોથી કેટલો ટ્રાફિક આવે છે. પ્રથમ વિચાર 'બોટ' શબ્દ માટે લોગ શોધવાનો છે. આ રીતે તમને કેટલાક બૉટો મળશે: Googlebot, Bingbot અને અન્ય ઘણા. પણ અહીં 'બોટ' શબ્દ નથી, પણ તેનો એક ભાગ છે. જો આપણે અનુક્રમણિકામાં 'બોટ' શોધીશું, તો અમને 'Googlebot' શબ્દ સાથેની કોઈપણ પોસ્ટ મળશે નહીં. જો તમે અનુક્રમણિકામાંના દરેક શબ્દને તપાસો અને પછી મળેલા કીવર્ડ્સ માટે અનુક્રમણિકા સ્કેન કરો, તો શોધ ખૂબ જ ધીમી થઈ જશે. પરિણામે, કેટલાક લોગ પ્રોગ્રામ્સ આંશિક-શબ્દ શોધને મંજૂરી આપતા નથી અથવા (શ્રેષ્ઠ રીતે) નીચા પ્રદર્શન સાથે વિશિષ્ટ વાક્યરચના કરવાની મંજૂરી આપતા નથી. અમે આને ટાળવા માંગીએ છીએ.

બીજી સમસ્યા વિરામચિહ્ન છે. શું તમે માંથી બધી વિનંતીઓ શોધવા માંગો છો 50.168.29.7? સમાવિષ્ટ લોગ ડીબગીંગ વિશે શું [error]? સબ્સ્ક્રિપ્ટ સામાન્ય રીતે વિરામચિહ્નોને છોડી દે છે.

છેવટે, એન્જિનિયરો શક્તિશાળી સાધનોને પસંદ કરે છે, અને કેટલીકવાર સમસ્યા ફક્ત નિયમિત અભિવ્યક્તિથી જ ઉકેલી શકાય છે. કીવર્ડ ઇન્ડેક્સ આ માટે ખૂબ યોગ્ય નથી.

વધુમાં, સૂચકાંકો જટિલ. દરેક સંદેશને કેટલીક કીવર્ડ સૂચિમાં ઉમેરવાની જરૂર છે. આ યાદીઓ દરેક સમયે સરળતાથી શોધી શકાય તેવા ફોર્મેટમાં રાખવી જોઈએ. શબ્દસમૂહો, શબ્દના ટુકડાઓ અથવા નિયમિત અભિવ્યક્તિઓ સાથેની ક્વેરીઝને બહુ-સૂચિ ઑપરેશન્સમાં અનુવાદિત કરવાની જરૂર છે, અને પરિણામોને સ્કેન કરીને પરિણામ સેટ બનાવવા માટે સંયુક્ત કરવાની જરૂર છે. મોટા પાયે, મલ્ટિ-ટેનન્ટ સેવાના સંદર્ભમાં, આ જટિલતા કામગીરીની સમસ્યાઓ બનાવે છે જે અલ્ગોરિધમ્સનું વિશ્લેષણ કરતી વખતે દેખાતી નથી.

કીવર્ડ ઇન્ડેક્સ પણ ઘણી જગ્યા લે છે, અને લોગ મેનેજમેન્ટ સિસ્ટમમાં સ્ટોરેજ એ મુખ્ય ખર્ચ છે.

બીજી બાજુ, દરેક શોધ ઘણી બધી કમ્પ્યુટિંગ શક્તિનો ઉપયોગ કરી શકે છે. અમારા વપરાશકર્તાઓ અનન્ય ક્વેરીઝ માટે હાઇ-સ્પીડ શોધની પ્રશંસા કરે છે, પરંતુ આવી ક્વેરીઝ પ્રમાણમાં ભાગ્યે જ કરવામાં આવે છે. લાક્ષણિક શોધ પ્રશ્નો માટે, ઉદાહરણ તરીકે, ડેશબોર્ડ માટે, અમે વિશિષ્ટ તકનીકોનો ઉપયોગ કરીએ છીએ (અમે તેનું વર્ણન આગામી લેખમાં કરીશું). અન્ય વિનંતીઓ એટલી ઓછી હોય છે કે તમારે ભાગ્યે જ એક સમયે એક કરતાં વધુ પ્રક્રિયા કરવી પડે છે. પરંતુ આનો અર્થ એ નથી કે અમારા સર્વર્સ વ્યસ્ત નથી: તેઓ નવા સંદેશાઓ પ્રાપ્ત કરવા, વિશ્લેષણ કરવા અને સંકુચિત કરવા, ચેતવણીઓનું મૂલ્યાંકન કરવા, જૂના ડેટાને સંકુચિત કરવા વગેરેમાં વ્યસ્ત છે. આમ, અમારી પાસે પ્રોસેસર્સનો એકદમ નોંધપાત્ર પુરવઠો છે જેનો ઉપયોગ ક્વેરી ચલાવવા માટે થઈ શકે છે.

બ્રુટ ફોર્સ કામ કરે છે જો તમને કોઈ જડ સમસ્યા હોય (અને ઘણું બળ)

બ્રુટ ફોર્સ નાના આંતરિક લૂપ્સ સાથેની સરળ સમસ્યાઓ પર શ્રેષ્ઠ કાર્ય કરે છે. ઘણી વખત તમે ખૂબ જ ઊંચી ઝડપે ચલાવવા માટે આંતરિક લૂપને ઑપ્ટિમાઇઝ કરી શકો છો. જો કોડ જટિલ છે, તો તેને ઑપ્ટિમાઇઝ કરવું વધુ મુશ્કેલ છે.

અમારા શોધ કોડમાં મૂળ રીતે એકદમ મોટી આંતરિક લૂપ હતી. અમે 4K પર પૃષ્ઠો પર સંદેશાઓ સંગ્રહિત કરીએ છીએ; દરેક પૃષ્ઠમાં કેટલાક સંદેશા (UTF-8 માં) અને દરેક સંદેશ માટે મેટાડેટા હોય છે. મેટાડેટા એ એક માળખું છે જે મૂલ્યની લંબાઈ, આંતરિક સંદેશ ID અને અન્ય ક્ષેત્રોને એન્કોડ કરે છે. શોધ ચક્ર આના જેવું દેખાતું હતું:

આ વાસ્તવિક કોડનું એક સરળ સંસ્કરણ છે. પરંતુ અહીં પણ, બહુવિધ ઑબ્જેક્ટ પ્લેસમેન્ટ્સ, ડેટા કૉપિ અને ફંક્શન કૉલ્સ દૃશ્યમાન છે. JVM ફંક્શન કૉલ્સને ઑપ્ટિમાઇઝ કરવા અને ક્ષણિક ઑબ્જેક્ટ્સ ફાળવવામાં ખૂબ સારું છે, તેથી આ કોડ અમે લાયક હતા તેના કરતાં વધુ સારી રીતે કામ કર્યું. પરીક્ષણ દરમિયાન, ગ્રાહકોએ તેનો સફળતાપૂર્વક ઉપયોગ કર્યો. પરંતુ આખરે અમે તેને આગલા સ્તર પર લઈ ગયા.

(તમે પૂછી શકો છો કે શા માટે અમે સીધા લોગ સાથે કામ કરવાને બદલે 4K પૃષ્ઠો, ટેક્સ્ટ અને મેટાડેટા સાથે સંદેશાઓને આ ફોર્મેટમાં સંગ્રહિત કરીએ છીએ. ત્યાં ઘણા કારણો છે, જે એ હકીકત તરફ ઉકળે છે કે આંતરિક રીતે સ્કેલર એન્જિન વધુ વિતરિત ડેટાબેઝ જેવું છે. ફાઇલ સિસ્ટમ. લખાણ શોધને ઘણીવાર લોગ પાર્સિંગ પછી માર્જિનમાં DBMS-શૈલી ફિલ્ટર્સ સાથે જોડવામાં આવે છે. અમે એકસાથે હજારો લૉગ્સ એકસાથે શોધી શકીએ છીએ, અને સરળ ટેક્સ્ટ ફાઇલો અમારા વ્યવહાર, પ્રતિકૃતિ, વિતરિત ડેટા મેનેજમેન્ટ માટે યોગ્ય નથી).

શરૂઆતમાં, એવું લાગતું હતું કે આવા કોડ બ્રુટ ફોર્સ ઑપ્ટિમાઇઝેશન માટે ખૂબ યોગ્ય નથી. "વાસ્તવિક કાર્ય" માં String.indexOf() CPU પ્રોફાઇલ પર પણ પ્રભુત્વ ધરાવતું નથી. એટલે કે, ફક્ત આ પદ્ધતિને ઑપ્ટિમાઇઝ કરવાથી નોંધપાત્ર અસર થશે નહીં.

એવું બને છે કે અમે દરેક પૃષ્ઠની શરૂઆતમાં મેટાડેટા સંગ્રહિત કરીએ છીએ, અને UTF-8 માં તમામ સંદેશાઓનો ટેક્સ્ટ બીજા છેડે પેક કરવામાં આવે છે. આનો લાભ લઈને, અમે આખા પૃષ્ઠને એકસાથે શોધવા માટે લૂપને ફરીથી લખ્યો:

આ સંસ્કરણ સીધું દૃશ્ય પર કામ કરે છે raw byte[] અને સમગ્ર 4K પેજ પર એક સાથે તમામ સંદેશાઓ શોધે છે.

આ જડ બળ પદ્ધતિ માટે ઑપ્ટિમાઇઝ કરવા માટે ખૂબ સરળ છે. આંતરિક શોધ લૂપને દરેક પોસ્ટ પર અલગથી બદલે સમગ્ર 4K પૃષ્ઠ માટે એકસાથે કહેવામાં આવે છે. ડેટાની કોઈ નકલ નથી, ઑબ્જેક્ટ્સની કોઈ ફાળવણી નથી. અને વધુ જટિલ મેટાડેટા ઓપરેશન્સ માત્ર ત્યારે જ બોલાવવામાં આવે છે જ્યારે પરિણામ હકારાત્મક હોય, અને દરેક સંદેશ પર નહીં. આ રીતે અમે એક ટન ઓવરહેડ દૂર કર્યું છે, અને બાકીનો ભાર નાના આંતરિક શોધ લૂપમાં કેન્દ્રિત છે, જે વધુ ઑપ્ટિમાઇઝેશન માટે યોગ્ય છે.

અમારા વાસ્તવિક શોધ અલ્ગોરિધમ પર આધારિત છે લિયોનીડ વોલ્નિટ્સકીનો મહાન વિચાર. તે બોયર-મૂર અલ્ગોરિધમ જેવું જ છે, દરેક પગલા પર શોધ સ્ટ્રીંગની લગભગ લંબાઈને છોડીને. મુખ્ય તફાવત એ છે કે તે ખોટા મેચોને ઘટાડવા માટે એક સમયે બે બાઇટ્સ તપાસે છે.

અમારા અમલીકરણ માટે દરેક શોધ માટે 64K લુકઅપ ટેબલ બનાવવાની જરૂર છે, પરંતુ અમે જે ગીગાબાઇટ્સ દ્વારા શોધી રહ્યા છીએ તેની સરખામણીમાં તે કંઈ નથી. આંતરિક લૂપ એક કોર પર સેકન્ડ દીઠ કેટલાક ગીગાબાઇટ્સ પ્રક્રિયા કરે છે. વ્યવહારમાં, દરેક કોર પર સ્થિર પ્રદર્શન લગભગ 1,25 GB પ્રતિ સેકન્ડ છે, અને તેમાં સુધારા માટે અવકાશ છે. આંતરિક લૂપની બહારના કેટલાક ઓવરહેડને દૂર કરવું શક્ય છે, અને અમે Java ને બદલે C માં આંતરિક લૂપ સાથે પ્રયોગ કરવાની યોજના બનાવીએ છીએ.

અમે બળનો ઉપયોગ કરીએ છીએ

અમે ચર્ચા કરી છે કે લોગ સર્ચિંગ "આશરે" અમલમાં મૂકી શકાય છે, પરંતુ અમારી પાસે કેટલી "શક્તિ" છે? તદ્દન ઘણો.

1 કોર: જ્યારે યોગ્ય રીતે ઉપયોગ થાય છે, ત્યારે આધુનિક પ્રોસેસરનો એક કોર તેની પોતાની રીતે ખૂબ શક્તિશાળી હોય છે.

8 કોરો: અમે હાલમાં એમેઝોન hi1.4xlarge અને i2.4xlarge SSD સર્વર્સ પર ચાલી રહ્યા છીએ, દરેક 8 કોરો (16 થ્રેડો) સાથે. ઉપર જણાવ્યા મુજબ, આ કોરો સામાન્ય રીતે પૃષ્ઠભૂમિ કામગીરીમાં વ્યસ્ત હોય છે. જ્યારે વપરાશકર્તા શોધ કરે છે, ત્યારે પૃષ્ઠભૂમિ કામગીરી સસ્પેન્ડ કરવામાં આવે છે, શોધ માટે તમામ 8 કોરોને મુક્ત કરે છે. શોધ સામાન્ય રીતે વિભાજિત સેકન્ડમાં પૂર્ણ થાય છે, જે પછી પૃષ્ઠભૂમિ કાર્ય ફરી શરૂ થાય છે (થ્રોટલિંગ પ્રોગ્રામ ખાતરી કરે છે કે શોધ ક્વેરીઝની બેરેજ મહત્વપૂર્ણ પૃષ્ઠભૂમિ કાર્યમાં દખલ કરતી નથી).

16 કોરો: વિશ્વસનીયતા માટે, અમે સર્વરને માસ્ટર/સ્લેવ જૂથોમાં ગોઠવીએ છીએ. દરેક માસ્ટર પાસે તેના આદેશ હેઠળ એક SSD અને એક EBS સર્વર છે. જો મુખ્ય સર્વર ક્રેશ થાય છે, તો SSD સર્વર તરત જ તેનું સ્થાન લે છે. લગભગ તમામ સમય, માસ્ટર અને સ્લેવ બરાબર કામ કરે છે, જેથી દરેક ડેટા બ્લોક બે અલગ-અલગ સર્વર પર શોધી શકાય છે (EBS સ્લેવ સર્વર નબળું પ્રોસેસર ધરાવે છે, તેથી અમે તેને ધ્યાનમાં લેતા નથી). અમે તેમની વચ્ચે કાર્યને વિભાજીત કરીએ છીએ, જેથી અમારી પાસે કુલ 16 કોરો ઉપલબ્ધ હોય.

ઘણા કોરો: નજીકના ભવિષ્યમાં, અમે સર્વર્સ પર ડેટાને એવી રીતે વિતરિત કરીશું કે તેઓ દરેક બિન-તુચ્છ વિનંતીની પ્રક્રિયામાં ભાગ લે. દરેક કોર કામ કરશે. [નૉૅધ: અમે યોજનાનો અમલ કર્યો અને શોધની ઝડપ વધારીને 1 TB/s કરી, લેખના અંતે નોંધ જુઓ].

સરળતા વિશ્વસનીયતા સુનિશ્ચિત કરે છે

બ્રુટ ફોર્સ પદ્ધતિનો બીજો ફાયદો એ તેની એકદમ સુસંગત કામગીરી છે. સામાન્ય રીતે, સમસ્યા અને ડેટા સેટની વિગતો માટે શોધ ખૂબ સંવેદનશીલ હોતી નથી (હું માનું છું કે તેથી જ તેને "બરછટ" કહેવામાં આવે છે).

કીવર્ડ ઇન્ડેક્સ કેટલીકવાર અવિશ્વસનીય રીતે ઝડપી પરિણામો આપે છે, અને અન્ય સમયે તે થતું નથી. ધારો કે તમારી પાસે 50 GB લોગ છે જેમાં 'ગ્રાહક_5987235982' શબ્દ બરાબર ત્રણ વખત દેખાય છે. આ શબ્દ માટેની શોધ ઇન્ડેક્સમાંથી સીધા જ ત્રણ સ્થાનોની ગણતરી કરે છે અને તરત જ પૂર્ણ થશે. પરંતુ જટિલ વાઇલ્ડકાર્ડ શોધ હજારો કીવર્ડ્સને સ્કેન કરી શકે છે અને ઘણો સમય લઈ શકે છે.

બીજી બાજુ, બ્રુટ ફોર્સ સર્ચ કોઈપણ ક્વેરી માટે વધુ કે ઓછા સમાન ઝડપે કરે છે. લાંબા શબ્દો શોધવાનું વધુ સારું છે, પરંતુ એક અક્ષરની શોધ પણ ખૂબ ઝડપી છે.

બ્રુટ ફોર્સ પદ્ધતિની સરળતાનો અર્થ એ છે કે તેનું પ્રદર્શન તેના સૈદ્ધાંતિક મહત્તમની નજીક છે. અણધાર્યા ડિસ્ક ઓવરલોડ, લૉક કન્ટેક્શન, પોઇન્ટર પીછો અને નિષ્ફળતાના અન્ય હજારો કારણો માટે ઓછા વિકલ્પો છે. મેં હમણાં જ અમારા સૌથી વ્યસ્ત સર્વર પર ગયા અઠવાડિયે Scalyr વપરાશકર્તાઓ દ્વારા કરવામાં આવેલી વિનંતીઓ જોઈ. 14 અરજીઓ આવી હતી. તેમાંથી બરાબર આઠને એક સેકન્ડથી વધુ સમય લાગ્યો; 000% 99 મિલિસેકંડમાં પૂર્ણ થયું (જો તમે લોગ વિશ્લેષણ સાધનોનો ઉપયોગ કર્યો નથી, તો મારા પર વિશ્વાસ કરો: તે ઝડપી છે).

સેવાના ઉપયોગમાં સરળતા માટે સ્થિર, વિશ્વસનીય કામગીરી મહત્વપૂર્ણ છે. જો તે સમયાંતરે પાછળ રહે છે, તો વપરાશકર્તાઓ તેને અવિશ્વસનીય સમજશે અને તેનો ઉપયોગ કરવામાં અનિચ્છા કરશે.

લૉગ સર્ચ ઇન એક્શન

અહીં એક નાનું એનિમેશન છે જે સ્કેલર શોધને ક્રિયામાં બતાવે છે. અમારી પાસે એક ડેમો એકાઉન્ટ છે જ્યાં અમે દરેક સાર્વજનિક ગીથબ રિપોઝીટરીમાં દરેક ઇવેન્ટને આયાત કરીએ છીએ. આ ડેમોમાં, હું એક અઠવાડિયાના મૂલ્યના ડેટાની તપાસ કરું છું: લગભગ 600 MB કાચા લૉગ્સ.

મારા ડેસ્કટોપ (સર્વરથી લગભગ 5000 કિલોમીટર દૂર) પર, ખાસ તૈયારી વિના વિડિયો લાઇવ રેકોર્ડ કરવામાં આવ્યો હતો. તમે જે પ્રદર્શન જોશો તે મોટે ભાગે કારણે છે વેબ ક્લાયંટ ઓપ્ટિમાઇઝેશન, તેમજ ઝડપી અને વિશ્વસનીય બેકએન્ડ. જ્યારે પણ 'લોડિંગ' સૂચક વિના વિરામ હોય, ત્યારે તે હું થોભાવું છું જેથી તમે વાંચી શકો કે હું શું દબાવવાનો છું.

અંતમા

મોટી માત્રામાં ડેટાની પ્રક્રિયા કરતી વખતે, સારી અલ્ગોરિધમ પસંદ કરવી મહત્વપૂર્ણ છે, પરંતુ "સારા" નો અર્થ "ફેન્સી" નથી. વ્યવહારમાં તમારો કોડ કેવી રીતે કાર્ય કરશે તે વિશે વિચારો. અલ્ગોરિધમ્સનું સૈદ્ધાંતિક વિશ્લેષણ કેટલાક પરિબળોને છોડી દે છે જે વાસ્તવિક દુનિયામાં ખૂબ મહત્વના હોઈ શકે છે. સરળ અલ્ગોરિધમ્સ ઑપ્ટિમાઇઝ કરવા માટે સરળ અને ધારની પરિસ્થિતિઓમાં વધુ સ્થિર છે.

કોડ કયા સંદર્ભમાં અમલમાં આવશે તે વિશે પણ વિચારો. અમારા કિસ્સામાં, અમને પૃષ્ઠભૂમિ કાર્યોનું સંચાલન કરવા માટે પૂરતા શક્તિશાળી સર્વરની જરૂર છે. વપરાશકર્તાઓ પ્રમાણમાં ભાગ્યે જ શોધ શરૂ કરે છે, તેથી અમે દરેક શોધને પૂર્ણ કરવા માટે જરૂરી ટૂંકા ગાળા માટે સર્વર્સના સંપૂર્ણ જૂથને ઉધાર લઈ શકીએ છીએ.

બ્રુટ ફોર્સ પદ્ધતિનો ઉપયોગ કરીને, અમે લોગના સમૂહમાં ઝડપી, વિશ્વસનીય, લવચીક શોધનો અમલ કર્યો. અમે આશા રાખીએ છીએ કે આ વિચારો તમારા પ્રોજેક્ટ માટે ઉપયોગી થશે.

સંપાદિત કરો: છેલ્લાં કેટલાંક વર્ષોમાં પ્રદર્શનમાં થયેલા વધારાને પ્રતિબિંબિત કરવા માટે શીર્ષક અને લખાણ "20 GB પ્રતિ સેકન્ડ પર શોધો" થી "1 TB પ્રતિ સેકન્ડ પર શોધ" માં બદલાઈ ગયા છે. ઝડપમાં આ વધારો મુખ્યત્વે અમારા વધેલા ગ્રાહક આધારને સેવા આપવા માટે અમે આજે જે EC2 સર્વર્સ મૂકી રહ્યા છીએ તેના પ્રકાર અને સંખ્યામાં ફેરફારને કારણે છે. ટૂંક સમયમાં એવા ફેરફારો આવી રહ્યા છે જે ઓપરેશનલ કાર્યક્ષમતામાં વધુ એક નાટકીય પ્રોત્સાહન આપશે, અને અમે તેમને શેર કરવા માટે રાહ જોઈ શકતા નથી.

સોર્સ: www.habr.com