ElasticSearch નો ઉપયોગ કરીને હાઇલોડ પ્રોજેક્ટ પર ઓપ્ટિમાઇઝેશન લોડ કરો

હેલો, હેબ્ર! મારું નામ મેક્સિમ વાસિલીવ છે, હું ફિન્ચમાં વિશ્લેષક અને પ્રોજેક્ટ મેનેજર તરીકે કામ કરું છું. આજે હું તમને જણાવવા માંગુ છું કે કેવી રીતે, ElasticSearch નો ઉપયોગ કરીને, અમે 15 મિનિટમાં 6 મિલિયન ક્વેરીઝ પર પ્રક્રિયા કરી શક્યા અને અમારા એક ક્લાયન્ટની સાઇટ પર દૈનિક લોડને ઑપ્ટિમાઇઝ કરી શક્યા. કમનસીબે, અમારે નામ વિના કરવું પડશે, કારણ કે અમારી પાસે એનડીએ છે, અમે આશા રાખીએ છીએ કે લેખની સામગ્રી આનાથી પીડાશે નહીં. ચાલો જઇએ.

પ્રોજેક્ટ કેવી રીતે કામ કરે છે

અમારા બેકએન્ડ પર અમે એવી સેવાઓ બનાવીએ છીએ જે અમારા ક્લાયન્ટની વેબસાઇટ્સ અને મોબાઇલ એપ્લિકેશનની કાર્યક્ષમતાને સુનિશ્ચિત કરે છે. સામાન્ય રચના આકૃતિમાં જોઈ શકાય છે:

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

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

સંક્ષિપ્ત પૃષ્ઠભૂમિ

શરૂઆતમાં, અમે અમારા એકમાત્ર ડેટા સ્ટોરેજ તરીકે PostgreSQL નો ઉપયોગ કર્યો હતો. ડીબીએમએસ માટે તેના ફાયદા પ્રમાણભૂત છે: વ્યવહારોની હાજરી, વિકસિત ડેટા પુનઃપ્રાપ્તિ ભાષા, એકીકરણ માટે સાધનોની વિશાળ શ્રેણી; સારા પ્રદર્શન સાથે મળીને એકદમ લાંબા સમય સુધી અમારી જરૂરિયાતોને સંતોષી.

અમે પોસ્ટગ્રેસમાં સંપૂર્ણપણે તમામ ડેટા સંગ્રહિત કર્યો છે: વ્યવહારોથી સમાચાર સુધી. પરંતુ વપરાશકર્તાઓની સંખ્યામાં વધારો થયો, અને તેની સાથે વિનંતીઓની સંખ્યા.

સમજવા માટે, એકલા ડેસ્કટોપ સાઇટ પર 2017 માં સત્રોની વાર્ષિક સંખ્યા 131 મિલિયન હતી. 2018 માં - 125 મિલિયન. 2019 માં ફરીથી 130 મિલિયન. સાઇટ અને મોબાઇલ એપ્લિકેશનના મોબાઇલ સંસ્કરણમાંથી બીજા 100-200 મિલિયન ઉમેરો, અને તમે મોટી સંખ્યામાં વિનંતીઓ પ્રાપ્ત થશે.

જેમ જેમ પ્રોજેક્ટ વધતો ગયો, પોસ્ટગ્રેસ હવે ભારનો સામનો કરી શક્યું નહીં; અમે ચાલુ રાખી શક્યા નહીં - મોટી સંખ્યામાં વિવિધ પ્રશ્નો દેખાયા, જેના માટે અમે પૂરતી સંખ્યામાં અનુક્રમણિકાઓ બનાવવામાં અસમર્થ હતા.

અમને સમજાયું કે અન્ય ડેટા સ્ટોર્સની જરૂર છે જે અમારી જરૂરિયાતોને પૂરી કરશે અને PostgreSQL નો ભાર દૂર કરશે. ઇલાસ્ટિકસર્ચ અને મોંગોડીબીને સંભવિત વિકલ્પો તરીકે ગણવામાં આવ્યા હતા. બાદમાં નીચેના મુદ્દાઓ પર હારી ગયા:

1. ઇન્ડેક્સમાં ડેટાનું પ્રમાણ વધવાથી ઇન્ડેક્સીંગની ઝડપ ધીમી થાય છે. સ્થિતિસ્થાપક સાથે, ઝડપ ડેટાની માત્રા પર આધારિત નથી.
2. સંપૂર્ણ ટેક્સ્ટ શોધ નથી

તેથી અમે અમારા માટે સ્થિતિસ્થાપક પસંદ કર્યું અને સંક્રમણ માટે તૈયાર.

સ્થિતિસ્થાપક પર સ્વિચ કરો

1. અમે પોઈન્ટ-ઓફ-સેલ શોધ સેવા સાથે સંક્રમણની શરૂઆત કરી. અમારા ક્લાયંટ પાસે વેચાણના કુલ લગભગ 70 પોઈન્ટ્સ છે, અને તે જ સમયે વેબસાઈટ અને એપ્લિકેશનમાં અનેક પ્રકારની શોધ જરૂરી છે:

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

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

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

3. પછી અમે વ્યવહાર પ્રક્રિયા ખસેડી. વપરાશકર્તાઓ સાઇટ પર ચોક્કસ ઉત્પાદન ખરીદી શકે છે અને ઇનામ ડ્રોમાં ભાગ લઈ શકે છે. આવી ખરીદીઓ પછી, અમે ખાસ કરીને સપ્તાહાંત અને રજાઓ પર મોટી માત્રામાં ડેટાની પ્રક્રિયા કરીએ છીએ. સરખામણી માટે, જો સામાન્ય દિવસોમાં ખરીદીની સંખ્યા ક્યાંક 1,5-2 મિલિયનની આસપાસ હોય છે, તો રજાના દિવસોમાં આ આંકડો 53 મિલિયન સુધી પહોંચી શકે છે.

તે જ સમયે, ડેટા પર ઓછામાં ઓછા સમયની પ્રક્રિયા થવી જોઈએ - વપરાશકર્તાઓ પરિણામો માટે ઘણા દિવસો રાહ જોવી પસંદ કરતા નથી. Postgres દ્વારા આવી સમયમર્યાદા હાંસલ કરવાનો કોઈ રસ્તો નથી - અમને વારંવાર બ્લોક્સ મળ્યા છે, અને જ્યારે અમે બધી વિનંતીઓ પર પ્રક્રિયા કરી રહ્યા હતા, ત્યારે વપરાશકર્તાઓ તેમને ઇનામ મળ્યા છે કે નહીં તે તપાસી શક્યા નથી. આ વ્યવસાય માટે ખૂબ સુખદ નથી, તેથી અમે પ્રક્રિયાને Elasticsearch પર ખસેડી છે.

સમયાંતરે

હવે અપડેટ્સ નીચેની શરતો અનુસાર ઇવેન્ટ-આધારિત ગોઠવેલ છે:

1. વેચાણના પોઈન્ટ. જલદી અમે બાહ્ય સ્ત્રોતમાંથી ડેટા પ્રાપ્ત કરીએ છીએ, અમે તરત જ અપડેટ શરૂ કરીએ છીએ.
2. સમાચાર. સાઇટ પર કોઈપણ સમાચાર સંપાદિત થતાં જ તે આપોઆપ ઈલાસ્ટીક પર મોકલવામાં આવે છે.

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

એકીકરણ પદ્ધતિઓ

સ્થિતિસ્થાપક સાથે સંકલિત કરવાની 2 રીતો છે:

1. TCP દ્વારા મૂળ ક્લાયન્ટ દ્વારા. મૂળ ડ્રાઇવર ધીમે ધીમે મરી રહ્યો છે: તે હવે સમર્થિત નથી, અને તેની વાક્યરચના ખૂબ જ અસુવિધાજનક છે. તેથી, અમે વ્યવહારીક રીતે તેનો ઉપયોગ કરતા નથી અને તેને સંપૂર્ણપણે છોડી દેવાનો પ્રયાસ કરીએ છીએ.
2. HTTP ઇન્ટરફેસ દ્વારા જેમાં તમે JSON વિનંતીઓ અને લ્યુસીન સિન્ટેક્સ બંનેનો ઉપયોગ કરી શકો છો. છેલ્લું એક ટેક્સ્ટ એન્જિન છે જે સ્થિતિસ્થાપક વાપરે છે. આ વિકલ્પમાં, અમને HTTP પર JSON વિનંતીઓ દ્વારા બેચ કરવાની ક્ષમતા મળે છે. આ તે વિકલ્પ છે જેનો અમે ઉપયોગ કરવાનો પ્રયાસ કરી રહ્યા છીએ.

HTTP ઇન્ટરફેસ માટે આભાર, અમે લાઇબ્રેરીઓનો ઉપયોગ કરી શકીએ છીએ જે HTTP ક્લાયંટનું અસુમેળ અમલીકરણ પ્રદાન કરે છે. અમે બેચ અને અસિંક્રોનસ API નો લાભ લઈ શકીએ છીએ, જે આખરે ઉચ્ચ પ્રદર્શન આપે છે, જેણે મોટા પ્રમોશનના દિવસો દરમિયાન ઘણી મદદ કરી હતી (નીચે આના પર વધુ)

સરખામણી માટે કેટલીક સંખ્યાઓ:

• ગ્રૂપિંગ વિના 20 થ્રેડમાં પોસ્ટગ્રેસમાં ઇનામ મેળવનારા વપરાશકર્તાઓને સાચવી રહ્યાં છે: 460713 સેકન્ડમાં 42 રેકોર્ડ
• 10 થ્રેડો માટે સ્થિતિસ્થાપક + પ્રતિક્રિયાશીલ ક્લાયંટ + 1000 તત્વો માટે બેચ: 596749 સેકન્ડમાં 11 રેકોર્ડ
• 10 થ્રેડો માટે સ્થિતિસ્થાપક + પ્રતિક્રિયાશીલ ક્લાયંટ + 1000 તત્વો માટે બેચ: 23801684 મિનિટમાં 4 રેકોર્ડ

હવે અમે એક HTTP રિક્વેસ્ટ મેનેજર લખ્યું છે જે JSON ને બેચ/નોન-બેચ તરીકે બનાવે છે અને લાઇબ્રેરીને ધ્યાનમાં લીધા વિના કોઈપણ HTTP ક્લાયંટ દ્વારા મોકલે છે. તમે સિંક્રનસ અથવા અસુમેળ રીતે વિનંતીઓ મોકલવાનું પણ પસંદ કરી શકો છો.

કેટલાક એકીકરણમાં અમે હજુ પણ અધિકૃત ટ્રાન્સપોર્ટ ક્લાયંટનો ઉપયોગ કરીએ છીએ, પરંતુ આ માત્ર તાત્કાલિક રિફેક્ટરિંગની બાબત છે. આ કિસ્સામાં, સ્પ્રિંગ વેબક્લાયન્ટના આધારે બનાવેલ તેના પોતાના ક્લાયંટનો ઉપયોગ પ્રક્રિયા માટે થાય છે.

મોટું પ્રમોશન

વર્ષમાં એકવાર, પ્રોજેક્ટ વપરાશકર્તાઓ માટે એક મોટું પ્રમોશન હોસ્ટ કરે છે - આ તે જ હાઇલોડ છે, કારણ કે આ સમયે અમે એક સાથે લાખો વપરાશકર્તાઓ સાથે કામ કરીએ છીએ.

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

2019 ની શરૂઆતમાં, અમે નક્કી કર્યું કે સ્થિતિસ્થાપક શોધની જરૂર છે. આખા વર્ષ માટે, અમે ઇલાસ્ટિકમાં પ્રાપ્ત ડેટાની પ્રક્રિયા અને મોબાઇલ એપ્લિકેશન અને વેબસાઇટના API પર તેના આઉટપુટનું આયોજન કર્યું. પરિણામે, આગલા વર્ષે પ્રમોશન દરમિયાન અમે પ્રક્રિયા કરી 15 મિનિટમાં 131 એન્ટ્રીઓ.

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

નિષ્કર્ષ/નિષ્કર્ષ

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

ભવિષ્યમાં, અમે સેવાઓને સ્થાનાંતરિત કરવાની યોજના બનાવીએ છીએ જો અમે સમજીએ કે ડેટા વિનંતી ખૂબ જ વૈવિધ્યસભર બની રહી છે અને અમર્યાદિત સંખ્યામાં કૉલમ્સ માટે શોધ કરવામાં આવી રહી છે. પોસ્ટગ્રેસ માટે આ હવે કાર્ય નથી.

જો અમને કાર્યક્ષમતામાં સંપૂર્ણ-ટેક્સ્ટ શોધની જરૂર હોય અથવા જો અમારી પાસે ઘણાં વિવિધ શોધ માપદંડ હોય, તો અમે પહેલાથી જ જાણીએ છીએ કે આને સ્થિતિસ્થાપકમાં અનુવાદિત કરવાની જરૂર છે.

⌘⌘⌘

વાંચવા બદલ આભાર. જો તમારી કંપની પણ ElasticSearch નો ઉપયોગ કરે છે અને તમારા પોતાના અમલીકરણ કેસ છે, તો કૃપા કરીને અમને જણાવો. અન્ય લોકો કેવી રીતે કરે છે તે જાણવું રસપ્રદ રહેશે :)

સોર્સ: www.habr.com