સ્પોર્ટમાસ્ટર પર અમે કેવી રીતે કેશીંગ સિસ્ટમ પસંદ કરી. ભાગ 1

નમસ્તે! મારું નામ એલેક્સી પ્યાન્કોવ છે, હું સ્પોર્ટમાસ્ટર કંપનીમાં ડેવલપર છું. તેમાં પોસ્ટ મેં કહ્યું કે સ્પોર્ટમાસ્ટર વેબસાઇટ પર 2012 માં કેવી રીતે કામ શરૂ થયું, અમે કઈ પહેલોને "પૂશ થ્રુ" કરવામાં અને તેનાથી વિપરીત, અમે કઈ રેક એકત્રિત કરી.

આજે હું બીજા વિષયને અનુસરતા વિચારો શેર કરવા માંગુ છું - સાઇટ એડમિન વિસ્તારમાં જાવા બેકએન્ડ માટે કેશીંગ સિસ્ટમ પસંદ કરવી. આ કાવતરું મારા માટે વિશેષ અર્થ ધરાવે છે - જો કે વાર્તા ફક્ત 2 મહિના માટે ખુલી હતી, આ 60 દિવસો દરમિયાન અમે 12-16 કલાક કામ કર્યું અને એક પણ દિવસની રજા વિના. મેં ક્યારેય વિચાર્યું પણ નહોતું કે આટલી મહેનત કરવી શક્ય છે.

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

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

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

પરંતુ આ પોસ્ટમાં હું દૂરથી શરૂ કરીશ, હું કેટલાક વિચારો - કેશીંગ વિશેના વિચારો રજૂ કરીશ, જે મોટા પ્રોજેક્ટ પહેલાં સ્ક્રોલ કરવા માટે એક સારું પગલું હશે.

જ્યારે કેશીંગ કાર્ય થાય છે

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

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

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

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

કેશીંગ સિસ્ટમ માટે મૂળભૂત આવશ્યકતાઓ

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

ચાલો આ કેસ રમીએ.

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

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

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

પ્રારંભિક લોડની તુલનામાં, અમારું આયર્ન રિઝર્વ 2-5 ગણું હતું, અને આ સમય દરમિયાન લોડ 10-100 ગણો વધ્યો હતો. કેશનો ઉપયોગ કરીને, અમે ભારે કાર્યો માટેના કૉલ્સને દૂર કર્યા અને તેથી બધું કામ કર્યું. અને હવે, કેશ વિના, આપણી સિસ્ટમ કેટલી વાર ધીમું થશે? આપણું શું થશે? સિસ્ટમ પડી જશે.

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

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

પસંદગીની વેદના

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

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

અમે શું કર્યું:

1. અમે Google અને StackOverflow સૂચવે છે તે તમામ સિસ્ટમોની સૂચિ બનાવીએ છીએ. 30 થી થોડું વધારે
2. અમે ઉત્પાદન માટે લાક્ષણિક લોડ સાથે પરીક્ષણો લખીએ છીએ. આ કરવા માટે, અમે ઉત્પાદન પર્યાવરણમાં સિસ્ટમમાંથી પસાર થતો ડેટા રેકોર્ડ કર્યો - નેટવર્ક પર નહીં, પરંતુ સિસ્ટમની અંદરના ડેટા માટે એક પ્રકારનું સ્નિફર. બરાબર આ ડેટાનો ઉપયોગ પરીક્ષણોમાં કરવામાં આવ્યો હતો.
3. આખી ટીમ સાથે, દરેક વ્યક્તિ સૂચિમાંથી આગલી સિસ્ટમ પસંદ કરે છે, તેને ગોઠવે છે અને પરીક્ષણો ચલાવે છે. તે પરીક્ષણ પાસ કરતું નથી, તે ભારને વહન કરતું નથી - અમે તેને ફેંકી દઈએ છીએ અને આગળની લાઇનમાં આગળ વધીએ છીએ.
4. 17 મી સિસ્ટમ પર તે સ્પષ્ટ થઈ ગયું કે બધું નિરાશાજનક હતું. બોટલને હલાવવાનું બંધ કરો, ગંભીરતાથી વિચારવાનો સમય છે.

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

ચાલો આ વિકલ્પને મોડલ કરીએ (કલ્પના કરવી મુશ્કેલ છે કે મધ્યમ+ વિકાસકર્તા શૂન્યાવકાશમાં રહે છે, અને પસંદગીના સમયે તેણે કયા ઉત્પાદનને પ્રથમ અજમાવવું તે અંગે તેની પસંદગી હજુ સુધી ઔપચારિક કરી નથી - તેથી, વધુ તર્ક એક સિદ્ધાંતવાદી/ફિલસૂફીનો વધુ છે. જુનિયર વિશે).

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

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

સૂચિ સંપૂર્ણ નથી; ત્યાં ડઝનેક સિસ્ટમ્સ છે. અને અમે ફક્ત એક વસ્તુને સ્ક્રૂ કરીશું. ચાલો “બ્યુટી કોન્ટેસ્ટ” માટે પસંદ કરેલી 5 સિસ્ટમો લઈએ અને પસંદગી કરીએ. કોણ વિજેતા બનશે?

Redis

અમે તેઓ સત્તાવાર વેબસાઇટ પર શું લખે છે તે વાંચીએ છીએ.
Redis - ઓપનસોર્સ પ્રોજેક્ટ. ઇન-મેમરી ડેટા સ્ટોરેજ, ઑન-ડિસ્ક સાચવવાની ક્ષમતા, ઑટો-પાર્ટીશનિંગ, ઉચ્ચ ઉપલબ્ધતા અને નેટવર્ક આઉટેજમાંથી પુનઃપ્રાપ્તિ ઑફર કરે છે.

એવું લાગે છે કે બધું સારું છે, તમે તેને લઈ શકો છો અને તેને સ્ક્રૂ કરી શકો છો - તમને જે જોઈએ છે, તે કરે છે. પરંતુ માત્ર મનોરંજન માટે, ચાલો અન્ય ઉમેદવારોને જોઈએ.

EhCache

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

રેડિસ ભૂલી ગયો છે, હું EhCache પસંદ કરવા માટે તૈયાર છું.

પરંતુ દેશભક્તિની ભાવના મને ટેરન્ટૂલ વિશે શું સારું છે તે જોવા માટે દબાણ કરે છે.

ટેરન્ટૂલ

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

ચાલો અમલીકરણો જોઈએ: Mail.ru કોર્પોરેટ હાઇવે, એવિટો, બેલાઇન, મેગાફોન, આલ્ફા-બેંક, ગેઝપ્રોમ...

જો ટેરન્ટૂલ વિશે હજુ પણ કોઈ શંકા હોય, તો માસ્ટરકાર્ડ પર અમલીકરણ કેસ મને સમાપ્ત કરે છે. હું ટેરન્ટૂલ લઉં છું.

પરંતુ કોઈપણ રીતે…

સળગાવવું

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

અમલીકરણો: Sberbank, અમેરિકન એરલાઇન્સ, Yahoo! જાપાન. અને પછી મને જાણવા મળ્યું કે ઇગ્નાઇટ માત્ર Sberbank માં જ લાગુ કરવામાં આવ્યું નથી, પરંતુ SberTech ટીમ ઉત્પાદનને રિફાઇન કરવા માટે તેના લોકોને Ignite ટીમ પાસે મોકલે છે. આ સંપૂર્ણપણે મનમોહક છે અને હું ઇગ્નાઇટ લેવા માટે તૈયાર છું.

તે શા માટે સંપૂર્ણપણે અસ્પષ્ટ છે, હું પાંચમા મુદ્દાને જોઈ રહ્યો છું.

હેઝલકાસ્ટ

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

બસ, હું હેઝલકાસ્ટ લેવા તૈયાર છું.

સરખામણી

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

અમને આના જેવું એક મળે છે સમીક્ષા, અમારી 5 સિસ્ટમ પસંદ કરો.

અહીં તેઓને સૉર્ટ કરવામાં આવ્યા છે: રેડિસ ટોચ પર છે, હેઝલકાસ્ટ બીજા સ્થાને છે, ટેરન્ટૂલ અને ઇગ્નાઇટ લોકપ્રિયતા મેળવી રહ્યાં છે, EhCache છે અને તે જ છે.

પરંતુ ચાલો જોઈએ ગણતરી પદ્ધતિ: વેબસાઇટ્સની લિંક્સ, સિસ્ટમમાં સામાન્ય રસ, જોબ ઑફર્સ - સરસ! એટલે કે, જ્યારે મારી સિસ્ટમ નિષ્ફળ જશે, ત્યારે હું કહીશ: "ના, તે વિશ્વસનીય છે! નોકરીની ઘણી ઓફરો છે..." આટલી સરળ સરખામણી કરવાથી નહીં ચાલે.

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

ઠીક છે, ચાલો હાર ન માનીએ, ચાલો સિસ્ટમ્સની સીધી સરખામણી શોધીએ. ચાલો ટોચના બે વિકલ્પો લઈએ - રેડિસ અને હેઝલકાસ્ટ. અમને ઝડપમાં રસ છે, અને અમે આ પરિમાણના આધારે તેમની તુલના કરીશું.

હર્ટ્ઝ વિ રેડિસ

અમે આ શોધીએ છીએ સરખામણી:


વાદળી રેડિસ છે, લાલ હેઝલકાસ્ટ છે. હેઝલકાસ્ટ દરેક જગ્યાએ જીતે છે, અને આ માટે એક તર્ક છે: તે મલ્ટી-થ્રેડેડ છે, અત્યંત ઑપ્ટિમાઇઝ છે, દરેક થ્રેડ તેના પોતાના પાર્ટીશન સાથે કામ કરે છે, તેથી ત્યાં કોઈ અવરોધ નથી. અને રેડિસ સિંગલ-થ્રેડેડ છે; તે આધુનિક મલ્ટી-કોર CPUs થી લાભ મેળવતું નથી. હેઝલકાસ્ટ પાસે અસુમેળ I/O છે, Redis-Jedis પાસે બ્લોકીંગ સોકેટ્સ છે. છેવટે, હેઝલકાસ્ટ બાઈનરી પ્રોટોકોલનો ઉપયોગ કરે છે, અને રેડિસ ટેક્સ્ટ-કેન્દ્રિત છે, એટલે કે તે બિનકાર્યક્ષમ છે.

માત્ર કિસ્સામાં, ચાલો સરખામણીના બીજા સ્ત્રોત તરફ વળીએ. તે આપણને શું બતાવશે?

રેડિસ વિ હર્ટ્ઝ

અન્ય સરખામણી:


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

તે તારણ આપે છે કે પ્રથમ પરિણામ વાસ્તવમાં રિગ કરવામાં આવ્યું હતું: રેડિસને બેઝ બોક્સમાં લેવામાં આવ્યું હતું, અને હેઝલકાસ્ટને ટેસ્ટ કેસ માટે તૈયાર કરવામાં આવ્યું હતું. પછી તે તારણ આપે છે: પ્રથમ, આપણે કોઈ પર વિશ્વાસ કરી શકતા નથી, અને બીજું, જ્યારે આપણે આખરે સિસ્ટમ પસંદ કરીએ છીએ, ત્યારે પણ આપણે તેને યોગ્ય રીતે ગોઠવવાની જરૂર છે. આ સેટિંગ્સમાં ડઝનેક, લગભગ સેંકડો પરિમાણો શામેલ છે.

બોટલ ધ્રુજારી

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

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

આ પદ્ધતિ આ ઉદાહરણ દ્વારા ખૂબ જ સારી રીતે સમજાવવામાં આવી છે.

એક સમયે બોટલમાં સેઇલબોટ એકત્રિત કરવી તે ખૂબ જ લોકપ્રિય હતું. તે જ સમયે, સેઇલબોટ મોટી અને નાજુક છે, અને બોટલની ગરદન ખૂબ સાંકડી છે, તેને અંદર દબાણ કરવું અશક્ય છે. તેને કેવી રીતે એસેમ્બલ કરવું?

આવી પદ્ધતિ છે, ખૂબ જ ઝડપી અને ખૂબ અસરકારક.

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

અમે કોઈને આ કંઈક બતાવીએ છીએ: "સરયોગા, તમે જુઓ છો!" અને ખરેખર, દૂરથી તે વહાણ જેવું લાગે છે. પરંતુ આને ચાલુ રાખવાની મંજૂરી આપી શકાય નહીં.

બીજી રીત છે. તેઓ હેકર્સ જેવા વધુ અદ્યતન લોકો દ્વારા ઉપયોગમાં લેવાય છે.

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

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

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

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

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

બોટલ-નેક ક્યાં જોવાનું છે

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

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

અમને કોડ લોજિક (2) ની પણ જરૂર છે, જે વાસ્તવમાં કેશીંગ વિશે છે. ક્લાયંટ આ કોડ સાથે અમુક API મારફતે ક્રિયાપ્રતિક્રિયા કરે છે. ક્લાઈન્ટ કોડ (1) કાં તો સમાન JVM ની અંદર હોઈ શકે છે અથવા તેને નેટવર્ક પર એક્સેસ કરી શકે છે. કેશમાં કઈ વસ્તુઓ છોડવી અને કઈ બહાર ફેંકવી તેનો નિર્ણય અંદર અમલમાં મૂકાયેલો તર્ક છે. અમે કૅશ સ્ટોર કરવા માટે મેમરી (3) નો ઉપયોગ કરીએ છીએ, પરંતુ જો જરૂરી હોય તો, અમે ડિસ્ક (4) પરનો કેટલોક ડેટા સાચવી શકીએ છીએ.

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

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

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

હેઝલકાસ્ટ

ચાલો જોઈએ કે આ વિઘટનને અમારી સૂચિમાં કેવી રીતે લાગુ કરવું. ઉદાહરણ તરીકે, હેઝલકાસ્ટ.

હેઝલકાસ્ટમાંથી ડેટા મૂકવા/લેવા માટે, ક્લાયંટ કોડ (1) api ને એક્સેસ કરે છે. Hz તમને સર્વરને એમ્બેડેડ તરીકે ચલાવવા માટે પરવાનગી આપે છે, અને આ કિસ્સામાં, api ને એક્સેસ કરવું એ JVM ની અંદર એક મેથડ કૉલ છે, જેને મફત ગણી શકાય.

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

સ્ટોરેજ (4) કનેક્ટ કરી શકાય છે. મહાન. એમ્બેડેડ માટે ક્રિયાપ્રતિક્રિયા (5) તાત્કાલિક ગણી શકાય. ક્લસ્ટર (6) માં નોડ્સ વચ્ચે ડેટા વિનિમય - હા, તે અસ્તિત્વમાં છે. આ ઝડપના ખર્ચે દોષ સહિષ્ણુતામાં રોકાણ છે. Hz ફીચર Near-cache તમને કિંમત ઘટાડવા માટે પરવાનગી આપે છે - ક્લસ્ટરમાંના અન્ય નોડ્સમાંથી પ્રાપ્ત ડેટા કેશ કરવામાં આવશે.

ઝડપ વધારવા માટે આવી પરિસ્થિતિઓમાં શું કરી શકાય?

ઉદાહરણ તરીકે, (2) માં કીના સીરીયલાઇઝેશનને ટાળવા માટે - સૌથી ગરમ ડેટા માટે, હેઝલકાસ્ટની ટોચ પર બીજી કેશ જોડો. સ્પોર્ટ માસ્ટરે આ હેતુ માટે કેફીન પસંદ કર્યું.

સ્તર (6) પર ટ્વિસ્ટ કરવા માટે, Hz બે પ્રકારના સ્ટોરેજ ઓફર કરે છે: IMap અને ReplicatedMap.


સ્પોર્ટમાસ્ટર ટેક્નોલોજી સ્ટેકમાં હેઝલકાસ્ટ કેવી રીતે પ્રવેશ્યું તે ઉલ્લેખનીય છે.

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

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

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

આ બધી આવશ્યકતાઓ માટે, હેઝલકાસ્ટ ચોક્કસપણે બિલને બંધબેસે છે.

ચાલુ રહી શકાય

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

તે દરમિયાન... નવા કોડની શુભેચ્છાઓ!

સોર્સ: www.habr.com