કસાન્ડ્રા. જો તમે ફક્ત ઓરેકલને જાણતા હોવ તો કેવી રીતે મૃત્યુ પામવું નહીં

હે હબર.

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

કસાન્ડ્રા વિશે શું સારું છે? તે એક NoSQL ડેટાબેઝ છે જે નિષ્ફળતાના એક પણ બિંદુ વિના ડિઝાઇન કરવામાં આવ્યો છે જે સારી રીતે માપે છે. જો તમારે કેટલાક ડેટાબેઝ માટે બે ટેરાબાઇટ ઉમેરવાની જરૂર હોય, તો તમે ફક્ત રિંગમાં નોડ્સ ઉમેરો. તેને બીજા ડેટા સેન્ટરમાં વિસ્તૃત કરીએ? ક્લસ્ટરમાં નોડ્સ ઉમેરો. પ્રોસેસ્ડ આરપીએસ વધારો? ક્લસ્ટરમાં નોડ્સ ઉમેરો. તે વિપરીત દિશામાં પણ કામ કરે છે.

તેણી બીજું શું સારી છે? તે ઘણી બધી વિનંતીઓને હેન્ડલ કરવા વિશે છે. પરંતુ ઘણું કેટલું છે? 10, 20, 30, 40 હજાર રિક્વેસ્ટ પ્રતિ સેકન્ડ વધારે નથી. રેકોર્ડિંગ માટે પ્રતિ સેકન્ડ 100 હજાર વિનંતીઓ - પણ. એવી કંપનીઓ છે જેણે કહ્યું કે તેઓ પ્રતિ સેકન્ડ 2 મિલિયન વિનંતીઓ રાખે છે. તેઓએ કદાચ તે માનવું પડશે.

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

સમાન દેખાતી દરેક વસ્તુ સરખી રીતે કામ કરતી નથી

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

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

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

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

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

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

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

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

આ કિસ્સામાં પ્રાથમિક કી એક કોલમ ધરાવે છે, અને તે પાર્ટીશનીંગ કી પણ છે.

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

પસંદ કરો: જ્યારે ફિલ્ટરિંગને સંપૂર્ણ સ્કેનમાં ફેરવવાની મંજૂરી આપો, અથવા શું ન કરવું

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

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

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

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

આ ખરેખર એક વૃક્ષ છે, એક તુલનાકારને ફક્ત ત્યાં કહેવામાં આવે છે, જેના પર આપણે ઑબ્જેક્ટના રૂપમાં કૉલમનો ચોક્કસ સેટ પસાર કરીએ છીએ, અને તે કૉલમ્સની સૂચિ તરીકે પણ ઉલ્લેખિત છે.

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

અમે સૉર્ટિંગ સેટ કરીએ છીએ અને પ્રતિબંધો લાદીએ છીએ

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

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

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

કોઈપણ અસ્પષ્ટ પરિસ્થિતિમાં, એક નવું ટેબલ બનાવો

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

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

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

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

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

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

અને સૌથી મહત્વની બાબત: જો આપણે સમાન ડેટાને 100 અલગ અલગ રીતે પુનઃપ્રાપ્ત કરવાની જરૂર હોય, તો આપણી પાસે 100 અલગ-અલગ કોષ્ટકો હશે.

સોર્સ: www.habr.com