ડેટા, સ્થિરતા અને NoSQL માં વિશ્વાસ ગુમાવ્યા વિના કેવી રીતે કેસન્ડ્રાની આંખોમાં જોવું

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

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

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

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

તેથી, આ તે છે જે અમને અનુભવે છે

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

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

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

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

અમને ટેસ્ટ ઝોનમાં ડેટા ટ્રાન્સફર કરવામાં સમસ્યા આવી (પ્રોમમાં 5 વિરુદ્ધ પરીક્ષણમાં 20 ગાંઠો). આ કિસ્સામાં, ડમ્પનો ઉપયોગ કરી શકાતો નથી.

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

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

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

અમે કેવી રીતે નક્કી કર્યું

નોડને ડૂબતા અટકાવવા માટે, SWAP અક્ષમ કરવામાં આવ્યું હતું. અને હવે, જો મેમરીનો અભાવ હોય, તો નોડ નીચે જવું જોઈએ અને મોટા જીસી વિરામ બનાવવું જોઈએ નહીં.

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

અમે DataStax પાસેથી સપોર્ટ ખરીદ્યો છે. બોક્સવાળી કેસાન્ડ્રાનો વિકાસ પહેલેથી જ બંધ થઈ ગયો છે (છેલ્લી કમિટ ફેબ્રુઆરી 2018 માં હતી). તે જ સમયે, Datastax શ્રેષ્ઠ સેવા અને હાલના IP ઉકેલો માટે મોટી સંખ્યામાં સંશોધિત અને અનુકૂલિત ઉકેલો પ્રદાન કરે છે.

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

અમે બે વિકલ્પો ધ્યાનમાં લીધા છે. પ્રથમ વિકલ્પમાં, અમે ફક્ત C* માં જ નહીં, પણ આર્કાઇવ કરેલા Oracle ડેટાબેઝમાં પણ કૉલ્સ લખીએ છીએ. ફક્ત, C* થી વિપરીત, આ ડેટાબેઝ ફક્ત વર્તમાન મહિના માટે જ કૉલ્સ સ્ટોર કરે છે (કેસો રિચાર્જ કરવા માટે પૂરતી કૉલ સ્ટોરેજ ડેપ્થ). અહીં આપણે તરત જ નીચેની સમસ્યા જોઈ: જો આપણે સિંક્રનસ રીતે લખીએ, તો આપણે ઝડપી નિવેશ સાથે સંકળાયેલા C* ના તમામ ફાયદા ગુમાવી દઈએ છીએ; જો આપણે અસુમેળ રીતે લખીએ, તો ત્યાં કોઈ ગેરેંટી નથી કે બધા જરૂરી કોલ્સ ઓરેકલમાં જ આવ્યા છે. ત્યાં એક વત્તા હતી, પરંતુ એક મોટો: ઓપરેશન માટે સમાન પરિચિત PL/SQL ડેવલપર રહે છે, એટલે કે અમે વ્યવહારિક રીતે "ફેકેડ" પેટર્નનો અમલ કરીએ છીએ. વૈકલ્પિક વિકલ્પ. અમે એક મિકેનિઝમ અમલમાં મૂકીએ છીએ જે C* માંથી કૉલ્સને અનલોડ કરે છે, Oracle માં સંબંધિત કોષ્ટકોમાંથી સંવર્ધન માટે અમુક ડેટા ખેંચે છે, પરિણામી નમૂનાઓ સાથે જોડાય છે અને અમને પરિણામ આપે છે, જેનો આપણે કોઈક રીતે ઉપયોગ કરીએ છીએ (રોલ બેક, પુનરાવર્તન, વિશ્લેષણ, પ્રશંસા). વિપક્ષ: પ્રક્રિયા તદ્દન મલ્ટિ-સ્ટેપ છે, અને વધુમાં, ઓપરેશન કર્મચારીઓ માટે કોઈ ઇન્ટરફેસ નથી.

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

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

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

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

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

પરિણામે, હમણાં માટે EACH_QUORUM લખવા માટે સુસંગતતા સ્તરે, વાંચવા માટે - LOCAL_QUORUM

સંક્ષિપ્ત છાપ અને તારણો

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

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

જેમ તમે જોઈ શકો છો, ભંડાર વિશાળ અને વૈવિધ્યસભર છે. અને જો આપણે NoSQL ના સમર્થકો/વિરોધીઓની શિબિર પસંદ કરીએ, તો અમે સમર્થકો સાથે જોડાઈશું, કારણ કે અમને અમારા ફાયદા મળ્યા છે, અને અમે અપેક્ષા રાખીએ છીએ.

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

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

ઉદાહરણ તરીકે, સમયસર રીતે Cassandra ના અપડેટ્સનો ટ્રૅક રાખોકારણ કે અમને મળેલી કેટલીક સમસ્યાઓ પહેલાથી જ જાણીતી અને નિશ્ચિત હતી.

ડેટાબેઝ પોતે અને સ્પાર્ક બંનેને સમાન નોડ્સ પર ન મૂકશો (અથવા સ્વીકાર્ય સંસાધન વપરાશની માત્રા દ્વારા સખત રીતે વિભાજીત કરો), કારણ કે સ્પાર્ક અપેક્ષા કરતા વધુ OP ખાઈ શકે છે, અને અમને અમારી સૂચિમાંથી સમસ્યા નંબર 1 ઝડપથી મળશે.

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

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

ખરાબ નથી TTL જોડવા અને જૂના ડેટાને સાફ કરવા માટે તાત્કાલિક પ્રદાન કરો.

Cassandra માંથી ડેટા ડાઉનલોડ કરતી વખતે એપ્લિકેશન લોજિક FETCH સિદ્ધાંત પર કામ કરવું જોઈએ, જેથી બધી પંક્તિઓ એક જ સમયે મેમરીમાં લોડ ન થાય, પરંતુ બેચમાં પસંદ કરવામાં આવે.

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

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

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

સોર્સ: www.habr.com