વેબ સેવાઓ માટે ઇન-મેમરી આર્કિટેક્ચર: ટેક્નોલોજી ફંડામેન્ટલ્સ અને સિદ્ધાંતો

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

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

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

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

ઇન-મેમરી કોણ અને કેવી રીતે વાપરે છે

ઇન-મેમરીનો મોટાભાગે ઉપયોગ થાય છે જ્યાં ઝડપી વપરાશકર્તા ક્રિયાપ્રતિક્રિયા અથવા મોટી માત્રામાં ડેટાની પ્રક્રિયા જરૂરી હોય છે.

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

અમારા ગ્રાહકો ઇન-મેમરી સોલ્યુશન્સનો ઉપયોગ કેવી રીતે કરે છે અને તમે તેને જાતે કેવી રીતે અમલમાં મૂકી શકો છો તેના કેટલાક ઉદાહરણો હું તમને જણાવીશ.

પ્રાથમિક સ્ટોરેજ તરીકે ઇન-મેમરી

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

સામૂહિક રીતે આને ઇન-મેમરી ડેટાબેઝ (IMDB) અથવા મેમરી-સેન્ટ્રિક સ્ટોરેજ કહેવામાં આવે છે. ઉકેલોના આ વર્ગના ઘણા નામો છે, આ માત્ર એક જ નથી. 

IMDB લક્ષણો:

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

• IMDB રિલેશનલ ડેટાબેઝ કરતાં ઝડપી છે કારણ કે તે ડિસ્ક કરતાં RAM માંથી માહિતી પુનઃપ્રાપ્ત કરવા માટે ઝડપી છે. 
• આંતરિક ઑપ્ટિમાઇઝેશન અલ્ગોરિધમ્સમાં ઓછી સૂચનાઓ હોય છે.
• IMDB એ એપ્લિકેશનમાં ડેટા, ઇવેન્ટ્સ અને વ્યવહારોનું સંચાલન કરવા માટે યોગ્ય છે.

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

દોષ-સહિષ્ણુ એપ્લિકેશનો બનાવવા માટે

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

બેલેન્સર એક સત્રમાંથી તમામ વિનંતીઓને સખત રીતે એક સર્વર પર નિર્દેશિત કરે છે. આ એક સ્ટીક સેશન મિકેનિઝમ છે: દરેક સત્ર સર્વર સાથે સંકળાયેલું છે જ્યાં તેને સ્થાનિક રીતે સંગ્રહિત અને પ્રક્રિયા કરવામાં આવે છે. 

જ્યારે એક સર્વર નિષ્ફળ જાય ત્યારે શું થાય છે?

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

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

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

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

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

હાઇબ્રિડ ટ્રાન્ઝેક્શનલ એનાલિટિકલ પ્રોસેસિંગ (HTAP)

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

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

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

ઇન-મેમરી સોલ્યુશન્સનું એકીકરણ

એક (પ્રમાણમાં) સરળ રીત - શરૂઆતથી બધું વિકસાવો. અમે ડિસ્ક પર ડેટા રાખીએ છીએ અને હોટ ડેટાને મેમરીમાં સ્ટોર કરીએ છીએ. આ સર્વર રીબૂટ અથવા આઉટેજને ટકી રહેવામાં મદદ કરે છે.

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

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

• ડેટાબેઝ સાથે કનેક્ટ કરવાની પ્રમાણભૂત રીત જે તેની નીચે સ્થિત હશે (ઉદાહરણ તરીકે, MySQL);
• સ્ટાન્ડર્ડ ક્વેરી લેંગ્વેજ, જેથી સ્ટોરેજ સાથેની ક્રિયાપ્રતિક્રિયાના તર્કને ફરીથી લખવા અને બદલવા નહીં;
• વ્યવહારિક - ક્રિયાપ્રતિક્રિયાના અર્થશાસ્ત્રને સાચવો.

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

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

સોર્સ: www.habr.com