കസാന്ദ്ര. ഒറാക്കിൾ മാത്രം അറിഞ്ഞാൽ എങ്ങനെ മരിക്കില്ല

ഹലോ, ഹബ്ർ.

എന്റെ പേര് മിഷ ബട്രിമോവ്, കസാന്ദ്രയെക്കുറിച്ച് കുറച്ച് പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. NoSQL ഡാറ്റാബേസുകൾ ഒരിക്കലും നേരിട്ടിട്ടില്ലാത്തവർക്ക് എന്റെ സ്റ്റോറി ഉപയോഗപ്രദമാകും - ഇതിന് ധാരാളം നടപ്പിലാക്കൽ സവിശേഷതകളും നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട കുഴപ്പങ്ങളും ഉണ്ട്. നിങ്ങൾ Oracle അല്ലെങ്കിൽ മറ്റേതെങ്കിലും റിലേഷണൽ ഡാറ്റാബേസ് അല്ലാതെ മറ്റൊന്നും കണ്ടിട്ടില്ലെങ്കിൽ, ഈ കാര്യങ്ങൾ നിങ്ങളുടെ ജീവൻ രക്ഷിക്കും.

കസാന്ദ്രയിൽ എന്താണ് നല്ലത്? ഒരു തകരാർ പോലും ഇല്ലാതെ രൂപകൽപന ചെയ്ത NoSQL ഡാറ്റാബേസാണ് ഇത്. ചില ഡാറ്റാബേസിനായി നിങ്ങൾക്ക് രണ്ട് ടെറാബൈറ്റുകൾ ചേർക്കണമെങ്കിൽ, നിങ്ങൾ റിംഗിലേക്ക് നോഡുകൾ ചേർക്കുക. മറ്റൊരു ഡാറ്റാ സെന്ററിലേക്ക് ഇത് വികസിപ്പിക്കണോ? ക്ലസ്റ്ററിലേക്ക് നോഡുകൾ ചേർക്കുക. പ്രോസസ്സ് ചെയ്ത RPS വർദ്ധിപ്പിക്കണോ? ക്ലസ്റ്ററിലേക്ക് നോഡുകൾ ചേർക്കുക. ഇത് വിപരീത ദിശയിലും പ്രവർത്തിക്കുന്നു.

അവൾ മറ്റെന്താണ് മിടുക്കൻ? ഇത് ഒരുപാട് അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യുന്നതിനെക്കുറിച്ചാണ്. എന്നാൽ ഒരുപാട് എന്നത് എത്രയാണ്? സെക്കൻഡിൽ 10, 20, 30, 40 ആയിരം അഭ്യർത്ഥനകൾ അധികമല്ല. റെക്കോർഡിംഗിനായി സെക്കൻഡിൽ 100 ​​ആയിരം അഭ്യർത്ഥനകൾ - അതും. സെക്കൻഡിൽ 2 ദശലക്ഷം അഭ്യർത്ഥനകൾ സൂക്ഷിക്കുന്നുവെന്ന് പറഞ്ഞ കമ്പനികളുണ്ട്. അവർ അത് വിശ്വസിക്കേണ്ടി വരും.

തത്വത്തിൽ, റിലേഷണൽ ഡാറ്റയിൽ നിന്ന് കസാന്ദ്രയ്ക്ക് ഒരു വലിയ വ്യത്യാസമുണ്ട് - അത് അവയ്ക്ക് സമാനമല്ല. കൂടാതെ ഇത് ഓർത്തിരിക്കേണ്ടത് വളരെ പ്രധാനമാണ്.

ഒരേ പോലെ കാണപ്പെടുന്ന എല്ലാം ഒരുപോലെ പ്രവർത്തിക്കില്ല

ഒരിക്കൽ ഒരു സഹപ്രവർത്തകൻ എന്റെ അടുത്ത് വന്ന് ചോദിച്ചു: “ഇതാ ഒരു CQL Cassandra അന്വേഷണ ഭാഷ, അതിൽ ഒരു തിരഞ്ഞെടുത്ത പ്രസ്താവനയുണ്ട്, അതിൽ എവിടെയുണ്ട്, ഉണ്ട്, ഉണ്ട്. ഞാൻ കത്തുകൾ എഴുതുന്നു, അത് പ്രവർത്തിക്കുന്നില്ല. എന്തുകൊണ്ട്?". കസാന്ദ്രയെ ഒരു റിലേഷണൽ ഡാറ്റാബേസ് പോലെ കൈകാര്യം ചെയ്യുന്നത് അക്രമാസക്തമായ ആത്മഹത്യ ചെയ്യാനുള്ള മികച്ച മാർഗമാണ്. ഞാൻ അത് പ്രൊമോട്ട് ചെയ്യുന്നില്ല, റഷ്യയിൽ ഇത് നിരോധിച്ചിരിക്കുന്നു. നിങ്ങൾ എന്തെങ്കിലും തെറ്റായി രൂപകൽപ്പന ചെയ്യും.

ഉദാഹരണത്തിന്, ഒരു ഉപഭോക്താവ് ഞങ്ങളുടെ അടുത്ത് വന്ന് പറയുന്നു: “നമുക്ക് ടിവി സീരീസിനായി ഒരു ഡാറ്റാബേസ് അല്ലെങ്കിൽ ഒരു പാചക ഡയറക്‌ടറിക്കായി ഒരു ഡാറ്റാബേസ് നിർമ്മിക്കാം. ഞങ്ങൾക്ക് അവിടെ ഭക്ഷണ വിഭവങ്ങളോ ടിവി സീരിയലുകളുടെയും അഭിനേതാക്കളുടെയും ഒരു ലിസ്റ്റ് ഉണ്ടായിരിക്കും. ഞങ്ങൾ സന്തോഷത്തോടെ പറയുന്നു: "നമുക്ക് പോകാം!" രണ്ട് ബൈറ്റുകൾ, രണ്ട് അടയാളങ്ങൾ അയയ്‌ക്കുക, നിങ്ങൾ പൂർത്തിയാക്കി, എല്ലാം വളരെ വേഗത്തിലും വിശ്വസനീയമായും പ്രവർത്തിക്കും. ഉപഭോക്താക്കൾ വന്ന് വീട്ടമ്മമാരും വിപരീത പ്രശ്നം പരിഹരിക്കുന്നുവെന്ന് പറയുന്നതുവരെ എല്ലാം ശരിയാണ്: അവർക്ക് ഉൽപ്പന്നങ്ങളുടെ ഒരു ലിസ്റ്റ് ഉണ്ട്, അവർ ഏത് വിഭവമാണ് പാചകം ചെയ്യാൻ ആഗ്രഹിക്കുന്നതെന്ന് അറിയാൻ അവർ ആഗ്രഹിക്കുന്നു. നിങ്ങൾ മരിച്ചു.

കാരണം, കസാന്ദ്ര ഒരു ഹൈബ്രിഡ് ഡാറ്റാബേസാണ്: ഇത് ഒരേസമയം ഒരു പ്രധാന മൂല്യം നൽകുകയും വിശാലമായ കോളങ്ങളിൽ ഡാറ്റ സംഭരിക്കുകയും ചെയ്യുന്നു. ജാവയിലോ കോട്ലിനിലോ, ഇതിനെ ഇതുപോലെ വിവരിക്കാം:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

അതായത്, ക്രമീകരിച്ച ഭൂപടം ഉൾക്കൊള്ളുന്ന ഒരു മാപ്പ്. ഈ മാപ്പിന്റെ ആദ്യ കീ റോ കീ അല്ലെങ്കിൽ പാർട്ടീഷൻ കീ ആണ് - പാർട്ടീഷനിംഗ് കീ. ഇതിനകം അടുക്കിയിട്ടുള്ള ഒരു മാപ്പിന്റെ കീ ആയ രണ്ടാമത്തെ കീ, ക്ലസ്റ്ററിംഗ് കീയാണ്.

ഡാറ്റാബേസിന്റെ വിതരണം വ്യക്തമാക്കുന്നതിന്, നമുക്ക് മൂന്ന് നോഡുകൾ വരയ്ക്കാം. ഡാറ്റയെ നോഡുകളിലേക്ക് എങ്ങനെ വിഘടിപ്പിക്കാമെന്ന് ഇപ്പോൾ നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. കാരണം, ഞങ്ങൾ എല്ലാം ഒന്നായി ഒതുക്കുകയാണെങ്കിൽ (ആയിരം, രണ്ടായിരം, അഞ്ച് - നിങ്ങൾക്ക് ഇഷ്ടമുള്ളത്ര എണ്ണം), ഇത് യഥാർത്ഥത്തിൽ വിതരണത്തെക്കുറിച്ചല്ല. അതിനാൽ, നമുക്ക് ഒരു സംഖ്യ നൽകുന്ന ഒരു ഗണിത പ്രവർത്തനം ആവശ്യമാണ്. കേവലം ഒരു സംഖ്യ, ഏതെങ്കിലുമൊരു പരിധിയിൽ വരുന്ന ഒരു നീണ്ട സംഖ്യ. നമുക്ക് ഒരു ശ്രേണിക്ക് ഉത്തരവാദിയായ ഒരു നോഡ് ഉണ്ടായിരിക്കും, രണ്ടാമത്തേത് രണ്ടാമത്തേത്, nth ന് nആമത്തേത്.

ഈ നമ്പർ ഒരു ഹാഷ് ഫംഗ്ഷൻ ഉപയോഗിച്ചാണ് എടുക്കുന്നത്, അത് നമ്മൾ പാർട്ടീഷൻ കീ എന്ന് വിളിക്കുന്നവയിൽ പ്രയോഗിക്കുന്നു. പ്രൈമറി കീ ഡയറക്‌ടീവിൽ വ്യക്തമാക്കിയിരിക്കുന്ന കോളം ഇതാണ്, മാപ്പിന്റെ ആദ്യത്തേതും ഏറ്റവും അടിസ്ഥാനപരവുമായ കീ ആയ കോളം ഇതാണ്. ഏത് നോഡിന് ഏത് ഡാറ്റയാണ് ലഭിക്കേണ്ടതെന്ന് ഇത് നിർണ്ണയിക്കുന്നു. 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)

പ്രാഥമിക കീ നിർദ്ദേശം ശ്രദ്ധിക്കുക; അതിന്റെ ആദ്യ വാദം (ഞങ്ങളുടെ കാര്യത്തിൽ, വർഷം) എല്ലായ്പ്പോഴും പാർട്ടീഷൻ കീയാണ്. അതിൽ ഒന്നോ അതിലധികമോ നിരകൾ അടങ്ങിയിരിക്കാം, അത് പ്രശ്നമല്ല. നിരവധി നിരകൾ ഉണ്ടെങ്കിൽ, അത് വീണ്ടും ബ്രാക്കറ്റിൽ നീക്കം ചെയ്യേണ്ടതുണ്ട്, അതുവഴി ഭാഷാ പ്രീപ്രോസസർ ഇത് പ്രാഥമിക കീ ആണെന്നും അതിന്റെ പിന്നിൽ മറ്റെല്ലാ നിരകളും ക്ലസ്റ്ററിംഗ് കീ ആണെന്നും മനസ്സിലാക്കുന്നു. ഈ സാഹചര്യത്തിൽ, അവ ദൃശ്യമാകുന്ന ക്രമത്തിൽ താരതമ്യത്തിൽ അവ കൈമാറ്റം ചെയ്യപ്പെടും. അതായത്, ആദ്യ നിര കൂടുതൽ പ്രാധാന്യമർഹിക്കുന്നു, രണ്ടാമത്തേത് പ്രാധാന്യം കുറവാണ്, അങ്ങനെ അങ്ങനെ. ഞങ്ങൾ എങ്ങനെ എഴുതുന്നു, ഉദാഹരണത്തിന്, ഡാറ്റ ക്ലാസുകൾക്കുള്ള ഫീൽഡുകൾക്ക് തുല്യമാണ്: ഞങ്ങൾ ഫീൽഡുകൾ ലിസ്റ്റ് ചെയ്യുന്നു, അവയ്‌ക്കായി ഞങ്ങൾ വലുതും ചെറുതുമായവ എഴുതുന്നു. കസാന്ദ്രയിൽ, ഇവ, താരതമ്യേന പറഞ്ഞാൽ, ഡാറ്റ ക്ലാസിന്റെ ഫീൽഡുകളാണ്, അതിനായി എഴുതിയ തുല്യതകൾ പ്രയോഗിക്കും.

ഞങ്ങൾ തരംതിരിക്കുകയും നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുകയും ചെയ്യുന്നു

കീ സൃഷ്‌ടിച്ച അതേ നിമിഷത്തിൽ അടുക്കൽ ക്രമം (അവരോഹണം, ആരോഹണം, എന്തും) സജ്ജീകരിച്ചിട്ടുണ്ടെന്നും അത് പിന്നീട് മാറ്റാൻ കഴിയില്ലെന്നും നിങ്ങൾ ഓർമ്മിക്കേണ്ടതുണ്ട്. ഡാറ്റ എങ്ങനെ അടുക്കുമെന്നും അത് എങ്ങനെ സംഭരിക്കുമെന്നും ഇത് ഭൗതികമായി നിർണ്ണയിക്കുന്നു. നിങ്ങൾക്ക് ക്ലസ്റ്ററിംഗ് കീ അല്ലെങ്കിൽ അടുക്കൽ ക്രമം മാറ്റണമെങ്കിൽ, നിങ്ങൾ ഒരു പുതിയ പട്ടിക ഉണ്ടാക്കി അതിലേക്ക് ഡാറ്റ കൈമാറേണ്ടതുണ്ട്. നിലവിലുള്ള ഒന്നിൽ ഇത് പ്രവർത്തിക്കില്ല.

ഞങ്ങൾ ഉപയോക്താക്കളെക്കൊണ്ട് ഞങ്ങളുടെ ടേബിൾ നിറച്ചു, അവർ ആദ്യം ജനിച്ച വർഷം ഒരു വളയത്തിൽ വീഴുന്നത് കണ്ടു, തുടർന്ന് ഓരോ നോഡിലും ശമ്പളവും ഉപയോക്തൃ ഐഡിയും പ്രകാരം. ഇനി നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തി തിരഞ്ഞെടുക്കാം.

ഞങ്ങളുടെ പ്രവർത്തനം വീണ്ടും ദൃശ്യമാകുന്നു where, and, ഞങ്ങൾക്ക് ഉപയോക്താക്കളെ ലഭിക്കുന്നു, എല്ലാം വീണ്ടും ശരിയാണ്. എന്നാൽ ഞങ്ങൾ ക്ലസ്റ്ററിംഗ് കീയുടെ ഒരു ഭാഗവും പ്രാധാന്യമില്ലാത്തതും മാത്രം ഉപയോഗിക്കാൻ ശ്രമിച്ചാൽ, നൾ കംപാറേറ്ററിനായി ഈ ഫീൽഡുകളുള്ള ഈ ഒബ്‌ജക്‌റ്റും ഇതും ഉള്ള സ്ഥലം ഞങ്ങളുടെ മാപ്പിൽ കണ്ടെത്താൻ കഴിയില്ലെന്ന് കസാന്ദ്ര ഉടൻ പരാതിപ്പെടും. അത് ഇപ്പോൾ സജ്ജീകരിച്ചിരിക്കുന്നു - അവൻ എവിടെയാണ് കിടക്കുന്നത്. ഈ നോഡിൽ നിന്നുള്ള എല്ലാ ഡാറ്റയും ഞാൻ വീണ്ടും എടുത്ത് ഫിൽട്ടർ ചെയ്യേണ്ടിവരും. ഇത് ഒരു നോഡിനുള്ളിലെ പൂർണ്ണ സ്കാനിന്റെ ഒരു അനലോഗ് ആണ്, ഇത് മോശമാണ്.

വ്യക്തമല്ലാത്ത ഏത് സാഹചര്യത്തിലും, ഒരു പുതിയ പട്ടിക സൃഷ്ടിക്കുക

ഐഡി, അല്ലെങ്കിൽ പ്രായം, അല്ലെങ്കിൽ ശമ്പളം എന്നിവ പ്രകാരം ഉപയോക്താക്കളെ ടാർഗെറ്റുചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ എന്തുചെയ്യണം? ഒന്നുമില്ല. രണ്ട് ടേബിളുകൾ മാത്രം ഉപയോഗിക്കുക. നിങ്ങൾക്ക് മൂന്ന് വ്യത്യസ്ത വഴികളിലൂടെ ഉപയോക്താക്കളിലേക്ക് എത്തിച്ചേരണമെങ്കിൽ, മൂന്ന് പട്ടികകൾ ഉണ്ടാകും. ഞങ്ങൾ സ്ക്രൂവിൽ സ്ഥലം ലാഭിച്ച ദിവസങ്ങൾ കഴിഞ്ഞു. ഇതാണ് ഏറ്റവും വിലകുറഞ്ഞ വിഭവം. ഇത് പ്രതികരണ സമയത്തേക്കാൾ വളരെ കുറവാണ്, ഇത് ഉപയോക്താവിന് ഹാനികരമാകും. 10 മിനിറ്റിനുള്ളിൽ ഒരു നിമിഷത്തിനുള്ളിൽ എന്തെങ്കിലും ലഭിക്കുന്നത് ഉപയോക്താവിന് വളരെ സന്തോഷകരമാണ്.

നന്നായി സ്കെയിൽ ചെയ്യാനും വിശ്വസനീയമായി പ്രവർത്തിക്കാനുമുള്ള കഴിവിനായി ഞങ്ങൾ അനാവശ്യ സ്ഥലവും ഡീനോർമലൈസ് ചെയ്ത ഡാറ്റയും ട്രേഡ് ചെയ്യുന്നു. എല്ലാത്തിനുമുപരി, വാസ്തവത്തിൽ, മൂന്ന് ഡാറ്റാ സെന്ററുകൾ അടങ്ങുന്ന ഒരു ക്ലസ്റ്ററിന് അഞ്ച് നോഡുകൾ ഉണ്ട്, സ്വീകാര്യമായ തലത്തിലുള്ള ഡാറ്റാ സംരക്ഷണം (ഒന്നും നഷ്‌ടപ്പെടാത്തപ്പോൾ), ഒരു ഡാറ്റാ സെന്ററിന്റെ മരണത്തെ പൂർണ്ണമായും അതിജീവിക്കാൻ കഴിയും. ബാക്കിയുള്ള രണ്ടെണ്ണത്തിലും രണ്ട് നോഡുകൾ കൂടി. അതിനുശേഷം മാത്രമേ പ്രശ്നങ്ങൾ ആരംഭിക്കൂ. ഇത് വളരെ നല്ല ആവർത്തനമാണ്, ഇത് രണ്ട് അധിക എസ്എസ്ഡി ഡ്രൈവുകളും പ്രോസസ്സറുകളും വിലമതിക്കുന്നു. അതിനാൽ, ഒരിക്കലും SQL അല്ലാത്ത, ബന്ധങ്ങളോ വിദേശ കീകളോ ഇല്ലാത്ത കസാന്ദ്ര ഉപയോഗിക്കുന്നതിന്, നിങ്ങൾ ലളിതമായ നിയമങ്ങൾ അറിയേണ്ടതുണ്ട്.

നിങ്ങളുടെ അഭ്യർത്ഥന അനുസരിച്ച് ഞങ്ങൾ എല്ലാം രൂപകൽപ്പന ചെയ്യുന്നു. പ്രധാന കാര്യം ഡാറ്റയല്ല, ആപ്ലിക്കേഷൻ എങ്ങനെ പ്രവർത്തിക്കും എന്നതാണ്. അതിന് വ്യത്യസ്‌ത ഡാറ്റ വ്യത്യസ്‌ത രീതികളിൽ അല്ലെങ്കിൽ ഒരേ ഡാറ്റ വ്യത്യസ്‌ത രീതികളിൽ സ്വീകരിക്കണമെങ്കിൽ, ഞങ്ങൾ അത് അപ്ലിക്കേഷന് സൗകര്യപ്രദമായ രീതിയിൽ നൽകണം. അല്ലെങ്കിൽ, ഫുൾ സ്കാനിൽ ഞങ്ങൾ പരാജയപ്പെടും, കസാന്ദ്ര ഞങ്ങൾക്ക് ഒരു നേട്ടവും നൽകില്ല.

ഡാറ്റ ഡിനോർമലൈസ് ചെയ്യുന്നത് സാധാരണമാണ്. സാധാരണ രൂപങ്ങളെക്കുറിച്ച് ഞങ്ങൾ മറക്കുന്നു, ഞങ്ങൾക്ക് ഇനി റിലേഷണൽ ഡാറ്റാബേസുകളില്ല. നമ്മൾ ഒരു കാര്യം 100 തവണ താഴെ വെച്ചാൽ അത് 100 തവണ കിടക്കും. ഇത് നിർത്തുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ്.

പാർട്ടീഷനിംഗിനുള്ള കീകൾ ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്നു, അങ്ങനെ അവ സാധാരണയായി വിതരണം ചെയ്യും. ഞങ്ങളുടെ കീകളുടെ ഹാഷ് ഒരു ഇടുങ്ങിയ ശ്രേണിയിലേക്ക് വീഴാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. അതായത്, മുകളിലെ ഉദാഹരണത്തിൽ ജനിച്ച വർഷം ഒരു മോശം ഉദാഹരണമാണ്. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ഞങ്ങളുടെ ഉപയോക്താക്കൾ സാധാരണയായി ജനിച്ച വർഷം വിതരണം ചെയ്താൽ അത് നല്ലതാണ്, ഞങ്ങൾ അഞ്ചാം ക്ലാസ് വിദ്യാർത്ഥികളെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ മോശമാണ് - അവിടെയുള്ള വിഭജനം വളരെ മികച്ചതായിരിക്കില്ല.

ക്ലസ്റ്ററിംഗ് കീ സൃഷ്‌ടിക്കൽ ഘട്ടത്തിൽ സോർട്ടിംഗ് ഒരിക്കൽ തിരഞ്ഞെടുത്തു. ഇത് മാറ്റണമെങ്കിൽ, മറ്റൊരു കീ ഉപയോഗിച്ച് ഞങ്ങളുടെ ടേബിൾ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടിവരും.

ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം: ഒരേ ഡാറ്റ 100 വ്യത്യസ്ത രീതികളിൽ വീണ്ടെടുക്കണമെങ്കിൽ, നമുക്ക് 100 വ്യത്യസ്ത പട്ടികകൾ ഉണ്ടാകും.

അവലംബം: www.habr.com