NewSQL = NoSQL+ACID

તાજેતરમાં સુધી, ઓડનોક્લાસ્નીકી એસક્યુએલ સર્વરમાં રીઅલ ટાઇમમાં પ્રોસેસ કરેલ લગભગ 50 TB ડેટા સંગ્રહિત કરે છે. આવા વોલ્યુમ માટે, SQL DBMS નો ઉપયોગ કરીને ઝડપી અને વિશ્વસનીય, અને ડેટા સેન્ટરની નિષ્ફળતા-સહિષ્ણુ ઍક્સેસ પ્રદાન કરવી લગભગ અશક્ય છે. સામાન્ય રીતે, આવા કિસ્સાઓમાં, NoSQL સ્ટોરેજમાંથી એકનો ઉપયોગ કરવામાં આવે છે, પરંતુ બધું NoSQL માં ટ્રાન્સફર કરી શકાતું નથી: કેટલીક સંસ્થાઓને ACID ટ્રાન્ઝેક્શન ગેરંટી જરૂરી છે.

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

તે કેવી રીતે કાર્ય કરે છે અને શું થયું - કટ હેઠળ વાંચો.

આજે, ઓડનોક્લાસ્નીકીના માસિક પ્રેક્ષકો 70 મિલિયનથી વધુ અનન્ય મુલાકાતીઓ છે. અમે અમે ટોચના પાંચમાં છીએ વિશ્વના સૌથી મોટા સામાજિક નેટવર્ક્સ, અને વીસ સાઇટ્સ પૈકી કે જેના પર વપરાશકર્તાઓ સૌથી વધુ સમય વિતાવે છે. ઓકે ઈન્ફ્રાસ્ટ્રક્ચર ખૂબ જ ઊંચા લોડને હેન્ડલ કરે છે: ફ્રન્ટ દીઠ એક મિલિયન કરતાં વધુ HTTP વિનંતીઓ/સેકન્ડ. 8000 થી વધુ ટુકડાઓના સર્વર કાફલાના ભાગો એકબીજાની નજીક સ્થિત છે - ચાર મોસ્કો ડેટા સેન્ટર્સમાં, જે તેમની વચ્ચે 1 ms કરતાં ઓછી નેટવર્ક લેટન્સી માટે પરવાનગી આપે છે.

અમે વર્ઝન 2010 થી શરૂ કરીને, 0.6 થી Cassandra નો ઉપયોગ કરી રહ્યા છીએ. આજે ઘણા ડઝન ક્લસ્ટર કાર્યરત છે. સૌથી ઝડપી ક્લસ્ટર પ્રતિ સેકન્ડમાં 4 મિલિયનથી વધુ કામગીરીની પ્રક્રિયા કરે છે અને સૌથી મોટું 260 TB સ્ટોર કરે છે.

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

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

શાર્ડિંગ અને SQL ને ઝડપી બનાવવા માટે આભાર:

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

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

SQL સાથે સમસ્યાઓ

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

પરંતુ મુખ્ય સમસ્યા છે

સહનશીલતા દોષ

ક્લાસિક SQL સર્વરની ખામી સહિષ્ણુતા નબળી છે. ચાલો કહીએ કે તમારી પાસે માત્ર એક ડેટાબેઝ સર્વર છે, અને તે દર ત્રણ વર્ષે એકવાર નિષ્ફળ જાય છે. આ સમય દરમિયાન સાઇટ 20 મિનિટ માટે ડાઉન છે, જે સ્વીકાર્ય છે. જો તમારી પાસે 64 સર્વર છે, તો દર ત્રણ અઠવાડિયે એકવાર સાઇટ ડાઉન થાય છે. અને જો તમારી પાસે 200 સર્વર છે, તો પછી સાઇટ દર અઠવાડિયે કામ કરતી નથી. આ સમસ્યા છે.

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

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

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

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

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

સરળ વ્યવહાર

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

1. અમે આલ્બમને કી દ્વારા લૉક કરીએ છીએ.
2. ફોટો ટેબલમાં એન્ટ્રી બનાવો.
3. જો ફોટોની સાર્વજનિક સ્થિતિ છે, તો પછી આલ્બમમાં સાર્વજનિક ફોટો કાઉન્ટર ઉમેરો, રેકોર્ડ અપડેટ કરો અને વ્યવહાર કરો.

અથવા સ્યુડોકોડમાં:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

અમે જોઈએ છીએ કે બિઝનેસ ટ્રાન્ઝેક્શન માટે સૌથી સામાન્ય દૃશ્ય એ છે કે ડેટાબેઝમાંથી ડેટાને એપ્લિકેશન સર્વરની મેમરીમાં વાંચવો, કંઈક બદલવું અને ડેટાબેઝમાં પાછા નવા મૂલ્યોને સાચવવું. સામાન્ય રીતે આવા ટ્રાન્ઝેક્શનમાં આપણે ઘણી એન્ટિટી, અનેક ટેબલ અપડેટ કરીએ છીએ.

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

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

અન્ય, ઓછી મહત્વની નથી, જરૂરિયાતો હતી:

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

નિર્ણયો, નિર્ણયો

સંભવિત ઉકેલોનું વિશ્લેષણ કરીને, અમે બે સંભવિત આર્કિટેક્ચર પસંદગીઓ પર આવ્યા:

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

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

Cassandra અને CQL

તો, કસાન્ડ્રા વિશે શું રસપ્રદ છે, તેની પાસે કઈ ક્ષમતાઓ છે?

સૌપ્રથમ, અહીં તમે કોષ્ટકો બનાવી શકો છો જે વિવિધ ડેટા પ્રકારોને સપોર્ટ કરે છે; તમે પ્રાથમિક કી પર સિલેક્ટ અથવા અપડેટ કરી શકો છો.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

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

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

કેસાન્ડ્રામાં વ્યવહારોની સૌથી નજીકની વસ્તુ કહેવાતા છે “હળવા વ્યવહારો" પરંતુ તેઓ "વાસ્તવિક" ACID વ્યવહારોથી દૂર છે: હકીકતમાં, આ કરવાની તક છે સીએએસ હેવીવેઇટ પૉક્સોસ પ્રોટોકોલનો ઉપયોગ કરીને સર્વસંમતિનો ઉપયોગ કરીને માત્ર એક રેકોર્ડમાંથી ડેટા પર. તેથી, આવા વ્યવહારોની ઝડપ ઓછી છે.

અમે Cassandra માં શું ખૂટે છે

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

સી*એક

આમ એક નવા DBMS નો જન્મ થયો સી*એક, જેમાં ત્રણ પ્રકારના સર્વર નોડ્સનો સમાવેશ થાય છે:

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

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

ગ્રાહકો

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

C*વન ટ્રાન્ઝેક્શન કોઓર્ડિનેટર

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

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

તાળાઓ

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

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

અમારા કિસ્સામાં ડેટા પહેલેથી જ SQL માં સ્થાનિક વ્યવહારોના જૂથો વચ્ચે વિતરિત કરવામાં આવ્યો હોવાથી, સ્થાનિક વ્યવહાર જૂથોને સંકલનકર્તાઓને સોંપવાનું નક્કી કરવામાં આવ્યું હતું: એક સંયોજક 0 થી 9 ના ટોકન્સ સાથે તમામ વ્યવહારો કરે છે, બીજો - 10 થી 19 ના ટોકન્સ સાથે, અને તેથી વધુ. પરિણામે, દરેક સંયોજક ઉદાહરણો વ્યવહાર જૂથના માસ્ટર બની જાય છે.

પછી તાળાઓ સંયોજકની યાદમાં મામૂલી હેશમેપના રૂપમાં લાગુ કરી શકાય છે.

સંયોજક નિષ્ફળતાઓ

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

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

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

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

પરંતુ તે ઝડપથી સમજવા માટે પૂરતું નથી કે કયા નોડે કાર્ય કરવાનું બંધ કર્યું છે. આપણે આ વિશે કંઈક કરવાની જરૂર છે.

આરક્ષણ

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

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

આ યોજના સાર્વત્રિક અલ્ગોરિધમ કરતાં વધુ વિશ્વસનીય છે, કારણ કે નવા માસ્ટરને સક્રિય કરવા માટે તે જૂનાની નિષ્ફળતા નક્કી કરવા માટે પૂરતું છે.

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

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

વ્યવહાર કેવી રીતે કાર્ય કરે છે

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

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

જ્યારે ક્લાયંટ સક્રિય વ્યવહારના ભાગ રૂપે તેના પોતાના બદલાયેલ ડેટાની વિનંતી કરે છે, ત્યારે સંયોજક નીચે મુજબ કાર્ય કરે છે:

• જો ID પહેલેથી જ વ્યવહારમાં છે, તો ડેટા મેમરીમાંથી લેવામાં આવે છે;
• જો મેમરીમાં કોઈ ID નથી, તો ગુમ થયેલ ડેટા સ્ટોરેજ નોડ્સમાંથી વાંચવામાં આવે છે, જે પહેલાથી મેમરીમાં છે તેની સાથે જોડાય છે, અને પરિણામ ક્લાયંટને આપવામાં આવે છે.

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

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

અને રોલબેક કરવા માટે, સંયોજકને માત્ર ટ્રાન્ઝેક્શન સ્ટેટ દ્વારા કબજે કરેલી મેમરીને મુક્ત કરવાની જરૂર છે.

ઉપરોક્ત સુધારાઓના પરિણામે, અમે ACID સિદ્ધાંતો લાગુ કર્યા છે:

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

અનુક્રમણિકાઓ દ્વારા વાંચન

ચાલો એક સરળ કોષ્ટક લઈએ:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

તેની પાસે ID (પ્રાથમિક કી), માલિક અને ફેરફારની તારીખ છે. તમારે ખૂબ જ સરળ વિનંતી કરવાની જરૂર છે - "છેલ્લા દિવસ માટે" ફેરફારની તારીખ સાથે માલિક પરનો ડેટા પસંદ કરો.

SELECT *
WHERE owner=?
AND modified>?

આવી ક્વેરી ઝડપથી પ્રક્રિયા કરવા માટે, ક્લાસિક SQL DBMS માં તમારે કૉલમ (માલિક, સંશોધિત) દ્વારા ઇન્ડેક્સ બનાવવાની જરૂર છે. અમે આ એકદમ સરળતાથી કરી શકીએ છીએ, કારણ કે હવે અમારી પાસે ACID ગેરંટી છે!

C*વન માં અનુક્રમણિકા

ફોટોગ્રાફ્સ સાથે એક સ્ત્રોત ટેબલ છે જેમાં રેકોર્ડ ID પ્રાથમિક કી છે.

ઇન્ડેક્સ માટે, C*One એક નવું ટેબલ બનાવે છે જે મૂળની નકલ છે. કી અનુક્રમણિકા અભિવ્યક્તિ જેવી જ છે, અને તેમાં સ્રોત કોષ્ટકમાંથી રેકોર્ડની પ્રાથમિક કી પણ શામેલ છે:

હવે "છેલ્લા દિવસ માટે માલિક" માટેની ક્વેરી અન્ય કોષ્ટકમાંથી પસંદગી તરીકે ફરીથી લખી શકાય છે:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

શું થયું

અમે ત્રણ વર્ષ પહેલાં C*One વિકસાવ્યું હતું અને તેને કોમર્શિયલ ઑપરેશનમાં લૉન્ચ કર્યું હતું.

અંતે આપણને શું મળ્યું? ચાલો ફોટો પ્રોસેસિંગ અને સ્ટોરેજ સબસિસ્ટમના ઉદાહરણનો ઉપયોગ કરીને તેનું મૂલ્યાંકન કરીએ, જે સોશિયલ નેટવર્કમાં ડેટાના સૌથી મહત્વપૂર્ણ પ્રકારોમાંનું એક છે. અમે ફોટોગ્રાફ્સના શરીર વિશે વાત કરી રહ્યા નથી, પરંતુ તમામ પ્રકારની મેટા-માહિતી વિશે. હવે ઓડનોક્લાસ્નીકી પાસે આવા લગભગ 20 બિલિયન રેકોર્ડ્સ છે, સિસ્ટમ પ્રતિ સેકન્ડ 80 હજાર વાંચવાની વિનંતીઓ પર પ્રક્રિયા કરે છે, ડેટા ફેરફાર સાથે સંકળાયેલા પ્રતિ સેકન્ડ 8 હજાર ACID વ્યવહારો.

જ્યારે અમે પ્રતિકૃતિ પરિબળ = 1 (પરંતુ RAID 10 માં) સાથે SQL નો ઉપયોગ કર્યો હતો, ત્યારે માઇક્રોસોફ્ટ એસક્યુએલ સર્વર (વત્તા 32 બેકઅપ્સ) ચલાવતા 11 મશીનોના અત્યંત ઉપલબ્ધ ક્લસ્ટર પર ફોટો મેટેનફોર્મેશન સંગ્રહિત કરવામાં આવ્યું હતું. બેકઅપ સ્ટોર કરવા માટે 10 સર્વર પણ ફાળવવામાં આવ્યા હતા. કુલ 50 મોંઘી કાર. તે જ સમયે, સિસ્ટમ અનામત વિના, રેટેડ લોડ પર કાર્યરત હતી.

નવી સિસ્ટમમાં સ્થળાંતર કર્યા પછી, અમને પ્રતિકૃતિ પરિબળ = 3 - દરેક ડેટા સેન્ટરમાં એક નકલ પ્રાપ્ત થઈ. સિસ્ટમમાં કુલ 63 સર્વર માટે 6 કસાન્ડ્રા સ્ટોરેજ નોડ્સ અને 69 કોઓર્ડિનેટર મશીનો છે. પરંતુ આ મશીનો ખૂબ સસ્તી છે, તેમની કુલ કિંમત SQL સિસ્ટમની કિંમતના લગભગ 30% જેટલી છે. તે જ સમયે, લોડ 30% પર રાખવામાં આવે છે.

સી*વનની રજૂઆત સાથે, લેટન્સીમાં પણ ઘટાડો થયો: એસક્યુએલમાં, લખવાની કામગીરીમાં લગભગ 4,5 એમએસનો સમય લાગ્યો. C*વન માં - લગભગ 1,6 ms. વ્યવહારની અવધિ સરેરાશ 40 ms કરતાં ઓછી છે, પ્રતિબદ્ધતા 2 ms માં પૂર્ણ થાય છે, વાંચવા અને લખવાની અવધિ સરેરાશ 2 ms છે. 99મી ટકાવારી - માત્ર 3-3,1 એમએસ, સમય સમાપ્તિની સંખ્યામાં 100 ગણો ઘટાડો થયો છે - આ બધું અટકળોના વ્યાપક ઉપયોગને કારણે છે.

અત્યાર સુધીમાં, મોટાભાગના SQL સર્વર નોડ્સ રદ કરવામાં આવ્યા છે; નવા ઉત્પાદનો ફક્ત C*One નો ઉપયોગ કરીને વિકસાવવામાં આવી રહ્યા છે. અમે અમારા ક્લાઉડમાં કામ કરવા માટે C*Oને અનુકૂલન કર્યું એક વાદળ, જેણે નવા ક્લસ્ટરોની જમાવટને ઝડપી બનાવવાનું, રૂપરેખાંકનને સરળ બનાવવું અને ઑટોમેટિક ઑપરેશન શક્ય બનાવ્યું. સ્ત્રોત કોડ વિના, આ કરવાનું વધુ મુશ્કેલ અને બોજારૂપ હશે.

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

સોર્સ: www.habr.com