હાઇલોડ++, મિખાઇલ ટ્યુલેનેવ (મોંગોડીબી): કારણ સુસંગતતા: સિદ્ધાંતથી પ્રેક્ટિસ સુધી

આગામી હાઇલોડ++ કોન્ફરન્સ 6 અને 7 એપ્રિલ, 2020ના રોજ સેન્ટ પીટર્સબર્ગમાં યોજાશે.
વિગતો અને ટિકિટો લિંક. હાઇલોડ++ સાઇબિરીયા 2019. હોલ "ક્રાસ્નોયાર્સ્ક". જૂન 25, 12:00. થીસીસ અને પ્રસ્તુતિ.

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

મિખાઇલ ટ્યુલેનેવ (ત્યારબાદ એમટી તરીકે ઓળખાય છે): - હું કારણભૂત સુસંગતતા વિશે વાત કરીશ - આ એક વિશેષતા છે જેના પર અમે MongoDB માં કામ કર્યું છે. હું વિતરિત પ્રણાલીઓના જૂથમાં કામ કરું છું, અમે તે લગભગ બે વર્ષ પહેલાં કર્યું હતું.

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

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

કારણભૂત સુસંગતતા. ચાલો ખ્યાલોને વ્યાખ્યાયિત કરીએ

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

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

હકીકતમાં, આ ડેટાબેઝના તદ્દન બિન-તુચ્છ ગુણધર્મો છે - બહુ ઓછા લોકો તેમને સમર્થન આપે છે. ચાલો મોડેલો પર આગળ વધીએ.

સુસંગતતા મોડલ્સ

ડેટાબેસેસમાં સુસંગતતા મોડેલ બરાબર શું છે? આ કેટલીક બાંયધરી છે જે વિતરિત સિસ્ટમ આપે છે કે ક્લાયંટ કયો ડેટા પ્રાપ્ત કરી શકે છે અને કયા ક્રમમાં.

સૈદ્ધાંતિક રીતે, તમામ સુસંગતતા મોડલ એક વિતરિત સિસ્ટમ જેવી સિસ્ટમ સાથે કેવી રીતે સમાન છે તે નીચે આવે છે, ઉદાહરણ તરીકે, લેપટોપ પર એક નોડ પર. અને આ રીતે હજારો જીઓ-ડિસ્ટ્રિબ્યુટેડ “નોડ્સ” પર ચાલતી સિસ્ટમ લેપટોપ જેવી જ છે, જેમાં આ તમામ ગુણધર્મો સૈદ્ધાંતિક રીતે આપમેળે કરવામાં આવે છે.

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

મોડલ મજબૂત

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

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

ત્યાં બીજી, મજબૂત મિલકત છે જે સ્પેનરમાં સમર્થિત છે - જેને બાહ્ય સુસંગતતા કહેવાય છે. અમે તેના વિશે થોડી વાર પછી વાત કરીશું.

કાર્યકારી

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

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

ઘટનાક્રમ

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

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

હું કેટલાક તુલનાત્મક ઉદાહરણો આપવા માંગુ છું:

આ તીરોનો અર્થ શું છે?

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

CAP પ્રમેય

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

CAP પ્રમેય એ 2000 ના દાયકામાં ઘડવામાં આવેલ સિદ્ધાંત છે કે સુસંગતતા, ઉપલબ્ધતા, પાર્ટીશનો: કોઈપણ બે લો, અને તમે ત્રણ પસંદ કરી શકતા નથી. તે ચોક્કસ સિદ્ધાંત હતો. તે થોડા વર્ષો પછી ગિલ્બર્ટ અને લિંચ દ્વારા પ્રમેય તરીકે સાબિત થયું હતું. પછી આનો ઉપયોગ મંત્ર તરીકે થવા લાગ્યો - સિસ્ટમોને CA, CP, AP વગેરેમાં વહેંચવામાં આવી.

આ પ્રમેય વાસ્તવમાં નીચેના કિસ્સાઓ માટે સાબિત થયો હતો... સૌપ્રથમ, પ્રાપ્યતાને શૂન્યથી સેંકડો સુધી સતત મૂલ્ય તરીકે ગણવામાં આવતું ન હતું (0 - સિસ્ટમ "મૃત" છે, 100 - ઝડપથી પ્રતિક્રિયા આપે છે; અમે તેને તે રીતે ધ્યાનમાં લેવા માટે ટેવાયેલા છીએ) , પરંતુ અલ્ગોરિધમની મિલકત તરીકે, જે ખાતરી આપે છે કે તેના તમામ અમલ માટે તે ડેટા પરત કરે છે.

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

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

કાર્યકારણ સુસંગતતા એ સૌથી મજબૂત મોડેલ છે

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

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

મોંગોડીબી આંતરિક રસોડું

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

MongoDB (ત્યારબાદ "MongoDB" તરીકે ઓળખવામાં આવે છે) એ વિતરિત સિસ્ટમ છે જે આડી સ્કેલિંગને સમર્થન આપે છે, એટલે કે, શાર્ડિંગ; અને દરેક શાર્ડની અંદર તે ડેટા રીડન્ડન્સીને પણ સપોર્ટ કરે છે, એટલે કે પ્રતિકૃતિ.

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

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

બીજો મહત્વનો મુદ્દો: મોંગોડીબી એ સિંગલ માસ્ટર છે. ત્યાં એક પ્રાથમિક છે - તે રેકોર્ડ્સ લઈ શકે છે જે તેમાં રહેલી કીને સપોર્ટ કરે છે. તમે મલ્ટિ-માસ્ટર લખી શકતા નથી.

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

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

ઘટકો કારણભૂત સુસંગતતા

મેં લગભગ 230 લેખો ગણ્યા છે જે આ વિષય પર પ્રકાશિત થયા છે - લેસ્લી લેમ્પર્ટ તરફથી. હવે મારી સ્મૃતિમાંથી હું તમને આ સામગ્રીના કેટલાક ભાગો પહોંચાડીશ.

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

પ્રતિબંધો

ત્યાં કયા પ્રતિબંધો છે? આ વાસ્તવમાં મુખ્ય મુદ્દાઓમાંનો એક છે, કારણ કે ઉત્પાદન પ્રણાલી જે પ્રતિબંધો લાદે છે તે શૈક્ષણિક લેખોમાં અસ્તિત્વમાં રહેલા પ્રતિબંધોથી ખૂબ જ અલગ છે. તેઓ ઘણીવાર તદ્દન કૃત્રિમ હોય છે.

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

સામાન્ય રીતે, આ બધા પ્રતિબંધો લાદે છે.

કારણભૂત સુસંગતતા ઘટકો

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

સંપૂર્ણ નિર્ભરતા ટ્રેકિંગ

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

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

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

સ્પષ્ટ નિર્ભરતા ટ્રેકિંગ

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

તેણી જુએ છે કે રેકોર્ડ 5 રેકોર્ડ્સ 1, 2, 3, 4 પર આધાર રાખે છે - તે મુજબ, પેનીના એક્સેસ નિર્ણય દ્વારા કરાયેલા ફેરફારોની ઍક્સેસ ક્લાયન્ટને મળે તે પહેલાં તેણી રાહ જુએ છે, જ્યારે અગાઉના તમામ ફેરફારો ડેટાબેઝમાંથી પસાર થઈ ગયા છે.

આ અમને અનુકૂળ નથી, કારણ કે હજી પણ ઘણી બધી માહિતી છે, અને તે વસ્તુઓને ધીમું કરશે. બીજો અભિગમ છે...

લેમ્પપોર્ટ ઘડિયાળ

તેઓ ખૂબ વૃદ્ધ છે. લેમપોર્ટ ઘડિયાળનો અર્થ એ છે કે આ અવલંબન એક સ્કેલર ફંક્શનમાં ફોલ્ડ કરવામાં આવે છે, જેને લેમપોર્ટ ઘડિયાળ કહેવામાં આવે છે.

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

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

તમે જુઓ છો કે ફીડ પરનો કાઉન્ટર સમય તાર્કિક રીતે કેવી રીતે વધે છે:

તેથી આ લેમપોર્ટ ઘડિયાળની મુખ્ય મિલકત અને કારણ સુસંગતતા (લેમપોર્ટ ઘડિયાળ દ્વારા સમજાવાયેલ) આ છે: જો આપણી પાસે ઇવેન્ટ્સ A અને B હોય, અને ઇવેન્ટ B ઇવેન્ટ A* પર આધારિત હોય, તો તે અનુસરે છે કે ઇવેન્ટ A નો લોજિકલ ટાઇમ કરતાં ઓછો છે. ઇવેન્ટ Bમાંથી લોજિકલ ટાઈમ.

* કેટલીકવાર તેઓ એમ પણ કહે છે કે A B પહેલાં થયું હતું, એટલે કે A B પહેલાં થયું હતું - આ એક ચોક્કસ સંબંધ છે જે સામાન્ય રીતે બનેલી ઘટનાઓના સંપૂર્ણ સેટને આંશિક રીતે ઓર્ડર કરે છે.

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

વેક્ટર ઘડિયાળ

લેમપોર્ટ ઘડિયાળનો તાર્કિક વિકાસ વેક્ટર ઘડિયાળ છે. તેઓ અલગ છે કે અહીં દરેક નોડ તેની પોતાની અલગ ઘડિયાળ ધરાવે છે, અને તે વેક્ટર તરીકે પ્રસારિત થાય છે.
આ કિસ્સામાં, તમે જોશો કે વેક્ટરનો શૂન્ય ઇન્ડેક્સ ફીડ માટે જવાબદાર છે, અને વેક્ટરનો પ્રથમ ઇન્ડેક્સ મિત્રો (આ દરેક નોડ્સ) માટે છે. અને હવે તેઓ વધશે: “ફીડ” નો શૂન્ય ઇન્ડેક્સ લખતી વખતે વધે છે – 1, 2, 3:

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

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

સ્પેનર ટ્રુટાઇમ. અણુ ઘડિયાળ

મેં કહ્યું કે સ્પેનર વિશે એક વાર્તા હશે. આ એક સરસ વસ્તુ છે, સીધી XNUMXમી સદીની: અણુ ઘડિયાળો, જીપીએસ સિંક્રનાઇઝેશન.

શું વિચાર છે? “સ્પૅનર” એ Google સિસ્ટમ છે જે તાજેતરમાં લોકો માટે પણ ઉપલબ્ધ બની છે (તેઓએ તેમાં SQL ઉમેર્યું છે). દરેક વ્યવહારમાં અમુક સમય સ્ટેમ્પ હોય છે. સમય સમન્વયિત હોવાથી, દરેક ઘટનાને ચોક્કસ સમય સોંપી શકાય છે - અણુ ઘડિયાળોમાં રાહ જોવાનો સમય હોય છે, જે પછી અલગ સમય "થવાની" ખાતરી આપવામાં આવે છે.

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

* લેમ્પર્ટ ઘડિયાળોની આ મુખ્ય સમસ્યા છે - તે વિતરિત સિસ્ટમો પર ક્યારેય સિંક્રનસ થતી નથી. તેઓ અલગ થઈ શકે છે; NTP સાથે પણ, તેઓ હજુ પણ ખૂબ સારી રીતે કામ કરતા નથી. "સ્પૅનર" પાસે અણુ ઘડિયાળ છે અને સિંક્રનાઇઝેશન, એવું લાગે છે, માઇક્રોસેકન્ડ્સ છે.

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

હાઇબ્રિડ ઘડિયાળ

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

• પ્રથમ યુનિક્સ યુગ છે ("કોમ્પ્યુટર વિશ્વની શરૂઆત" પછી કેટલી સેકંડ પસાર થઈ ગઈ છે).
• બીજું અમુક ઇન્ક્રીમેન્ટ છે, એ પણ 32-બીટ અનસાઇન ઇન્ટ.

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

MongoDB માટે આ કેમ મહત્વનું છે? કારણ કે તે તમને ચોક્કસ સમયે અમુક પ્રકારના બેકઅપ રેસ્ટોરન્ટ્સ બનાવવાની મંજૂરી આપે છે, એટલે કે, ઇવેન્ટ સમય દ્વારા અનુક્રમિત થાય છે. જ્યારે ચોક્કસ ઘટનાઓની જરૂર હોય ત્યારે આ મહત્વપૂર્ણ છે; ડેટાબેઝ માટે, ઇવેન્ટ્સ એ ડેટાબેઝમાં થતા ફેરફારો છે જે સમયના અમુક અંતરાલોમાં થાય છે.

હું તમને ફક્ત તમારા માટે સૌથી મહત્વપૂર્ણ કારણ કહીશ (કૃપા કરીને, કોઈને કહો નહીં)! અમે આ કર્યું કારણ કે આ તે છે જે સંગઠિત, અનુક્રમિત ડેટા MongoDB OpLog માં જેવો દેખાય છે. OpLog એ ડેટા સ્ટ્રક્ચર છે જેમાં ડેટાબેઝમાં સંપૂર્ણપણે તમામ ફેરફારો શામેલ છે: તેઓ પ્રથમ OpLog પર જાય છે, અને પછી જ્યારે તે નકલ કરેલી તારીખ અથવા શાર્ડ હોય ત્યારે તે સ્ટોરેજ પર જ લાગુ થાય છે.

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

ઘડિયાળ સિંક્રનાઇઝેશન

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

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

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

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

તે બધા એકસાથે કેવી રીતે કામ કરે છે?

અહીં હું તેને થોડી સરળ બનાવવા માટે એક પ્રતિકૃતિ સેટ જોઈ રહ્યો છું. ત્યાં પ્રાથમિક અને માધ્યમિક છે. ગૌણ પ્રતિકૃતિ કરે છે અને હંમેશા પ્રાથમિક સાથે સંપૂર્ણપણે સમન્વયિત થતું નથી.

એક નિવેશ ચોક્કસ સમય મૂલ્ય સાથે "પ્રાઈમરી" માં થાય છે. જો આ મહત્તમ હોય તો આ દાખલ આંતરિક ગણતરીમાં 11નો વધારો કરે છે. અથવા તે ઘડિયાળના મૂલ્યોને તપાસશે અને ઘડિયાળના મૂલ્યો વધારે હોય તો ઘડિયાળ સાથે સમન્વયિત કરશે. આ તમને સમય દ્વારા ગોઠવવાની મંજૂરી આપે છે.

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

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

જે મૂલ્ય પહેલાથી જ “Oplog” પર લખાયેલું છે તે પરત કરવામાં આવે છે - આપણે જાણીએ છીએ કે “Oplog” માં આ મૂલ્ય પહેલેથી જ છે, અને તેનો સમય 12 છે. હવે કહો કે, વાંચન બીજા નોડ (સેકન્ડરી) થી શરૂ થાય છે, અને તે ક્લસ્ટર ટાઈમ પછી પ્રસારિત થાય છે. સંદેશ. તે કહે છે: "મને તે બધું જોઈએ છે જે ઓછામાં ઓછું 12 પછી અથવા બાર દરમિયાન થયું હતું" (ઉપરનું ચિત્ર જુઓ).

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

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

તે બધું કેવી રીતે કાર્ય કરે છે તે ખૂબ જ છે. લગભગ.

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

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

તે સ્પષ્ટ છે કે આ પછી સિસ્ટમ કંઈપણ માટે સંપૂર્ણપણે અગમ્ય બની જાય છે. તે ફક્ત અનલોડ અને સાફ કરી શકાય છે - ઘણું મેન્યુઅલ કામ. સંપૂર્ણ ઉપલબ્ધતા:

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

અમારો રસ્તો ક્લસ્ટર ટાઈમ પર સહી કરવાનો છે

આ રીતે તે સંદેશમાં પ્રસારિત થાય છે (વાદળી ટેક્સ્ટ પહેલાં). પરંતુ અમે એક સહી (વાદળી લખાણ) જનરેટ કરવાનું પણ શરૂ કર્યું:

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

આ કિસ્સામાં કારણભૂત સુસંગતતાનો ઉપયોગ કરવાનો અર્થ શું છે? આ afterClusterTime પરિમાણ બતાવવા માટે છે. આ વિના, તે કોઈપણ રીતે મૂલ્યો પસાર કરશે. ગપસપ, આવૃત્તિ 3.6 થી શરૂ કરીને, હંમેશા કામ કરે છે.

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

તે ઝડપથી કરો!

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

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

આપણે શું શીખ્યા?

આમાંથી આપણે શીખ્યા પાઠ:

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

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

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

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

હું આ સાથે સમાપ્ત કરીશ. આભાર!

પ્રશ્નો

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

MT: - ખરેખર મહાન પ્રશ્ન! હું માત્ર shards વિશે વાત કરવા માંગતો હતો. જો હું પ્રશ્નને યોગ્ય રીતે સમજી શકું, તો આપણી પાસે નીચેની પરિસ્થિતિ છે: ત્યાં શાર્ડ 1 અને શાર્ડ 2 છે, આ બે શાર્ડમાંથી વાંચન થાય છે - તેમાં વિસંગતતા છે, તેઓ એકબીજા સાથે ક્રિયાપ્રતિક્રિયા કરતા નથી, કારણ કે તેઓ જે સમય જાણે છે તે અલગ છે, ખાસ કરીને સમય કે જ્યારે તેઓ oplogs માં અસ્તિત્વ ધરાવે છે.
ચાલો કહીએ કે શાર્ડ 1 એ એક મિલિયન રેકોર્ડ બનાવ્યા, શાર્ડ 2 એ કંઈ જ કર્યું નથી, અને વિનંતી બે શાર્ડ પર આવી. અને પ્રથમમાં એક મિલિયનથી વધુનો આફ્ટરક્લસ્ટર ટાઈમ છે. આવી સ્થિતિમાં, મેં સમજાવ્યું તેમ, શાર્ડ 2 ક્યારેય જવાબ આપશે નહીં.

IN: - હું જાણવા માંગુ છું કે તેઓ કેવી રીતે સિંક્રનાઇઝ કરે છે અને એક તાર્કિક સમય પસંદ કરે છે?

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

IN: - જો આ પછી તેની પાસે બીજી કેટલીક ઘટનાઓ આવે જે નેટવર્કમાં ક્યાંક ખોવાઈ ગઈ હોય તો?

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

IN: - મને કતારોને લગતા ઘણા પ્રશ્નો છે. કાર્યકારણ સુસંગતતા ધારે છે કે ક્રિયાઓની ચોક્કસ કતાર છે જે કરવાની જરૂર છે. જો અમારું એક પેકેજ અદૃશ્ય થઈ જાય તો શું થશે? અહીં 10મી, 11મી આવે છે... 12મી અદ્રશ્ય થઈ ગઈ છે, અને બાકીના બધા તે સાકાર થવાની રાહ જોઈ રહ્યા છે. અને અચાનક અમારી કાર મરી ગઈ, અમે કંઈ કરી શકતા નથી. શું કતારની મહત્તમ લંબાઈ છે જે એક્ઝિક્યુટ થતા પહેલા એકઠી થાય છે? જ્યારે કોઈ એક રાજ્ય ખોવાઈ જાય ત્યારે કઈ ઘાતક નિષ્ફળતા થાય છે? તદુપરાંત, જો આપણે લખી લઈએ કે કોઈ અગાઉની સ્થિતિ છે, તો આપણે કોઈક રીતે તેમાંથી શરૂઆત કરવી જોઈએ? પરંતુ તેઓએ તેને દૂર ધકેલ્યો નહીં!

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

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

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

MT: - હું હવે સ્પષ્ટ કરીશ. શાર્ડ (એટલે ​​​​કે આડું પાર્ટીશન) - ત્યાં હંમેશા પ્રાથમિક હોય છે. અને શાર્ડમાં "માસ્ટર" હોઈ શકે છે અને ત્યાં પ્રતિકૃતિઓ હોઈ શકે છે. પરંતુ શાર્ડ હંમેશા રેકોર્ડિંગને સપોર્ટ કરે છે, કારણ કે તે અમુક ડોમેનને સપોર્ટ કરે છે (શાર્ડમાં પ્રાથમિક હોય છે).

IN: - તો બધું સંપૂર્ણપણે "માસ્ટર" પર આધારિત છે? શું મુખ્ય સમયનો હંમેશા ઉપયોગ થાય છે?

MT: - હા. તમે અલંકારિક રીતે કહી શકો છો: જ્યારે “માસ્ટર” માં, “ઓપલોગ” માં પ્રવેશ થાય છે ત્યારે ઘડિયાળ ટિક કરી રહી છે.

IN: - અમારી પાસે એક ક્લાયંટ છે જે કનેક્ટ કરે છે અને સમય વિશે કંઈપણ જાણવાની જરૂર નથી?

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

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

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

IN: – કોમ્પ્યુટ સાયન્સનું નવું સ્તર – CRDT (કોન્ફ્લિક્ટ-ફ્રી રેપ્લિકેટેડ ડેટા ટાઈપ્સ) ડેટા પ્રકારો – ઘટનાત્મક સુસંગતતાના વિષય સાથે મજબૂત રીતે સંબંધિત છે. શું તમે ડેટાબેઝમાં આ પ્રકારના ડેટાને એકીકૃત કરવાનું વિચાર્યું છે અને તમે તેના વિશે શું કહી શકો?

MT: - સારો પ્રશ્ન! CRDT લખાણ તકરાર માટે અર્થપૂર્ણ છે: MongoDB માં, સિંગલ માસ્ટર.

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

MT: - પરિમિતિની અંદરના દુષ્ટ લોકો ટ્રોજન હોર્સ જેવા છે! પરિમિતિની અંદરના દુષ્ટ લોકો ઘણું ખરાબ કરી શકે છે.

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

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

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

IN: – સંરક્ષિત પરિમિતિમાં, કોઈએ સર્વરને સંપૂર્ણપણે નાશ કરવા માટે સર્વર માટે અનપેક્ષિત પ્રોટોકોલ બનાવવાનો પ્રયાસ કર્યો, અને જો તમે નસીબદાર છો, તો આખું ક્લસ્ટર... શું તે ક્યારેય તે "સારું" મેળવે છે?

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

IN: - અહેવાલ માટે આભાર. સેર્ગેઈ (યાન્ડેક્ષ). મોંગમાં એક સ્થિરાંક છે જે પ્રતિકૃતિ સમૂહમાં મતદાન કરનારા સભ્યોની સંખ્યાને મર્યાદિત કરે છે, અને આ સ્થિરાંક 7 (સાત) છે. શા માટે આ સતત છે? શા માટે આ કોઈ પ્રકારનું પરિમાણ નથી?

MT: - અમારી પાસે 40 નોડ્સ સાથે પ્રતિકૃતિ સેટ છે. હંમેશા બહુમતી હોય છે. મને ખબર નથી કે કયું સંસ્કરણ...

IN: – રેપ્લિકા સેટમાં તમે નોન-વોટિંગ મેમ્બર્સ ચલાવી શકો છો, પરંતુ ત્યાં વધુમાં વધુ 7 વોટિંગ મેમ્બર્સ હોય છે. જો અમારો રેપ્લિકા સેટ 3 ડેટા સેન્ટરમાં ફેલાયેલો હોય તો આ કિસ્સામાં અમે શટડાઉનમાંથી કેવી રીતે બચી શકીએ? એક ડેટા સેન્ટર સરળતાથી બંધ થઈ શકે છે, અને બીજું મશીન બહાર પડી શકે છે.

MT: - આ પહેલેથી જ રિપોર્ટના અવકાશની બહાર છે. આ એક સામાન્ય પ્રશ્ન છે. કદાચ હું તમને તેના વિશે પછીથી કહી શકું.

કેટલીક જાહેરાતો 🙂

અમારી સાથે રહેવા બદલ આભાર. શું તમને અમારા લેખો ગમે છે? વધુ રસપ્રદ સામગ્રી જોવા માંગો છો? ઓર્ડર આપીને અથવા મિત્રોને ભલામણ કરીને અમને ટેકો આપો, $4.99 થી વિકાસકર્તાઓ માટે ક્લાઉડ VPS, એન્ટ્રી-લેવલ સર્વર્સનું એક અનન્ય એનાલોગ, જેની શોધ અમારા દ્વારા તમારા માટે કરવામાં આવી છે: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps વિશેનું સંપૂર્ણ સત્ય $19 થી અથવા સર્વર કેવી રીતે શેર કરવું? (RAID1 અને RAID10 સાથે ઉપલબ્ધ, 24 કોરો સુધી અને 40GB DDR4 સુધી).

એમ્સ્ટરડેમમાં ઇક્વિનિક્સ ટાયર IV ડેટા સેન્ટરમાં ડેલ R730xd 2 ગણું સસ્તું? માત્ર અહીં 2 x ઇન્ટેલ ટેટ્રાડેકા-કોર Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ટીવી $199 થી નેધરલેન્ડમાં! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 થી! વિશે વાંચો ઇન્ફ્રાસ્ટ્રક્ચર કોર્પોરેશન કેવી રીતે બનાવવું. ડેલ R730xd E5-2650 v4 સર્વર્સના ઉપયોગ સાથેનો વર્ગ એક પેની માટે 9000 યુરોના મૂલ્યના છે?

સોર્સ: www.habr.com