කැසැන්ඩ්රා. ඔරකල් විතරක් දන්නවනම් මැරෙන්නෙ නැති හැටි

හේ හබ්ර්.

මගේ නම මිෂා බුට්‍රිමොව්, මම ඔබට කැසැන්ඩ්‍රා ගැන ටිකක් කියන්න කැමතියි. NoSQL දත්ත සමුදායන් කිසිදා හමු නොවූ අයට මගේ කතාව ප්‍රයෝජනවත් වනු ඇත - එහි ක්‍රියාත්මක කිරීමේ විශේෂාංග සහ ඔබ දැනගත යුතු අන්තරායන් රාශියක් ඇත. ඔබ Oracle හෝ වෙනත් සම්බන්ධතා දත්ත ගබඩාව හැර වෙනත් කිසිවක් දැක නොමැති නම්, මේ දේවල් ඔබේ ජීවිතය සුරැකෙනු ඇත.

කැසැන්ඩ්‍රා ගැන එතරම් හොඳ කුමක්ද? එය හොඳින් පරිමාණය කරන තනි අසාර්ථකත්වයකින් තොරව නිර්මාණය කරන ලද NoSQL දත්ත ගබඩාවකි. ඔබට යම් දත්ත සමුදායක් සඳහා ටෙරාබයිට් කිහිපයක් එකතු කිරීමට අවශ්‍ය නම්, ඔබ හුදෙක් මුද්දට නෝඩ් එක් කරන්න. එය වෙනත් දත්ත මධ්‍යස්ථානයකට පුළුල් කරන්නද? පොකුරට නෝඩ් එකතු කරන්න. සැකසූ RPS වැඩි කරන්නද? පොකුරට නෝඩ් එකතු කරන්න. එය ප්රතිවිරුද්ධ දිශාවට ද ක්රියා කරයි.

ඇය දක්ෂ වෙන කුමක් ද? එය බොහෝ ඉල්ලීම් හැසිරවීමයි. නමුත් ගොඩක් කියන්නේ කීයද? තත්පරයකට ඉල්ලීම් 10, 20, 30, 40 දහසක් වැඩි නොවේ. පටිගත කිරීම සඳහා තත්පරයකට ඉල්ලීම් 100 දහසක් - ද. තත්පරයකට ඉල්ලීම් ලක්ෂ 2ක් තියාගෙන ඉන්නවා කියපු සමාගම් තියෙනවා. ඔවුන්ට එය විශ්වාස කිරීමට සිදුවනු ඇත.

ප්‍රතිපත්තිමය වශයෙන්, කැසැන්ඩ්‍රාට සම්බන්ධතා දත්ත වලින් එක් විශාල වෙනසක් ඇත - එය කිසිසේත් ඒවාට සමාන නොවේ. තවද මෙය මතක තබා ගැනීම ඉතා වැදගත් වේ.

එක වගේ පෙනෙන හැම දෙයක්ම එකම විදිහට වැඩ කරන්නේ නැහැ

වරක් සගයෙක් මා වෙත පැමිණ මෙසේ ඇසීය: “මෙන්න CQL Cassandra විමසුම් භාෂාවක්, එහි තෝරාගත් ප්‍රකාශයක් ඇත, එහි ඇත්තේ කොතැනද, තිබේද සහ ඇත. මම ලියුම් ලිව්වත් වැඩක් නෑ. ඇයි?". ප්‍රචණ්ඩකාරී සියදිවි නසා ගැනීමට ඇති හොඳම ක්‍රමය කැසැන්ඩ්‍රා සම්බන්ධ දත්ත ගබඩාවක් ලෙස සැලකීමයි. මම එය ප්‍රවර්ධනය නොකරමි, එය රුසියාවේ තහනම්ය. ඔබ වැරදි දෙයක් නිර්මාණය කරයි.

උදාහරණයක් වශයෙන්, පාරිභෝගිකයෙක් අප වෙත පැමිණ මෙසේ කියයි: “අපි රූපවාහිනී කතා මාලා සඳහා දත්ත සමුදායක් හෝ වට්ටෝරු නාමාවලියක් සඳහා දත්ත සමුදායක් ගොඩනඟමු. අපට එහි කෑම පිඟන් හෝ රූපවාහිනී කතා මාලා සහ එහි නළු නිළියන්ගේ ලැයිස්තුවක් තිබේ. ” අපි සතුටින් කියනවා: "අපි යමු!" බයිට් දෙකක්, සංඥා කිහිපයක් යවන්න සහ ඔබ අවසන්, සියල්ල ඉතා ඉක්මනින් සහ විශ්වාසදායක ලෙස ක්‍රියා කරයි. පාරිභෝගිකයින් පැමිණ ගෘහණියන් ද ප්‍රතිවිරුද්ධ ගැටලුව විසඳන බව පවසන තුරු සියල්ල හොඳයි: ඔවුන් සතුව නිෂ්පාදන ලැයිස්තුවක් ඇති අතර, ඔවුන් උයන්න අවශ්‍ය කෑම මොනවාදැයි දැන ගැනීමට ඔවුන්ට අවශ්‍යය. ඔය මැරිලා.

මෙයට හේතුව කැසැන්ඩ්‍රා දෙමුහුන් දත්ත සමුදායක් වන බැවිනි: එය එකවර ප්‍රධාන අගයක් සපයන අතර පුළුල් තීරු වල දත්ත ගබඩා කරයි. ජාවා හෝ කොට්ලින් වලදී, එය මෙසේ විස්තර කළ හැකිය:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

එනම්, වර්ග කළ සිතියමක් ද අඩංගු සිතියමකි. මෙම සිතියමේ පළමු යතුර වන්නේ පේළි යතුර හෝ කොටස් යතුර - කොටස් කිරීමේ යතුරයි. දැනටමත් වර්ග කර ඇති සිතියමක යතුර වන දෙවන යතුර වන්නේ Clustering යතුරයි.

දත්ත සමුදායේ ව්‍යාප්තිය නිදර්ශනය කිරීම සඳහා, අපි නෝඩ් තුනක් අඳිමු. දත්ත නෝඩ් වලට වියෝජනය කරන්නේ කෙසේදැයි දැන් ඔබ තේරුම් ගත යුතුය. මක්නිසාද යත්, අපි සියල්ල එකකට තද කළහොත් (මාර්ගය වන විට, දහසක්, දෙදහසක්, පහක් - ඔබ කැමති තරම් තිබිය හැකිය), මෙය ඇත්ත වශයෙන්ම බෙදා හැරීම ගැන නොවේ. එමනිසා, අපට සංඛ්‍යාවක් ආපසු ලබා දෙන ගණිතමය ශ්‍රිතයක් අවශ්‍ය වේ. හුදෙක් අංකයක්, යම් පරාසයකට වැටෙන දිගු int. තවද අපට එක් පරාසයකට වගකිව යුතු එක් නෝඩයක් ඇත, දෙවැන්න දෙවැන්න සඳහා, nth සඳහා n වැනි එක.

මෙම අංකය හැෂ් ශ්‍රිතයක් භාවිතයෙන් ගනු ලැබේ, එය අපි කොටස් යතුර ලෙස හඳුන්වන දෙයට යොදනු ලැබේ. මෙය ප්‍රාථමික යතුරු විධානයේ දක්වා ඇති තීරුව වන අතර, සිතියමේ පළමු සහ මූලිකම යතුර වනුයේ මෙම තීරුවයි. එය කුමන දත්ත ලබා ගන්නේද යන්න තීරණය කරයි. SQL හි ඇති වාක්‍ය ඛණ්ඩය සමඟ කැසැන්ඩ්‍රා හි වගුවක් නිර්මාණය කර ඇත:

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

)

මෙම නඩුවේ ප්රාථමික යතුර එක් තීරුවකින් සමන්විත වන අතර, එය කොටස් කිරීමේ යතුර ද වේ.

අපගේ පරිශීලකයින් ක්‍රියා කරන්නේ කෙසේද? සමහරු එක නෝඩ් එකකට, සමහරක් තවත් එකකට, තවත් සමහරු තුන්වෙනි එකකට යනවා. මෙහි ප්‍රතිඵලය වන්නේ සාමාන්‍ය හැෂ් වගුවකි, එය සිතියමක් ලෙසද හැඳින්වේ, පයිතන් හි ශබ්දකෝෂයක් ලෙසද හැඳින්වේ, නැතහොත් අපට සියලු අගයන් කියවිය හැකි, යතුරෙන් කියවීමට සහ ලිවීමට හැකි සරල Key අගය ව්‍යුහයකි.

තෝරන්න: පෙරීම සම්පූර්ණ ස්කෑන් බවට හැරෙන විට, හෝ නොකළ යුතු දේ

අපි තෝරාගත් ප්රකාශ කිහිපයක් ලියන්නෙමු: select * from users where, userid = . එය Oracle හි මෙන් හැරෙනවා: අපි තෝරන්න ලියන්න, කොන්දේසි නියම කරන්න සහ සෑම දෙයක්ම ක්රියා කරයි, පරිශීලකයින් එය ලබා ගනී. නමුත් ඔබ තෝරා ගන්නේ නම්, උදාහරණයක් ලෙස, උපන් වර්ෂයක් ඇති පරිශීලකයෙකු, කැසැන්ඩ්‍රා පැමිණිලි කරන්නේ එයට ඉල්ලීම ඉටු කළ නොහැකි බවයි. අපි උපන් වර්ෂය පිළිබඳ දත්ත බෙදා හරින ආකාරය ගැන ඇය කිසිවක් නොදන්නා නිසා - ඇයට යතුරක් ලෙස දක්වා ඇත්තේ එක් තීරුවක් පමණි. එවිට ඇය කියනවා, “හරි, මට තවමත් මේ ඉල්ලීම ඉටු කරන්න පුළුවන්. පෙරීමට ඉඩ දෙන්න." අපි විධානය එකතු කරමු, සියල්ල ක්රියා කරයි. මේ මොහොතේ භයානක දෙයක් සිදු වේ.

අපි පරීක්ෂණ දත්ත මත ධාවනය කරන විට, සියල්ල හොඳයි. ඔබ නිෂ්පාදනයේදී විමසුමක් ක්‍රියාත්මක කරන විට, උදාහරණයක් ලෙස, අපට වාර්තා මිලියන 4 ක් ඇති, එවිට සියල්ල අපට එතරම් හොඳ නැත. ඉඩ පෙරීම යනු සියලුම නෝඩ්, සියලුම දත්ත මධ්‍යස්ථාන (මෙම පොකුරේ ඒවායින් බොහොමයක් තිබේ නම්) මෙම වගුවේ ඇති සියලුම දත්ත එක්රැස් කිරීමට කැසැන්ඩ්‍රාට ඉඩ දෙන නියෝගයක් වන අතර පසුව පමණක් එය පෙරීම. මෙය ෆුල් ස්කෑන් හි ප්‍රතිසමයක් වන අතර කිසිවකු ඒ ගැන සතුටු නොවන තරම්ය.

අපට හැඳුනුම්පත මගින් පරිශීලකයින් පමණක් අවශ්‍ය නම්, අපට මෙය හොඳ වනු ඇත. නමුත් සමහර විට අපට වෙනත් විමසුම් ලිවීමට සහ තේරීමට වෙනත් සීමාවන් පැනවීමට සිදුවේ. එමනිසා, අපට මතකයි: මේ සියල්ල කොටස් කිරීමේ යතුරක් ඇති සිතියමකි, නමුත් එහි ඇතුළත වර්ග කළ සිතියමකි.

තවද ඇය සතුව යතුරක් ද ඇත, එය අපි Clustering Key ලෙස හඳුන්වයි. මෙම යතුර, අපි තෝරා ගන්නා තීරු වලින් සමන්විත වන අතර, එහි දත්ත භෞතිකව වර්ග කර ඇති ආකාරය සහ එක් එක් නෝඩය මත පිහිටා ඇති ආකාරය කැසැන්ඩ්‍රා තේරුම් ගනී. එනම්, සමහර කොටස් යතුර සඳහා, Clustering යතුර ඔබට මෙම ගස තුළට දත්ත තල්ලු කරන්නේ කෙසේද, එය එහි ගන්නේ කුමන ස්ථානයටද යන්න හරියටම කියනු ඇත.

මෙය සැබවින්ම ගසකි, සංසන්දනය කරන්නෙකු එහි සරලව හැඳින්වේ, අපි වස්තුවක ස්වරූපයෙන් යම් තීරු කට්ටලයක් පසුකර යන අතර එය තීරු ලැයිස්තුවක් ලෙසද දක්වා ඇත.

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

ප්‍රාථමික යතුරු විධානය වෙත අවධානය යොමු කරන්න; එහි පළමු තර්කය (අපගේ නඩුවේදී, වර්ෂය) සෑම විටම කොටස් යතුර වේ. එය තීරු එකක් හෝ වැඩි ගණනකින් සමන්විත විය හැකිය, එය වැදගත් නොවේ. තීරු කිහිපයක් තිබේ නම්, එය නැවත වරහන් තුළ ඉවත් කළ යුතු අතර එමඟින් භාෂා පූර්ව සකසනය මෙය ප්‍රාථමික යතුර බව තේරුම් ගන්නා අතර අනෙක් සියලුම තීරු පොකුරු යතුර වේ. මෙම අවස්ථාවෙහිදී, ඔවුන් පෙනී සිටින අනුපිළිවෙලෙහි සංසන්දනය තුළ සම්ප්රේෂණය කරනු ලැබේ. එනම්, පළමු තීරුව වඩාත් වැදගත් වන අතර, දෙවනුව අඩු වැදගත්කමක් ඇත, සහ එසේ ය. අපි ලියන ආකාරය, උදාහරණයක් ලෙස, දත්ත පන්ති සඳහා ක්ෂේත්‍ර වලට සමාන වේ: අපි ක්ෂේත්‍ර ලැයිස්තුගත කරමු, සහ ඒවා සඳහා අපි ලියන්නේ කුමන ඒවා විශාල සහ කුඩාද යන්නයි. Cassandra හි, මේවා සාපේක්ෂ වශයෙන් කථා කරන විට, දත්ත පන්තියේ ක්ෂේත්‍ර වන අතර, ඒ සඳහා ලියා ඇති සමානකම් යොදනු ලැබේ.

අපි වර්ග කිරීම සහ සීමාවන් පනවන්නෙමු

යතුර සෑදූ මොහොතේම වර්ග කිරීමේ අනුපිළිවෙල (බැසීම, නැගීම, ඕනෑම දෙයක්) සකසා ඇති බවත්, එය පසුව වෙනස් කළ නොහැකි බවත් ඔබ මතක තබා ගත යුතුය. එය දත්ත වර්ග කරන ආකාරය සහ එය ගබඩා කරන්නේ කෙසේද යන්න භෞතිකව තීරණය කරයි. ඔබට Clustering යතුර හෝ අනුපිළිවෙල වෙනස් කිරීමට අවශ්‍ය නම්, ඔබට නව වගුවක් සාදා එයට දත්ත මාරු කිරීමට සිදුවේ. පවතින එකක් සමඟ මෙය ක්‍රියා නොකරනු ඇත.

අපි අපගේ මේසය පරිශීලකයින්ගෙන් පුරවා ගත් අතර, ඔවුන් පළමුව උපන් වර්ෂය අනුව, පසුව වැටුප සහ පරිශීලක හැඳුනුම්පත අනුව එක් එක් නෝඩය තුළ වළල්ලකට වැටී ඇති බව දුටුවෙමු. දැන් අපට සීමා පැනවීමෙන් තෝරා ගත හැකිය.

අපේ වැඩ කරන එක ආයෙත් පෙනෙයි where, and, සහ අපි පරිශීලකයින් ලබා ගන්නා අතර, සියල්ල නැවතත් හොඳයි. නමුත් අපි ක්ලස්ටරින් යතුරේ කොටසක් පමණක් සහ අඩු වැදගත්කමක් භාවිතා කිරීමට උත්සාහ කරන්නේ නම්, එවිට කැසැන්ඩ්‍රා වහාම පැමිණිලි කරනු ඇත්තේ අපගේ සිතියමේ මෙම වස්තුව, ශුන්‍ය සංසන්දනය සඳහා මෙම ක්ෂේත්‍ර ඇති ස්ථානය සොයාගත නොහැකි බවයි. එය නිකම්ම සකසා ඇත - ඔහු සිටින තැන. මට නැවත මෙම නෝඩයෙන් සියලුම දත්ත ඇදගෙන එය පෙරීමට සිදුවේ. තවද මෙය node එකක් තුළ ඇති Full Scan හි ප්‍රතිසමයකි, මෙය නරකයි.

ඕනෑම අපැහැදිලි තත්වයක් තුළ, නව වගුවක් සාදන්න

හැඳුනුම්පත අනුව හෝ වයස අනුව හෝ වැටුප අනුව පරිශීලකයින් ඉලක්ක කර ගැනීමට අපට අවශ්‍ය නම්, අප කුමක් කළ යුතුද? කිසිවක් නැත. මේස දෙකක් පමණක් භාවිතා කරන්න. ඔබට විවිධ ආකාර තුනකින් පරිශීලකයින් වෙත ළඟා වීමට අවශ්‍ය නම්, වගු තුනක් ඇත. අපි ඉස්කුරුප්පු ඇණ මත ඉඩ ඉතිරි කළ කාලය ගෙවී ගොස් ඇත. මෙය ලාභම සම්පතයි. එය ප්‍රතිචාර දැක්වීමේ කාලයට වඩා බෙහෙවින් අඩු පිරිවැයක් දරයි, එය පරිශීලකයාට අහිතකර විය හැක. මිනිත්තු 10කට වඩා තත්පරයකින් යමක් ලැබීම පරිශීලකයාට වඩාත් ප්‍රසන්නය.

හොඳින් පරිමාණය කිරීමට සහ විශ්වාසදායක ලෙස ක්‍රියා කිරීමට ඇති හැකියාව සඳහා අපි අනවශ්‍ය ඉඩ සහ සාමාන්‍යකරණය කළ දත්ත වෙළඳාම් කරමු. ඇත්ත වශයෙන්ම, දත්ත මධ්‍යස්ථාන තුනකින් සමන්විත වන අතර, ඒ සෑම එකක්ම නෝඩ් පහක් ඇති අතර, පිළිගත හැකි මට්ටමේ දත්ත සංරක්ෂණයක් (කිසිවක් නැති වූ විට), එක් දත්ත මධ්‍යස්ථානයක මරණයෙන් සම්පූර්ණයෙන්ම බේරීමට හැකි වේ. සහ ඉතිරි දෙකෙහිම තවත් නෝඩ් දෙකක්. ගැටළු ආරම්භ වන්නේ මෙයින් පසුව පමණි. මෙය ඉතා හොඳ අතිරික්තයකි, එය අමතර SSD ධාවකයන් සහ ප්‍රොසෙසර කිහිපයක් වටී. එමනිසා, කිසි විටෙකත් SQL නොවන, සබඳතා, විදේශීය යතුරු නොමැති Cassandra භාවිතා කිරීම සඳහා, ඔබ සරල නීති දැන සිටිය යුතුය.

ඔබගේ ඉල්ලීම පරිදි අපි සියල්ල සැලසුම් කරමු. ප්රධාන දෙය වන්නේ දත්ත නොවේ, නමුත් යෙදුම එය සමඟ වැඩ කරන්නේ කෙසේද යන්නයි. එයට විවිධ දත්ත විවිධ ආකාරවලින් හෝ එකම දත්ත විවිධ ආකාරවලින් ලබා ගැනීමට අවශ්‍ය නම්, අපි එය යෙදුමට පහසු ආකාරයකින් තැබිය යුතුය. නැත්තම් අපි Full Scan එකෙන් ෆේල් වෙනවා වගේම Cassandra එකෙන් අපිට කිසිම වාසියක් ලැබෙන්නේ නැහැ.

දත්ත සාමාන්‍යකරණය කිරීම සාමාන්‍ය දෙයකි. අපි සාමාන්‍ය ආකෘති ගැන අමතක කරමු, අපට තවදුරටත් සම්බන්ධතා දත්ත සමුදායන් නොමැත. අපි යමක් 100 වතාවක් තැබුවොත් එය 100 වතාවක් වැතිරෙනවා. එය තවමත් නතර කිරීමට වඩා ලාභදායී වේ.

අපි කොටස් කිරීම සඳහා යතුරු තෝරා ගන්නේ ඒවා සාමාන්යයෙන් බෙදා හරිනු ලැබේ. අපගේ යතුරු වල හැෂ් එක පටු පරාසයකට වැටීමට අපට අවශ්‍ය නැත. එනම් ඉහත උදාහරණයේ උපන් වර්ෂය නරක උදාහරණයකි. වඩාත් නිවැරදිව, අපගේ පරිශීලකයින් සාමාන්‍යයෙන් උපන් වර්ෂය අනුව බෙදා හරිනු ලැබුවහොත් හොඳයි, අපි 5 වන ශ්‍රේණියේ සිසුන් ගැන කතා කරන්නේ නම් නරකයි - එහි කොටස් කිරීම එතරම් හොඳ නොවනු ඇත.

Clustering Key නිර්මාණය කිරීමේ අදියරේදී එක් වරක් වර්ග කිරීම තෝරා ගනු ලැබේ. එය වෙනස් කිරීමට අවශ්‍ය නම්, අපට වෙනත් යතුරකින් අපගේ වගුව යාවත්කාලීන කිරීමට සිදුවේ.

සහ වඩාත්ම වැදගත් දෙය: අපට එකම දත්ත විවිධ ආකාර 100 කින් ලබා ගැනීමට අවශ්‍ය නම්, අපට විවිධ වගු 100 ක් ඇත.

මූලාශ්රය: www.habr.com