අප්‍රේල් මාසයේදී, Avito ඉංජිනේරුවන් ප්රධාන ClickHouse සංවර්ධක Alexey Milovidov සහ Integros හි Golang සංවර්ධකයෙකු වන Kirill Shvakov සමඟ සබැඳි රැස්වීම් සඳහා රැස් වූහ. අපි දත්ත සමුදා කළමනාකරණ පද්ධතියක් භාවිතා කරන ආකාරය සහ අප මුහුණ දෙන දුෂ්කරතා මොනවාද යන්න අපි සාකච්ඡා කළෙමු.
රැස්වීම මත පදනම්ව, අපි උපස්ථ, දත්ත නැවත සකස් කිරීම, බාහිර ශබ්දකෝෂ, Golang ධාවකය සහ ClickHouse අනුවාද යාවත්කාලීන කිරීම පිළිබඳ අපගේ සහ ප්‍රේක්ෂකයන්ගේ ප්රශ්නවලට ප්‍රවීණයන්ගේ පිළිතුරු සහිත ලිපියක් සම්පාදනය කර ඇත. Yandex DBMS සමඟ දැනටමත් ක්රියාකාරීව වැඩ කරන සහ එහි වර්තමාන සහ අනාගතය ගැන උනන්දුවක් දක්වන සංවර්ධකයින්ට එය ප්රයෝජනවත් විය හැකිය. පෙරනිමියෙන්, පිළිතුරු Alexey Milovidov විසින්, වෙනත් ආකාරයකින් ලියා නොමැති නම්.
ප්‍රවේශම් වන්න, කප්පාදුව යට පෙළ ගොඩක් තිබේ. ප්‍රශ්න සහිත අන්තර්ගතය ඔබට සැරිසැරීමට උපකාරී වනු ඇතැයි අපි බලාපොරොත්තු වෙමු.
අන්තර්ගතය
ඔබට පෙළ කියවීමට අවශ්ය නැතිනම්, ඔබට රැස්වීම් පටිගත කිරීම නැරඹිය හැකිය . වේලා කේත වීඩියෝව යටතේ පළමු කමෙන්ට් එකේ ඇත.
ClickHouse නිරන්තරයෙන් යාවත්කාලීන වේ, නමුත් අපගේ දත්ත එසේ නොවේ. ඒකට මොනවා කරන්නද?
ClickHouse නිරන්තරයෙන් යාවත්කාලීන වන අතර, අපගේ දත්ත, ප්‍රශස්ත ලෙස සකස් කරන ලද, යාවත්කාලීන නොවන අතර උපස්ථ පිටපතක ඇත.
අපි හිතමු අපිට මොකක් හරි ප්රශ්නයක් වෙලා දත්ත නැති වුනා කියලා. අපි ප්‍රතිසාධනය කිරීමට තීරණය කළ අතර, උපස්ථ සේවාදායකයන්හි ගබඩා කර ඇති පැරණි කොටස්, දැනට භාවිතා කරන ClickHouse අනුවාදයට වඩා බෙහෙවින් වෙනස් බව පෙනී ගියේය. එවැනි තත්වයක් තුළ කුමක් කළ යුතුද, එය කළ හැකිද?
ඔබ පැරණි ආකෘතියකින් උපස්ථයකින් දත්ත ප්රතිස්ථාපනය කළ නමුත් එය නව අනුවාදයට සම්බන්ධ නොවන තත්වයක් කළ නොහැක. ClickHouse හි දත්ත ආකෘතිය සැමවිටම පසුපසට ගැළපෙන බව අපි සහතික කර ගනිමු. කලාතුරකින් භාවිතා වන සමහර ශ්‍රිතයක හැසිරීම් වෙනස් වී ඇත්නම්, ක්‍රියාකාරීත්වයේ පසුගාමී අනුකූලතාවයට වඩා මෙය ඉතා වැදගත් වේ. ClickHouse හි නව අනුවාදය සෑම විටම තැටියේ ගබඩා කර ඇති දත්ත කියවීමට හැකි විය යුතුය. මේක තමයි නීතිය.
ClickHouse වෙතින් දත්ත උපස්ථ කිරීම සඳහා දැනට පවතින හොඳම භාවිතයන් මොනවාද?
අපි අවසාන මෙහෙයුම් ප්‍රශස්ත කර ඇති බව, ටෙරාබයිට් විශාල දත්ත ගබඩාවක් සහ පසුගිය දින තුන තුළ යාවත්කාලීන කරන ලද දත්ත සහ පසුව එයට කිසිදු ක්රියා පටිපාටියක් සිදු නොවන බව සැලකිල්ලට ගනිමින් උපස්ථ කරන්නේ කෙසේද?
අපට අපගේම විසඳුමක් සාදා බාෂ් මත ලිවිය හැකිය: මෙම උපස්ථ පිටපත් එවැනි සහ එවැනි ආකාරයකින් එකතු කරන්න. සමහර විට කිසිවක් කිහිලිකරු කිරීමට අවශ්ය නැත, සහ බයිසිකලය බොහෝ කලකට පෙර සොයා ගන්නා ලදී?
හොඳම භාවිතයන් සමඟ ආරම්භ කරමු. මෙම ගැටළුව දැනටමත් විසඳා ඇති Yandex.Cloud සේවාව ගැන මතක් කිරීමට මගේ සගයන් සැමවිටම උපස්ථ පිළිබඳ ප්රශ්නවලට ප්රතිචාර දැක්වීමට උපදෙස් දෙයි. එබැවින් හැකි නම් එය භාවිතා කරන්න.
උපස්ථ සඳහා සම්පූර්ණ විසඳුමක් නොමැත, සියයට සියයක් ClickHouse තුළ ගොඩනගා ඇත. භාවිතා කළ හැකි හිස් තැන් කිහිපයක් තිබේ. සම්පූර්ණ විසඳුමක් ලබා ගැනීම සඳහා, ඔබට අතින් ටිකක් ටින්කර් කිරීමට සිදුවනු ඇත, නැතහොත් ස්ක්‍රිප්ට් ආකාරයෙන් දවටන නිර්මාණය කළ යුතුය.
මම සරලම විසඳුම් වලින් පටන් ගෙන දත්ත පරිමාව සහ පොකුරේ ප්රමාණය අනුව වඩාත් සංකීර්ණ ඒවා සමඟ අවසන් කරමි. පොකුර විශාල වන තරමට විසඳුම වඩාත් සංකීර්ණ වේ.
දත්ත සහිත වගුව ගිගාබයිට් කිහිපයක් පමණක් භාවිතා කරන්නේ නම්, උපස්ථ කිරීම මේ ආකාරයට කළ හැකිය:
- වගු අර්ථ දැක්වීම එනම් පාරදත්ත - සුරකින්න සාදන්න වගුව පෙන්වන්න.
- ClickHouse සේවාලාභියා භාවිතයෙන් ඩම්ප් එකක් සාදන්න - තෝරන්න * මේසයෙන් ගොනු කිරීමට. පෙරනිමියෙන් ඔබට TabSeparated ආකෘතියෙන් ගොනුවක් ලැබෙනු ඇත. ඔබට වඩාත් කාර්යක්ෂම වීමට අවශ්ය නම්, ඔබට එය ස්වදේශීය ආකෘතියෙන් කළ හැකිය.
දත්ත ප්රමාණය විශාල නම්, උපස්ථයට වැඩි කාලයක් සහ විශාල ඉඩක් ගතවනු ඇත. මෙය තාර්කික උපස්ථයක් ලෙස හැඳින්වේ; එය ClickHouse දත්ත ආකෘතියට බැඳී නැත. එය එසේ නම්, අවසාන විසඳුම ලෙස ඔබට උපස්ථයක් ගෙන එය ප්‍රතිසාධනය සඳහා MySQL වෙත උඩුගත කළ හැකිය.
වඩාත් උසස් අවස්ථා සඳහා, දේශීය ගොනු පද්ධතිය තුළ කොටස්වල සැණෙපොතක් නිර්මාණය කිරීමට ClickHouse හට සවි කළ හැකියාව ඇත. මෙම විශේෂාංගය ඉල්ලීමක් ලෙස පවතී වගුව කැටිකිරීමේ කොටස වෙනස් කරන්න. හෝ සරලව වගුව කැටි කිරීම වෙනස් කරන්න - මෙය සම්පූර්ණ වගුවේ ඡායාරූපයකි.
ස්නැප්ෂොට් එක මේසයක් සඳහා එක කැබැල්ලක් සඳහා අඛණ්ඩව නිර්මාණය වනු ඇත, එනම්, මේ ආකාරයෙන් සම්පූර්ණ පොකුරේ ස්ථාවර ඡායාරූපයක් නිර්මාණය කළ නොහැක. නමුත් බොහෝ කාර්යයන් සඳහා එවැනි අවශ්යතාවයක් නොමැති අතර, එක් එක් ෂාර්ඩ් මත ඉල්ලීමක් ක්රියාත්මක කිරීම සහ ස්ථාවර ස්නැප්ෂොට් එකක් ලබා ගැනීම ප්රමාණවත් වේ. එය Hardlinks ආකාරයෙන් නිර්මාණය කර ඇති අතර එබැවින් අමතර ඉඩක් නොගනී. ඊළඟට, ඔබ මෙම ඡායාරූපය උපස්ථ සේවාදායකයට හෝ ඔබ උපස්ථ සඳහා භාවිතා කරන ගබඩාවට පිටපත් කරයි.
එවැනි උපස්ථයක් ප්රතිස්ථාපනය කිරීම තරමක් පහසුය. පළමුව, පවතින වගු අර්ථ දැක්වීම් භාවිතා කරමින් වගු සාදන්න. මීළඟට, මෙම වගු සඳහා වන කොටස්වල සුරකින ලද ස්නැප්ෂොට් නාමාවලි-වෙන්කළ වෙත පිටපත් කර විමසුම ක්රියාත්මක කරන්න. කොටස අමුණන්න. මෙම විසඳුම වඩාත් බරපතල දත්ත පරිමාවන් සඳහා බෙහෙවින් සුදුසු ය.
සමහර විට ඔබට ඊටත් වඩා සිසිල් දෙයක් අවශ්ය වේ - ඔබට එක් එක් සේවාදායකයේ ටෙරාබයිට් දස හෝ සිය ගණනක් සහ සේවාදායක සිය ගණනක් ඇති අවස්ථාවන්හිදී. Yandex.Metrica වෙතින් මගේ සගයන්ගෙන් මා ලබා ගත් විසඳුමක් මෙහි තිබේ. මම එය සෑම කෙනෙකුටම නිර්දේශ නොකරමි - එය කියවා එය සුදුසුද නැද්ද යන්න ඔබම තීරණය කරන්න.
පළමුව ඔබ විශාල තැටි රාක්ක සහිත සේවාදායකයන් කිහිපයක් සෑදිය යුතුය. මීළඟට, මෙම සේවාදායකයන් මත, ClickHouse සේවාදායකයන් කිහිපයක් ඔසවා ඒවා එකම කැබලි සඳහා තවත් අනුරුවක් ලෙස ක්රියා කරන පරිදි ඒවා වින්‍යාස කරන්න. ඉන්පසු ඔබට ස්නැප්ෂොට් සෑදීමට ඉඩ සලසන ගොනු පද්ධතියක් හෝ මෙම සර්වර් වල යම් මෙවලමක් භාවිතා කරන්න. මෙහි විකල්ප දෙකක් තිබේ. පළමු විකල්පය LVM snapshots වේ, දෙවන විකල්පය Linux මත ZFS වේ.
ඊට පසු, සෑම දිනකම ඔබට ස්නැප්ෂොට් එකක් සෑදිය යුතුය, එය බොරු කියමින් යම් ඉඩක් ලබා ගනී. ස්වාභාවිකවම, දත්ත වෙනස් වුවහොත්, කාලයත් සමඟ ඉඩ ප්රමාණය වැඩි වේ. මෙම ස්නැප්ෂොට් ඕනෑම වේලාවක පිටතට ගෙන දත්ත ප්‍රතිසාධනය කළ හැකිය, එවැනි අමුතු විසඳුමක්. තවද, අපි මෙම අනුරූ වින්‍යාසය තුළ සීමා කළ යුතු අතර එවිට ඔවුන් නායකයින් වීමට උත්සාහ නොකරයි.
පතුවළ තුළ අනුරූ වල පාලිත ප්‍රමාදයක් සංවිධානය කිරීමට හැකි වේද?
මෙම වසරේ ඔබ ClickHouse හි පතුවළ සෑදීමට සැලසුම් කර ඇත. ඒවා තුළ පාලිත ප්‍රමාදයක් අනුරූ සංවිධානය කිරීමට හැකි වේද? වෙනස් කිරීම් සහ වෙනත් වෙනස්කම් සහිත සෘණාත්මක අවස්ථා වලින් අපව ආරක්ෂා කර ගැනීමට අපි එය භාවිතා කිරීමට කැමැත්තෙමු.
වෙනස් කිරීම් සඳහා යම් ආකාරයක පෙරළීමක් කළ හැකිද? උදාහරණයක් ලෙස, පවතින පතුවළක, මේ මොහොත දක්වා ඔබ වෙනස්කම් යොදන බවත්, මේ මොහොතේ සිට ඔබ වෙනස්කම් යෙදීම නවත්වන බවත් කියන්න.
විධානයක් අපගේ පොකුරට පැමිණ එය බිඳ දැමුවහොත්, අපට පැයක ප්‍රමාදයක් සහිත කොන්දේසි සහිත අනුරුවක් තිබේ, එහිදී අපට එය මේ මොහොතේ භාවිතා කරමු යැයි පැවසිය හැකිය, නමුත් අපි අවසාන මිනිත්තු දහය සඳහා එයට වෙනස්කම් යොදන්නේ නැද්ද?
පළමුව, අනුරූ වල පාලිත ප්‍රමාදය ගැන. පරිශීලකයින්ගෙන් එවැනි ඉල්ලීමක් ඇති අතර, අපි Github හි ගැටලුවක් නිර්මාණය කළේ “යමෙකුට මෙය අවශ්ය නම්, එයට කැමති නම්, හදවතක් තබන්න” යන ඉල්ලීම සමඟිනි. කිසිවෙකු භාර නොදුන් අතර, ගැටලුව වසා දමන ලදී. කෙසේ වෙතත්, ClickHouse පිහිටුවීමෙන් ඔබට දැනටමත් මෙම අවස්ථාව ලබා ගත හැක. ඇත්ත, 20.3 අනුවාදයෙන් පමණක් ආරම්භ වේ.
ClickHouse නිරන්තරයෙන් පසුබිමේ දත්ත ඒකාබද්ධ කිරීම සිදු කරයි. ඒකාබද්ධ කිරීමක් සම්පූර්ණ වූ විට, යම් දත්ත කට්ටලයක් විශාල කැබැල්ලක් සමඟ ප්රතිස්ථාපනය වේ. ඒ අතරම, කලින් තිබූ දත්ත කොටස් ටික වේලාවක් තැටියේ පවතී.
පළමුව, අවහිර නොවන ක්‍රියාවක් සැපයීම සඳහා, ඒවා භාවිතා කරන තෝරාගත් විමසුම් පවතින තාක් ඒවා දිගටම ගබඩා වේ. තෝරාගත් විමසුම් පැරණි කොටස් වලින් පහසුවෙන් කියවිය හැක.
දෙවනුව, කාල සීමාවක් ද ඇත - පැරණි දත්ත කොටස් විනාඩි අටක් තැටියේ පවතී. මෙම මිනිත්තු අට අභිරුචිකරණය කර එක් දිනක් බවට පත් කළ හැකිය. මෙය තැටි අවකාශය වැය කරයි: දත්ත ප්‍රවාහය මත පදනම්ව, අවසාන දිනයේ දත්ත දෙගුණයක් පමණක් නොව, එය පස් ගුණයකින් වැඩි විය හැකි බව පෙනේ. නමුත් බරපතල ගැටළුවක් තිබේ නම්, ඔබට ClickHouse සේවාදායකය නවතා සියල්ල විසඳා ගත හැකිය.
දැන් ප්රශ්නය මතුවන්නේ මෙය වෙනස්වීම් වලින් ආරක්ෂා වන්නේ කෙසේද යන්නයි. මෙහි ගැඹුරින් බැලීම වටී, මන්ද ක්ලික්හවුස් හි පැරණි අනුවාද වල, වෙනස් කිරීම ක්රියා කළේ එය කෙලින්ම කෑලි වෙනස් කරන ආකාරයට ය. සමහර ලිපිගොනු සමඟ දත්ත කැබැල්ලක් ඇත, අපි උදාහරණයක් ලෙස, පතන තීරුව වෙනස් කරන්න. එවිට මෙම තීරුව සියලුම කුට්ටි වලින් භෞතිකව ඉවත් කරනු ලැබේ.
නමුත් 20.3 අනුවාදයෙන් පටන් ගෙන, වෙනස් කිරීමේ යාන්ත්‍රණය සම්පූර්ණයෙන්ම වෙනස් කර ඇති අතර, දැන් දත්ත කැබලි සෑම විටම වෙනස් කළ නොහැක. ඒවා කිසිසේත්ම වෙනස් නොවේ - දැන් වෙනස් කිරීම් ඒකාබද්ධ කරන ආකාරයටම ක්රියා කරයි. එම ස්ථානයේදීම කෑල්ලක් වෙනුවට අපි අලුත් එකක් සාදන්නෙමු. නව කුට්ටිය තුළ, වෙනස් නොවූ ගොනු දෘඪ සබැඳි බවට පත් වන අතර, අපි තීරුවක් මකා දැමුවහොත්, එය නව කුට්ටිය තුළ අතුරුදහන් වනු ඇත. පැරණි කෑල්ල මිනිත්තු අටකට පසු පෙරනිමියෙන් මකා දමනු ඇත, මෙහිදී ඔබට ඉහත සඳහන් කළ සැකසුම් වෙනස් කළ හැකිය.
විකෘති කිරීම් වැනි වෙනස් කිරීම් සඳහා ද එය අදාළ වේ. ඔබ කරන විට මකා දැමීම වෙනස් කරන්න හෝ යාවත්කාලීන වෙනස් කරන්න, එය කෑල්ලක් වෙනස් නොකරයි, නමුත් අලුත් එකක් නිර්මාණය කරයි. ඊට පස්සේ පරණ එක මකනවා.
මේසයේ ව්යුහය වෙනස් වී ඇත්නම් කුමක් කළ යුතුද?
පැරණි යෝජනා ක්රමය සමඟ සාදන ලද උපස්ථයක් ප්රතිස්ථාපනය කරන්නේ කෙසේද? දෙවන ප්රශ්නය වන්නේ ස්නැප්ෂොට් සහ ගොනු පද්ධති මෙවලම් සම්බන්ධ නඩුවයි. Linux LVM හි ZFS වෙනුවට Btrfs හොඳද?
ඔබ කරන්නේ නම් කොටස අමුණන්න වෙනස් ව්යුහයක් සහිත කොටස්, එවිට ClickHouse මෙය කළ නොහැකි බව ඔබට කියනු ඇත. විසඳුම මෙයයි. පළමුවැන්න නම් පැරණි ව්යුහය සමඟ MergeTree ආකාරයේ තාවකාලික වගුවක් නිර්මාණය කිරීම, ඇමුණුම භාවිතයෙන් දත්ත අමුණීම සහ වෙනස් විමසුමක් සෑදීමයි. එවිට ඔබට මෙම දත්ත පිටපත් කිරීමට හෝ මාරු කර නැවත ඇමිණිය හැකිය, නැතහොත් ඉල්ලීමක් භාවිතා කරන්න වගුව මාරු කිරීමේ කොටස වෙනස් කරන්න.
දැන් දෙවන ප්රශ්නය වන්නේ Btrfs භාවිතා කළ හැකිද යන්නයි. ආරම්භ කිරීමට, ඔබට LVM තිබේ නම්, LVM ස්නැප්ෂොට් ප්රමාණවත් වේ, සහ ගොනු පද්ධතිය ext4 විය හැක, එය වැදගත් නොවේ. Btrts සමඟ, සෑම දෙයක්ම එය භාවිතා කිරීමේ ඔබේ අත්දැකීම් මත රඳා පවතී. මෙය පරිණත ගොනු පද්ධතියකි, නමුත් යම් සිද්ධියක් තුළ සෑම දෙයක්ම ප්‍රායෝගිකව ක්රියාත්මක වන්නේ කෙසේද යන්න පිළිබඳව තවමත් යම් සැකයක් පවතී. ඔබ නිෂ්පාදනයේ Btrfs නොමැති නම් මෙය භාවිතා කිරීමට මම නිර්දේශ නොකරමි.
දත්ත නැවත සකස් කිරීමේ වත්මන් හොඳම භාවිතයන් මොනවාද?
නැවත බෙදා හැරීමේ ගැටළුව සංකීර්ණ හා බහුවිධ ය. මෙහි හැකි පිළිතුරු කිහිපයක් තිබේ. ඔබට එක පැත්තකින් ගොස් මෙය පැවසිය හැකිය - ClickHouse හි නැවත බෙදාගැනීමේ අංගයක් නොමැත. ඒත් මට බයයි මේ උත්තරේ කාටවත් ගැලපෙන්නේ නෑ කියලා. ඒ නිසා අනිත් පැත්තෙන් ගිහින් කියන්න පුළුවන් ClickHouse එකේ Data Reshaard කරන්න ගොඩක් ක්‍රම තියෙනවා කියලා.
පොකුරේ ඉඩ අවසන් වුවහොත් හෝ එයට බර දරාගත නොහැකි නම්, ඔබ නව සේවාදායකයන් එක් කරන්න. නමුත් මෙම සේවාදායකයන් පෙරනිමියෙන් හිස් ය, ඒවායේ දත්ත නොමැත, බරක් නොමැත. නව, විශාල පොකුරක් පුරා ඒකාකාරව පැතිරෙන පරිදි දත්ත නැවත සකස් කිරීමට ඔබට අවශ්ය වේ.
මෙය කළ හැකි පළමු ක්රමය වන්නේ ඉල්ලීමක් භාවිතයෙන් කොටස්වල කොටසක් නව සේවාදායකයන් වෙත පිටපත් කිරීමයි වගුව ගෙන ඒම කොටස වෙනස් කරන්න. උදාහරණයක් ලෙස, ඔබට මාසය අනුව කොටස් ඇති අතර, ඔබ 2017 පළමු මාසය ගෙන එය නව සේවාදායකයකට පිටපත් කර, තුන්වන මාසය වෙනත් නව සේවාදායකයකට පිටපත් කරන්න. එය වැඩි හෝ අඩු වන තුරු ඔබ මෙය කරන්න.
මාරු කිරීම සිදු කළ හැක්කේ පටිගත කිරීමේදී වෙනස් නොවන කොටස් සඳහා පමණි. නැවුම් කොටස් සඳහා, ඒවායේ හුවමාරුව පරමාණුක නොවන බැවින්, පටිගත කිරීම අක්රිය කිරීමට සිදුවනු ඇත. එසේ නොමැතිනම්, ඔබ දත්තවල අනුපිටපත් හෝ හිඩැස් සමඟ අවසන් වනු ඇත. කෙසේ වෙතත්, මෙම ක්රමය ප්රායෝගික වන අතර ඉතා ඵලදායී ලෙස ක්රියා කරයි. සූදානම් කළ සම්පීඩිත කොටස් ජාලය හරහා සම්ප්‍රේෂණය වේ, එනම් දත්ත සම්පීඩනය කර හෝ නැවත කේතනය කර නොමැත.
මෙම ක්‍රමයට එක් අඩුපාඩුවක් ඇති අතර, එය බෙදා හැරීමේ ක්රමය මත රඳා පවතී, ඔබ මෙම බෙදා හැරීමේ යෝජනා ක්‍රමයට ප්‍රතිඥා දුන්නේද, ඔබ සතුව තිබූ බෙදා හැරීමේ යතුර කුමක්ද. ප්‍රමිතික සමඟ ඇති අවස්ථාව සඳහා ඔබේ උදාහරණයේ, ෂර්ඩින් යතුර මාර්ගයේ හැෂ් වේ. Distributed table එකක් තෝරගත්තම ඒක cluster එකේ තියෙන ඔක්කොම shards වලට එකපාර ගිහින් එතනින් data ගන්නවා.
මෙයින් අදහස් කරන්නේ කුමන දත්තවල අවසන් වූයේ කුමන දත්තද යන්න ඇත්ත වශයෙන්ම ඔබට වැදගත් නොවන බවයි. ප්රධාන දෙය නම්, එක් මාර්ගයක් ඔස්සේ දත්ත එක් කැබැල්ලකින් අවසන් වන නමුත්, එය වැදගත් නොවේ. මෙම අවස්ථාවේ දී, සූදානම් කළ කොටස් මාරු කිරීම පරිපූර්ණයි, මන්ද තෝරාගත් විමසුම් සමඟ ඔබට සම්පූර්ණ දත්ත ද ලැබෙනු ඇත - නැවත බෙදා හැරීමට පෙර හෝ පසුව වුවද, යෝජනා ක්රමය ඇත්ත වශයෙන්ම වැදගත් නොවේ.
නමුත් වඩාත් සංකීර්ණ අවස්ථා තිබේ. යෙදුම් තාර්කික මට්ටමින් ඔබ විශේෂ බෙදා හැරීමේ යෝජනා ක්රමයක් මත රඳා සිටින්නේ නම්, මෙම සේවාදායකයා එවැනි සහ එවැනි කැබැල්ලක් මත පිහිටා ඇති අතර, ඉල්ලීම කෙලින්ම එහි යැවිය හැකි අතර බෙදා හරින ලද වගුවට නොවේ. නැතහොත් ඔබ ClickHouse හි තරමක් මෑත අනුවාදයක් භාවිතා කරන අතර සැකසීම සක්‍රීය කර ඇත භාවිතයට නොගත් කැබලි මඟ හැරීම ප්‍රශස්ත කරන්න. මෙම අවස්ථාවෙහිදී, තෝරාගත් විමසුම අතරතුර, එම කොටසේ ඇති ප්‍රකාශනය විශ්ලේෂණය කරනු ලබන අතර, බෙදා හැරීමේ යෝජනා ක්‍රමයට අනුව භාවිතා කළ යුතු කැබලි මොනවාදැයි ගණනය කරනු ලැබේ. මෙම බෙදා හැරීමේ යෝජනා ක්‍රමයට අනුව දත්ත හරියටම කොටස් කර ඇති බව මෙම ක්රියා කරයි. ඔබ ඒවා අතින් නැවත සකස් කර ඇත්නම්, ලිපි හුවමාරුව වෙනස් විය හැක.
ඉතින් මේක තමයි අංක එකේ ක්රමය. මම ඔබේ පිළිතුර බලාපොරොත්තුවෙන් සිටිමි, ක්රමය සුදුසුද, නැතහොත් අපි ඉදිරියට යමු.
Vladimir Kolobaev, Avito හි ප්රධාන පද්ධති පරිපාලක: ඇලෙක්සි, කියවීම ඇතුළුව ඔබට බර පතුරුවා හැරීමට අවශ්ය වූ විට ඔබ සඳහන් කළ ක්රමය එතරම් හොඳින් ක්රියා නොකරයි. අපිට පාටිෂන් එකක් මාසිකව ගන්න පුළුවන්, කලින් මාසේ වෙනත් නෝඩ් එකකට ගෙනියන්න පුළුවන්, හැබැයි මේ ඩේටා වලට රික්වෙස්ට් එකක් ආවම ලෝඩ් කරනවා විතරයි. නමුත් අපි මුළු පොකුරම පැටවීමට කැමතියි, එසේ නොමැති නම්, යම් කාලයක් සඳහා සම්පූර්ණ කියවීමේ භාරය කැබලි දෙකකින් සකසනු ඇත.
ඇලෙක්සි මිලොවිඩොව්: මෙහි පිළිතුර අමුතුයි - ඔව්, එය නරකයි, නමුත් එය වැඩ කළ හැකිය. මම හරියටම පැහැදිලි කරන්නම් කොහොමද කියලා. ඔබගේ දත්ත පිටුපසින් එන load scenario දෙස බැලීම වටී. මෙය දත්ත අධීක්ෂණය කරන්නේ නම්, ඉල්ලීම්වලින් බහුතරයක් නැවුම් දත්ත සඳහා බව අපට නිසැකවම පැවසිය හැකිය.
ඔබ නව සේවාදායකයන් ස්ථාපනය කර ඇත, පැරණි කොටස් සංක්‍රමණය කර ඇත, නමුත් නැවුම් දත්ත වාර්තා කරන ආකාරය ද වෙනස් කර ඇත. තවද නැවුම් දත්ත පොකුර පුරා පැතිරෙනු ඇත. මේ අනුව, මිනිත්තු පහකට පසුව, අවසාන මිනිත්තු පහ සඳහා වන ඉල්ලීම් පොකුර ඒකාකාරව පටවනු ඇත; දිනකට පසු, පැය XNUMX සඳහා වන ඉල්ලීම් පොකුර ඒකාකාරව පටවනු ඇත. සහ පෙර මාසය සඳහා ඉල්ලීම්, අවාසනාවකට මෙන්, පොකුරු සේවාදායකයේ කොටසකට පමණක් යයි.
නමුත් බොහෝ විට ඔබට 2019 පෙබරවාරි සඳහා විශේෂයෙන් ඉල්ලීම් නොමැත. බොහෝ දුරට, ඉල්ලීම් 2019 වෙත ගියහොත්, ඒවා සම්පූර්ණ 2019 සඳහා වනු ඇත - විශාල කාලයක් සඳහා මිස කුඩා පරාසයක් සඳහා නොවේ. තවද එවැනි ඉල්ලීම් පොකුර ඒකාකාරව පැටවීමට ද හැකි වනු ඇත. නමුත් පොදුවේ ගත් කල, මෙය දත්ත සම්පූර්ණයෙන්ම ඒකාකාරව පැතිර නොයන තාවකාලික විසඳුමක් බව ඔබේ ප්‍රකාශය සම්පූර්ණයෙන්ම නිවැරදිය.
ප්රශ්නයට පිළිතුරු දීමට මට තවත් කරුණු කිහිපයක් තිබේ. ඒවායින් එකක් නම්, නැවත බෙදා හැරීම අඩු වේදනාවක් ඇති වන පරිදි මුලින් ෂර්ඩින් යෝජනා ක්රමයක් සැලසුම් කරන්නේ කෙසේද යන්නයි. මෙය සැමවිටම කළ නොහැකි දෙයක්.
උදාහරණයක් ලෙස, ඔබට නිරීක්ෂණ දත්ත තිබේ. අධීක්ෂණ දත්ත හේතු තුනක් නිසා වර්ධනය වේ. පළමුවැන්න ඓතිහාසික දත්ත සමුච්චය කිරීමයි. දෙවැන්න රථවාහන වර්ධනයයි. ඒ වගේම තුන් වෙනි එක තමයි අධීක්‍ෂණයට ලක්වෙන දේවල් ප්රමාණය වැඩිවීම. සුරැකීමට අවශ්ය නව ක්ෂුද්‍ර සේවා සහ ප්‍රමිතික ඇත.
මේවායින් විශාලතම වැඩිවීම තුන්වන හේතුව සමඟ සම්බන්ධ විය හැකිය - අධීක්ෂණ භාවිතය වැඩි වීම. මෙම අවස්ථාවේ දී, බරෙහි ස්වභාවය දෙස බැලීම වටී, ප්රධාන තෝරාගත් විමසුම් මොනවාද. මූලික තෝරන විමසුම් බොහෝ විට යම් ප්‍රමිතික උපකුලකයක් මත පදනම් වේ.
උදාහරණයක් ලෙස, සමහර සේවා මගින් සමහර සේවාදායකයන් මත CPU භාවිතය. ඔබ මෙම දත්ත ලබා ගන්නා යතුරු වල නිශ්චිත උප කුලකයක් ඇති බව පෙනේ. තවද මෙම දත්ත සඳහා වන ඉල්ලීම බොහෝ දුරට සරල වන අතර එය මිලි තත්පර දස ගණනකින් සම්පූර්ණ වේ. අධීක්ෂණ සේවා සහ උපකරණ පුවරු සඳහා භාවිතා වේ. මම මෙය නිවැරදිව තේරුම් ගත්තා යැයි මම බලාපොරොත්තු වෙමි.
ව්ලැඩිමීර් කොලොබෙව්: කාරණය නම්, අපි බොහෝ විට ඓතිහාසික දත්ත වෙත ආයාචනා කරනුයේ, අපි වර්තමාන තත්ත්වය ඓතිහාසික තත්ත්වය සමඟ තත්කාලීනව සංසන්දනය කරන බැවිනි. විශාල දත්ත ප්‍රමාණයකට ඉක්මන් ප්‍රවේශයක් ලබා ගැනීම අපට වැදගත් වන අතර ClickHouse මේ සමඟ විශිෂ්ට කාර්යයක් කරයි.
ඔබ සම්පුර්ණයෙන්ම නිවැරදියි, ඕනෑම අධීක්ෂණ පද්ධතියක් මෙන් අපි බොහෝ කියවීම් ඉල්ලීම් අවසාන දිනයේ අත්විඳිමු. නමුත් ඒ සමගම, ඓතිහාසික දත්ත මත පැටවීම ද තරමක් විශාල ය. එය මූලික වශයෙන් සෑම තත්පර තිහකට වරක් යන අනතුරු ඇඟවීමේ පද්ධතියකින් වන අතර ක්ලික්හවුස් වෙත මෙසේ කියයි: “පසුගිය සති හයක දත්ත මට දෙන්න. දැන් මට ඔවුන්ගෙන් යම් ආකාරයක චලනය වන සාමාන්‍යයක් ගොඩනඟන්න, අපි වර්තමාන අගය ඓතිහාසික අගය සමඟ සංසන්දනය කරමු.
එවැනි ඉතා මෑතකාලීන ඉල්ලීම් සඳහා අපට තවත් කුඩා වගුවක් ඇති බවත්, එහි දින දෙකක දත්ත පමණක් ගබඩා කර ඇති බවත්, ප්රධාන ඉල්ලීම් එයට පියාසර කරන බවත් මම පැවසීමට කැමැත්තෙමි. අපි විශාල ඉතිහාස විමසුම් විශාල කැබලි සහිත මේසයට පමණක් යවමු.
ඇලෙක්සි මිලොවිඩොව්: අවාසනාවකට, එය ඔබගේ තත්වය සඳහා දුර්වල ලෙස අදාළ වන නමුත්, භාවිතා කිරීමට අවශ්ය නොවන නමුත් මගේ මිතුරන්ගේ සේවයේ භාවිතා වන නරක සහ සංකීර්ණ බෙදා හැරීමේ යෝජනා ක්‍රම දෙකක් පිළිබඳ විස්තරයක් මම ඔබට කියමි.
Yandex.Metrica සිදුවීම් සහිත ප්රධාන පොකුරක් ඇත. සිදුවීම් යනු පිටු බැලීම්, ක්ලික් කිරීම් සහ පරිවර්තන වේ. බොහෝ ඉල්ලීම් නිශ්චිත වෙබ් අඩවියකට යයි. ඔබ Yandex.Metrica සේවාව විවෘත කරන්න, ඔබට වෙබ් අඩවියක් ඇත - avito.ru, වාර්තාවට යන්න, සහ ඔබේ වෙබ් අඩවිය සඳහා ඉල්ලීමක් කරනු ලැබේ.
නමුත් අභ්යන්තර විශ්ලේෂකයින් විසින් කරනු ලබන වෙනත් ඉල්ලීම් - විශ්ලේෂණාත්මක සහ ගෝලීය - ඇත. යම් අවස්ථාවක දී, අභ්යන්තර විශ්ලේෂකයින් Yandex සේවාවන් සඳහා පමණක් ඉල්ලීම් කරන බව මම සටහන් කරමි. කෙසේ වෙතත්, Yandex සේවාවන් පවා සියලු දත්ත වලින් සැලකිය යුතු කොටසක් හිමි කර ගනී. මේවා විශේෂිත කවුන්ටර සඳහා නොව, පුළුල් පෙරහන සඳහා ඉල්ලීම් වේ.
එක් කවුන්ටරයක් සඳහා සෑම දෙයක්ම කාර්යක්ෂමව ක්රියා කරන ආකාරයට සහ ගෝලීය විමසුම් සඳහා දත්ත සංවිධානය කරන්නේ කෙසේද? තවත් දුෂ්කරතාවයක් වන්නේ Metrics පොකුර සඳහා ClickHouse හි ඉල්ලීම් ගණන තත්පරයකට දහස් ගණනක් වේ. ඒ අතරම, එක් ClickHouse සේවාදායකයකට සුළු නොවන ඉල්ලීම් හැසිරවිය නොහැක, උදාහරණයක් ලෙස, තත්පරයකට දහස් ගණනක්.
පොකුරු ප්රමාණය සේවාදායක හයසියයකි. ඔබ මෙම පොකුර මත බෙදා හරින ලද වගුවක් ඇදගෙන එහි ඉල්ලීම් දහස් ගණනක් යැව්වහොත්, එය එක් සේවාදායකයකට යැවීමට වඩා නරක වනු ඇත. අනෙක් අතට, දත්ත ඒකාකාරව පැතිරී ඇති අතර, අපි ගොස් සියලුම සේවාදායකයන්ගෙන් ඉල්ලා සිටීමේ විකල්පය වහාම ඉවත දමනු ලැබේ.
විෂ්කම්භය ප්රතිවිරුද්ධ විකල්පයක් ඇත. අපි අඩවි හරහා දත්ත බෙදා හැරියහොත්, එක් වෙබ් අඩවියක් සඳහා ඉල්ලීමක් එක් කැබැල්ලකට ගියහොත් සිතන්න. දැන් පොකුරට තත්පරයකට ඉල්ලීම් දසදහසක් හැසිරවීමට හැකි වනු ඇත, නමුත් එක් කැබැල්ලක ඕනෑම ඉල්ලීමක් ඉතා සෙමින් ක්රියා කරයි. එය තවදුරටත් ප්‍රතිදානය අනුව පරිමාණය නොවනු ඇත. විශේෂයෙන්ම මෙය avito.ru වෙබ් අඩවිය නම්. RuNet හි වැඩිපුරම නරඹන අඩවි වලින් එකක් Avito බව මම පැවසුවහොත් මම රහස හෙළි නොකරමි. තවද එය එක් කැබැල්ලක් මත සැකසීම පිස්සුවක් වනු ඇත.
එමනිසා, ෂර්ඩිං යෝජනා ක්රමය වඩාත් කපටි ආකාරයෙන් නිර්මාණය කර ඇත. සම්පූර්ණ පොකුර පොකුරු ගණනාවකට බෙදා ඇත, අපි ඒවා ස්ථර ලෙස හඳුන්වමු. සෑම පොකුරකම කැබලි දුසිමක සිට දුසිම් කිහිපයක් දක්වා ඇත. එවැනි පොකුරු තිස් නවයක් ඇත.
මේ සියල්ල පරිමාණය කරන්නේ කෙසේද? පොකුරු ගණන වෙනස් නොවේ - වසර කිහිපයකට පෙර එය තිස් නවයක් වූ බැවින්, එය එසේ පවතී. නමුත් ඒ සෑම එකක් තුළම අපි දත්ත රැස් කරන විට ක්‍රමයෙන් කැබලි ගණන වැඩි කරමු. සමස්තයක් ලෙස බෙදා හැරීමේ යෝජනා ක්රමය මේ වගේ ය: මෙම පොකුරු වෙබ් අඩවි වලට බෙදා ඇති අතර, කුමන පොකුරේ ඇත්තේ කුමන වෙබ් අඩවියද යන්න තේරුම් ගැනීම සඳහා, MySQL හි වෙනම පරිවෘත්තීය පදනමක් භාවිතා කරයි. එක් අඩවියක් - එක් පොකුරක් මත. ඒවගේම ඒක ඇතුලේ, විසිටර් හැඳුනුම්පත් වලට අනුව ෂර්ඩින් වෙනවා.
පටිගත කිරීමේදී, අපි අමුත්තන්ගේ හැඳුනුම්පතේ බෙදීමේ ඉතිරි කොටස මගින් ඒවා බෙදන්නෙමු. නමුත් නව කැබැල්ලක් එකතු කරන විට, බෙදා හැරීමේ යෝජනා ක්රමය වෙනස් වේ; අපි දිගටම බෙදී යයි, නමුත් බෙදීමේ ඉතිරි කොටස වෙනත් අංකයකින්. මෙයින් අදහස් කරන්නේ එක් අමුත්තෙකු දැනටමත් සේවාදායකයන් කිහිපයක පිහිටා ඇති අතර ඔබට මෙය මත විශ්වාසය තැබිය නොහැකි බවයි. මෙය සිදු කරනුයේ දත්ත වඩා හොඳින් සම්පීඩිත බව සහතික කිරීම සඳහා පමණි. ඉල්ලීම් කරන විට, අපි බෙදා හරින ලද වගුව වෙත යන්නෙමු, එය පොකුර දෙස බලා සේවාදායකයන් දුසිම් ගණනකට ප්‍රවේශ වේ. මේක ඒ තරම් මෝඩ වැඩපිළිවෙලක්.
නමුත් අපි මේ යෝජනා ක්රමය අත්හැරිය බව නොකිව්වොත් මගේ කතාව අසම්පූර්ණයි. නව යෝජනා ක්‍රමයේදී, අපි සියල්ල වෙනස් කර ක්ලික්හවුස්-කොපියර් භාවිතයෙන් සියලුම දත්ත පිටපත් කළෙමු.
නව යෝජනා ක්‍රමයේදී, සියලුම අඩවි විශාල හා කුඩා කාණ්ඩ දෙකකට බෙදා ඇත. එළිපත්ත තෝරා ගත්තේ කෙසේදැයි මම නොදනිමි, නමුත් එහි ප්‍රති result ලය වූයේ එක් පොකුරක් මත විශාල අඩවි පටිගත කර ඇති අතර එහිදී අනුපිටපත් තුනකින් යුත් කැබලි 120 ක් ඇත - එනම් සේවාදායකයන් 360 කි. තවද ෂර්ඩිං ක්රමය නම් ඕනෑම ඉල්ලීමක් එකවර සියලුම කැබලිවලට යන ලෙසය. ඔබ දැන් Yandex.Metrica හි avito.ru සඳහා කිසියම් වාර්තා පිටුවක් විවෘත කරන්නේ නම්, ඉල්ලීම සේවාදායකයන් 120 කට යයි. RuNet හි විශාල අඩවි කිහිපයක් තිබේ. තවද ඉල්ලීම් තත්පරයට දහසක් නොව සියයකට වඩා අඩුය. මේ සියල්ල නිශ්ශබ්දව බෙදා හරින ලද වගුව මගින් හපනු ලබන අතර, ඒ සෑම එකක්ම සේවාදායකයන් 120 කින් ක්රියා කරයි.
දෙවන පොකුර කුඩා අඩවි සඳහා වේ. මෙහි අඩවි හැඳුනුම්පත මත පදනම් වූ බෙදා හැරීමේ ක්රමයක් වන අතර, සෑම ඉල්ලීමක්ම හරියටම එක් කැබැල්ලකට යයි.
ClickHouse හි clickhouse-copier උපයෝගීතාවයක් ඇත. ඔබට ඇය ගැන අපට කියන්න පුළුවන්ද?
මෙම විසඳුම වඩාත් අපහසු සහ තරමක් අඩු ඵලදායී බව මම වහාම කියමි. වාසිය නම් එය ඔබ සඳහන් කරන රටාවට අනුව දත්ත සම්පුර්ණයෙන්ම තැවරීමයි. නමුත් උපයෝගීතාවයේ අවාසිය නම් එය කිසිසේත් නැවත සකස් නොකිරීමයි. එය එක් පොකුරු ක්‍රමයකින් තවත් පොකුරු ක්‍රමයකට දත්ත පිටපත් කරයි.
මෙයින් අදහස් කරන්නේ එය වැඩ කිරීමට ඔබට පොකුරු දෙකක් තිබිය යුතු බවයි. ඒවා එකම සේවාදායකයන් මත ස්ථානගත කළ හැකි නමුත්, කෙසේ වෙතත්, දත්ත වර්ධක ලෙස ගෙන නොයනු ඇත, නමුත් පිටපත් කරනු ලැබේ.
උදාහරණයක් ලෙස, සේවාදායකයන් හතරක් තිබුණි, දැන් අටක් ඇත. ඔබ සියලු සේවාදායකයන්, නව දේශීය වගු මත නව බෙදා හරින ලද වගුවක් සාදා ක්ලික්හවුස්-කොපියර් දියත් කරන්න, එය එහි සිට කියවිය යුතු වැඩ යෝජනා ක්රමය, නව බෙදා හැරීමේ ක්රමය පිළිගෙන දත්ත එහි මාරු කළ යුතුය. තවද පැරණි සේවාදායකයන් මත ඔබට දැන් තිබෙන ප්‍රමාණයට වඩා එකහමාරක් වැඩි ඉඩක් අවශ්ය වනු ඇත, මන්ද පැරණි දත්ත ඒවායේ පැවතිය යුතු අතර පැරණි දත්ත වලින් අඩක් ඒවා මතට පැමිණෙනු ඇත. දත්ත නැවත සකස් කළ යුතු බවත් ඉඩක් ඇති බවත් ඔබ කල්තියා සිතුවා නම්, මෙම ක්රමය සුදුසු වේ.
ක්ලික්හවුස්-කොපියර් ඇතුළත ක්රියා කරන්නේ කෙසේද? එය එක් වගුවක එක් කොටසක් එක් කැබැල්ලක් මත සැකසීම සඳහා සියලු කාර්යයන් කාර්යයන් සමූහයකට කැඩී යයි. මෙම සියලු කාර්යයන් සමාන්තරව ක්රියාත්මක කළ හැකි අතර, clickhouse-copier විවිධ අවස්ථා වලදී විවිධ යන්ත්‍රවල ක්රියාත්මක කළ හැක, නමුත් එය එක් කොටසක් සඳහා කරන්නේ ඇතුල් කිරීම තේරීමකට වඩා වැඩි දෙයක් නොවේ. දත්ත කියවා, විසන්ධි කර, නැවත කොටස් කර, පසුව නැවත සම්පීඩනය කර, කොහේ හරි ලියා, නැවත වර්ග කිරීම. මෙය වඩාත් දැඩි තීරණයකි.
ඔබට නැවත බෙදා හැරීම නම් නියමු දෙයක් තිබුණා. ඇය සමඟ කුමක් ද?
ආපසු 2017 දී, ඔබට නැවත බෙදාගැනීම නම් නියමු දෙයක් තිබුණි. ClickHouse හි පවා විකල්පයක් ඇත. මට තේරෙන විදියට ඒක ගොඩ ගියේ නෑ. මෙය සිදු වූයේ මන්දැයි මට කියන්න පුළුවන්ද? එය ඉතා අදාළ වන බව පෙනේ.
සම්පූර්ණ ගැටළුව වන්නේ දත්ත නැවත සකස් කිරීමට අවශ්ය නම්, මෙය පරමාණුකව සිදු කිරීම සඳහා ඉතා සංකීර්ණ සමමුහුර්තකරණයක් අවශ්ය වීමයි. මෙම සමමුහුර්තකරණය ක්රියාත්මක වන ආකාරය දෙස බැලීමට පටන් ගත් විට, මූලික ගැටළු ඇති බව පැහැදිලි විය. මෙම මූලික ගැටළු න්‍යායික පමණක් නොව, ඉතා සරලව පැහැදිලි කළ හැකි දෙයක ස්වරූපයෙන් වහාම ප්‍රායෝගිකව පෙන්වීමට පටන් ගත්තේය - කිසිවක් ක්රියා නොකරයි.
මන්දගාමී තැටි වෙත ගෙන යාමට පෙර සියලුම දත්ත කොටස් එකට ඒකාබද්ධ කළ හැකිද?
ඒකාබද්ධ කිරීමේ සන්දර්භය තුළ මන්දගාමී තැටි විකල්පය වෙත ගෙනයාම සමඟ TTL පිළිබඳ ප්රශ්නය. මන්දගාමී තැටි වෙත ගෙන යාමට පෙර සියලුම කොටස් එකකට ඒකාබද්ධ කිරීමට ක්‍රෝන් හරහා හැර වෙනත් ක්රමයක් තිබේද?
ප්රශ්නයට පිළිතුර නම්, සියලුම කෑලි මාරු කිරීමට පෙර කෙසේ හෝ ස්වයංක්රීයව එකකට ඇලවිය හැකිය - නැත. මම හිතන්නේ මේක අවශ්ය නැහැ. ඔබට සියලුම කොටස් එකකට ඒකාබද්ධ කිරීමට අවශ්ය නැත, නමුත් ඒවා ස්වයංක්රීයව මන්දගාමී තැටි වෙත මාරු කරනු ලබන බව ගණන් කරන්න.
ස්ථාන මාරු නීති සඳහා අපට නිර්ණායක දෙකක් තිබේ. පළමු එක පිරී ඇති පරිදි ය. වත්මන් ආචයන ස්ථරයේ යම් ප්‍රතිශතයකට වඩා අඩු නිදහස් ඉඩක් තිබේ නම්, අපි එක් කුට්ටියක් තෝරා එය මන්දගාමී ආචයනය වෙත ගෙන යන්නෙමු. එසේත් නැතිනම්, මන්දගාමී නොවේ, නමුත් ඊළඟ එක - ඔබ වින්‍යාස කරන පරිදි.
දෙවන නිර්ණායකය ප්රමාණයයි. එය විශාල කෑලි චලනය කිරීම ගැන ය. වේගවත් තැටියේ ඇති නිදහස් ඉඩ අනුව ඔබට එළිපත්ත සකස් කළ හැකි අතර, දත්ත ස්වයංක්රීයව මාරු කරනු ලැබේ.
කල්තියා ගැළපුම පරීක්ෂා කිරීමට ක්රමයක් නොමැති නම් ClickHouse හි නව අනුවාද වෙත සංක්‍රමණය වන්නේ කෙසේද?
මෙම මාතෘකාව නිතිපතා සාකච්ඡා කෙරේ විවිධ අනුවාදයන් සැලකිල්ලට ගනිමින්, සහ තවමත්. අනුවාදය 19.11 සිට 19.16 දක්වා සහ, උදාහරණයක් ලෙස, 19.16 සිට 20.3 දක්වා යාවත්කාලීන කිරීම කොතරම් ආරක්ෂිතද? වැලිපිල්ලෙහි ගැළපුම කල්තියා පරීක්ෂා කිරීමට නොහැකිව නව අනුවාද වෙත සංක්‍රමණය වීමට හොඳම ක්රමය කුමක්ද?
මෙහි "රන්" නීති කිහිපයක් තිබේ. පලමු - . එය විශාලයි, නමුත් පසුපසට නොගැලපෙන වෙනස්කම් ගැන වෙනම ඡේද ඇත. මෙම කරුණු රතු කොඩියක් ලෙස සලකන්න එපා. මේවා සාමාන්‍යයෙන් ඔබ භාවිතා නොකරන සමහර දාර ක්‍රියාකාරීත්වයන් ඇතුළත් වන සුළු නොගැලපීම් වේ.
දෙවනුව, වැලිපිල්ලෙහි ගැළපුම පරීක්ෂා කිරීමට ක්රමයක් නොමැති නම්, ඔබ නිෂ්පාදනයේ දී වහාම යාවත්කාලීන කිරීමට අවශ්ය නම්, නිර්දේශය වන්නේ ඔබට මෙය කිරීමට අවශ්ය නොවේ. මුලින්ම වැලිපිල්ලක් සාදා පරීක්ෂා කරන්න. පරීක්ෂණ පරිසරයක් නොමැති නම්, ඔබට බොහෝ විට විශාල සමාගමක් නොමැත, එයින් අදහස් කරන්නේ ඔබට සමහර දත්ත ඔබේ ලැප්ටොප් පරිගණකයට පිටපත් කර එහි සෑම දෙයක්ම නිවැරදිව ක්රියාත්මක වන බවට වග බලා ගත හැකි බවයි. ඔබට ඔබේ යන්ත්‍රයේ දේශීයව අනුරූ කිහිපයක් පවා ඉහළ නැංවිය හැක. නැතහොත් ඔබට අසල කොතැනක හෝ නව අනුවාදයක් ගෙන එහි දත්ත කිහිපයක් උඩුගත කළ හැකිය - එනම්, වැඩිදියුණු කළ පරීක්ෂණ පරිසරයක් නිර්මාණය කරන්න.
තවත් රීතියක් වන්නේ නිෂ්පාදනයේ දෝෂ හසුවීම සහ පසුව ඉක්මන් නිවැරදි කිරීම් හේතුවෙන් අනුවාදය නිකුත් කිරීමෙන් සතියකට යාවත්කාලීන නොකිරීමයි. ව්‍යාකූල නොවන පරිදි ClickHouse අනුවාදවල අංකනය හදුනා ගනිමු.
20.3.4 අනුවාදය ඇත. අංක 20 මඟින් නිෂ්පාදිත වර්ෂය - 2020 පෙන්නුම් කරයි. ඇතුළත ඇති දේ පිළිබඳ දෘෂ්ටි කෝණයෙන් මෙය වැදගත් නොවේ, එබැවින් අපි ඒ ගැන අවධානය යොමු නොකරමු. ඊළඟ - 20.3. අපි දෙවන අංකය වැඩි කරමු - මෙම අවස්ථාවෙහි 3 - අපි යම් නව ක්‍රියාකාරීත්වයක් සහිත නිකුතුවක් නිකුත් කරන සෑම අවස්ථාවකම. අපට ClickHouse වෙත යම් විශේෂාංගයක් එක් කිරීමට අවශ්ය නම්, අපි මෙම සංඛ්යාව වැඩි කළ යුතුය. එනම්, 20.4 අනුවාදයේ ක්ලික් හවුස් වඩාත් හොඳින් ක්රියා කරයි. තුන්වන ඉලක්කම් 20.3.4 වේ. මෙහි 4 යනු අපි නව විශේෂාංග එකතු නොකළ නමුත් සමහර දෝෂ නිවැරදි කළ පැච් නිකුතු ගණනයි. ඒ වගේම 4 කියන්නේ අපි හතර වතාවක් කළා.
මේක භයානක දෙයක් කියලා හිතන්න එපා. සාමාන්‍යයෙන් පරිශීලකයාට නවතම අනුවාදය ස්ථාපනය කළ හැකි අතර එය වසරකට අතිකාල සමඟ කිසිදු ගැටළුවක් නොමැතිව ක්රියා කරයි. නමුත් අපගේ චීන සහෘදයින් විසින් එකතු කරන ලද බිට්මැප් සැකසීම සඳහා යම් කාර්යයකදී, වැරදි තර්ක සම්මත කිරීමේදී සේවාදායකය බිඳ වැටෙන බව සිතන්න. මේක හදන්න අපිට වගකීමක් තියෙනවා. අපි නව පැච් අනුවාදයක් නිකුත් කරන අතර ClickHouse වඩාත් ස්ථායී වනු ඇත.
ඔබ ක්ලික්හවුස් නිෂ්පාදනයේ ක්රියාත්මක වන්නේ නම් සහ ක්ලික්හවුස් හි නව අනුවාදයක් අමතර විශේෂාංග සමඟ නිකුත් කර ඇත්නම් - උදාහරණයක් ලෙස, 20.4.1 යනු පළමු එකයි, එය පළමු දිනයේ නිෂ්පාදනය කිරීමට ඉක්මන් නොවන්න. එය පවා අවශ්ය වන්නේ ඇයි? ඔබ දැනටමත් ClickHouse භාවිතා නොකරන්නේ නම්, ඔබට එය ස්ථාපනය කළ හැකිය, බොහෝ විට සියල්ල හොඳින් වනු ඇත. නමුත් ClickHouse දැනටමත් ස්ථායීව ක්රියා කරන්නේ නම්, අපි නිවැරදි කරන ගැටළු මොනවාදැයි බැලීමට පැච් සහ යාවත්කාලීන කිරීම් පිළිබඳව විමසිල්ලෙන් සිටින්න.
කිරිල් ෂ්වාකොව්: මම පරීක්ෂණ පරිසරයන් ගැන ටිකක් එකතු කරන්න කැමතියි. සෑම කෙනෙකුම පරීක්ෂණ පරිසරයන්ට බෙහෙවින් බිය වන අතර කිසියම් හේතුවක් නිසා ඔවුන් විශ්වාස කරන්නේ ඔබට ඉතා විශාල ClickHouse පොකුරක් තිබේ නම්, පරීක්ෂණ පරිසරය අඩු හෝ අවම වශයෙන් දස ගුණයකින් කුඩා විය යුතු බවයි. එය කිසිසේත්ම එසේ නොවේ.
මට මගේම උදාහරණයෙන් කියන්න පුළුවන්. මට ව්‍යාපෘතියක් තියෙනවා, ClickHouse තියෙනවා. අපගේ පරීක්ෂණ පරිසරය ඔහු සඳහා පමණි - මෙය යුරෝ විස්සක් සඳහා Hetzner හි කුඩා අතථ්‍ය යන්ත්‍රයකි, එහිදී නියත වශයෙන්ම සියල්ල යොදවා ඇත. මෙය සිදු කිරීම සඳහා, අපට ඇන්සිබල් හි සම්පූර්ණ ස්වයංක්‍රීයකරණයක් ඇත, එබැවින් ප්රතිපත්තිමය වශයෙන්, යා යුත්තේ කොතැනටද යන්න වෙනසක් නැත - දෘඩාංග සේවාදායකයන් වෙත හෝ අථත්‍ය යන්ත්‍රවල යෙදවීම.
කළ හැක්කේ කුමක්ද? ඔබේම නිවසෙහි කුඩා පොකුරක් යෙදවිය යුතු ආකාරය පිළිබඳ ClickHouse ප්‍රලේඛනයේ උදාහරණයක් සැපයීම සතුටක් වනු ඇත - Docker හි, LXC හි, සමහර විට Ansible playbook එකක් සාදන්න, මන්ද විවිධ පුද්ගලයින්ට විවිධ යෙදවීම් ඇති බැවිනි. මෙය බොහෝ දේ සරල කරනු ඇත. ඔබ විනාඩි පහකින් පොකුරක් ගෙන යෙදවූ විට, යමක් සොයා ගැනීමට උත්සාහ කිරීම වඩාත් පහසු වේ. මෙය වඩාත් පහසු වේ, මන්ද ඔබ පරීක්ෂා නොකළ නිෂ්පාදන අනුවාදයකට පෙරළීම කොතැනකටවත් යා නොහැකි මාර්ගයකි. සමහර විට එය වැඩ කරන අතර සමහර විට එය නොවේ. ඒ නිසා සාර්ථකත්වය බලාපොරොත්තු වීම නරකයි.
Maxim Kotyakov, ජ්යෙෂ්ඨ පසුපෙළ ඉංජිනේරු Avito: විශාල සමාගම් මුහුණ දෙන ගැටළු මාලාවකින් මම පරීක්ෂණ පරිසරයන් ගැන ටිකක් එකතු කරමි. අපට සම්පූර්ණ ClickHouse පිළිගැනීමේ පොකුරක් ඇත; දත්ත යෝජනා ක්‍රම සහ සැකසුම් අනුව, එය නිෂ්පාදනයේ ඇති දේවල නියම පිටපතකි. මෙම පොකුර අවම සම්පත් සහිත තරමක් අඩු කරන ලද බහාලුම්වල යොදවා ඇත. අපි එහි නිෂ්පාදන දත්ත වලින් යම් ප්‍රතිශතයක් ලියන්නෙමු, වාසනාවකට මෙන් කෆ්කා හි ප්‍රවාහය අනුකරණය කළ හැකිය. එහි ඇති සෑම දෙයක්ම සමමුහුර්ත කර පරිමාණය කර ඇත - ධාරිතාව සහ ප්‍රවාහය යන දෙඅංශයෙන්ම, සහ න්‍යායාත්මකව, අනෙක් සියල්ල සමාන වන අතර, එය ප්‍රමිතික අනුව නිෂ්පාදනයක් ලෙස හැසිරිය යුතුය. පුපුරන සුලු විය හැකි සෑම දෙයක්ම මුලින්ම මෙම ස්ථාවරය මතට පෙරළා සූදානම් වන තෙක් දින කිහිපයක් එහි තබයි. නමුත් ස්වභාවිකවම, මෙම විසඳුම මිල අධික, දුෂ්කර සහ ශුන්ය නොවන ආධාරක පිරිවැයක් ඇත.
ඇලෙක්සි මිලොවිඩොව්: Yandex.Metrica වෙතින් අපගේ මිතුරන්ගේ පරීක්ෂණ පරිසරය කෙබඳුදැයි මම ඔබට කියමි. එක පොකුරකට ඔත්තේ සර්වර් 600ක් තිබුනා, තවත් එකක 360ක් තිබුනා, තුන්වෙනි එක සහ පොකුරු කිහිපයක් තියෙනවා. ඒවායින් එකක් සඳහා පරීක්ෂණ පරිසරය හුදෙක් අනුරූ දෙකක් සහිත කැබලි දෙකකි. ඇයි කෑලි දෙකක්? ඒ නිසා ඔබ තනිවම නොවේ. ඒ වගේම අනුරූත් තියෙන්න ඕන. ඔබට දැරිය හැකි අවම මුදලක් පමණි.
මෙම පරීක්ෂණ පරිසරය ඔබගේ විමසුම් ක්රියා කරන්නේද සහ ප්රධාන දෙයක් කැඩී ඇත්දැයි පරීක්ෂා කිරීමට ඔබට ඉඩ සලසයි. නමුත් බොහෝ විට ගැටළු සම්පූර්ණයෙන්ම වෙනස් ස්වභාවයකින් පැන නගී, සෑම දෙයක්ම ක්රියාත්මක වන විට, නමුත් බරෙහි කුඩා වෙනස්කම් කිහිපයක් තිබේ.
මම ඔබට උදාහරණයක් කියන්නම්. අපි ClickHouse හි නව අනුවාදයක් ස්ථාපනය කිරීමට තීරණය කළා. එය පරීක්ෂණ පරිසරයක් මත පළ කර ඇත, Yandex.Metrica තුළම ස්වයංක්‍රීය පරීක්ෂණ සම්පූර්ණ කර ඇත, එය පැරණි අනුවාදයේ සහ නව එකෙහි දත්ත සංසන්දනය කරයි, සම්පූර්ණ නල මාර්ගයම ධාවනය කරයි. ඇත්ත වශයෙන්ම, අපගේ CI හි හරිත පරීක්ෂණ. එසේ නොමැතිනම් අපි මෙම අනුවාදය යෝජනා කරන්නේවත් නැත.
හැම දෙයක්ම හොඳයි. අපි නිෂ්පාදනයට යාමට පටන් ගනිමු. ප්‍රස්ථාරවල බර කිහිප වතාවක් වැඩි වී ඇති බවට මට පණිවිඩයක් ලැබේ. අපි අනුවාදය පෙරළන්නෙමු. මම ප්‍රස්ථාරය දෙස බලා දකිමි: පෙරළීමේදී පැටවීම ඇත්ත වශයෙන්ම කිහිප වතාවක් වැඩි වූ අතර ඒවා පෙරළෙන විට නැවත අඩු විය. ඊට පස්සේ අපි අනුවාදය පෙරළන්න පටන් ගත්තා. ඒවගේම ලෝඩ් එක ඒ විදියටම වැඩි වෙලා ආපහු ඒ විදියටම වැටුනා. එබැවින් නිගමනය මෙයයි: පිරිසැලසුම නිසා බර වැඩි වී ඇත, පුදුම වීමට කිසිවක් නැත.
එවිට නව අනුවාදය ස්ථාපනය කිරීමට සගයන් ඒත්තු ගැන්වීම දුෂ්කර විය. මම කියනවා: "කමක් නෑ, පෙරළන්න. ඔබේ ඇඟිලි හරස් අතට තබා ගන්න, සියල්ල වැඩ කරනු ඇත. දැන් ප්‍රස්ථාරවල බර වැඩි වී ඇත, නමුත් සියල්ල හොඳයි. ඔහොම ඉන්න." පොදුවේ ගත් කල, අපි මෙය කළෙමු, එය එයයි - අනුවාදය නිෂ්පාදනය සඳහා නිකුත් කරන ලදී. නමුත් සෑම පිරිසැලසුමකින්ම පාහේ සමාන ගැටළු මතු වේ.
Kill query මගින් විමසුම් මරා දැමිය යුතු නමුත් එය එසේ නොවේ. ඇයි?
පරිශීලකයෙක්, යම් ආකාරයක විශ්ලේෂකයෙක්, මා වෙත පැමිණ මගේ ClickHouse පොකුරක් තබන ඉල්ලීමක් නිර්මාණය කළේය. කිසියම් නෝඩයක් හෝ සම්පූර්ණ පොකුරක්, ඉල්ලීම ගියේ කුමන අනුරුවට හෝ කැබලිවලටද යන්න මත පදනම්ව. මෙම සේවාදායකයේ සියලුම CPU සම්පත් රාක්කයක ඇති බව මට පෙනේ, සියල්ල රතු ය. ඒ සමගම, ClickHouse විසින්ම ඉල්ලීම් වලට ප්රතිචාර දක්වයි. මම ලියන්නේ: "කරුණාකර මට පෙන්වන්න, ක්‍රියාවලි ලැයිස්තුව, මෙම පිස්සුව ඇති කළේ කුමන ඉල්ලීමද යන්න."
මම මේ ඉල්ලීම සොයාගෙන එයට මරන්න ලියන්නෙමි. ඒ වගේම මම දකිනවා කිසිවක් සිදු නොවන බව. මගේ සේවාදායකය රාක්කයක ඇත, ක්ලික්හවුස් මට විධාන කිහිපයක් ලබා දෙයි, සේවාදායකය ජීවමාන බව පෙන්වයි, සහ සියල්ල විශිෂ්ටයි. නමුත් මට සියලුම පරිශීලක ඉල්ලීම් වල පිරිහීමක් ඇත, ක්ලික් හවුස් හි වාර්තා වලින් පිරිහීම ආරම්භ වේ, සහ මගේ ඝාතන විමසුම ක්රියා නොකරයි. ඇයි? මම හිතුවා කිල් query එක queries මරන්න ඕන කියලා, නමුත් ඒක එහෙම වෙන්නේ නැහැ.
දැන් ටිකක් අමුතු පිළිතුරක් ලැබෙනු ඇත. ප්රශ්නය නම් කිල් විමසුමෙන් විමසුම් මරන්නේ නැත.
Kill query "මට මෙම විමසුම මරා දැමීමට අවශ්‍යයි" නමින් කුඩා කොටුවක් පරීක්ෂා කරයි. එක් එක් වාරණ සැකසීමේදී ඉල්ලීම මෙම ධජය දෙස බලයි. එය සකසා ඇත්නම්, ඉල්ලීම ක්රියා විරහිත වේ. කිසිවෙකු ඉල්ලීම විනාශ නොකරන බව පෙනේ, ඔහුම සියල්ල පරීක්ෂා කර නතර කළ යුතුය. ඉල්ලීම දත්ත සැකසීමේ තත්වයේ පවතින සෑම අවස්ථාවකම මෙය ක්රියා කළ යුතුය. එය මීළඟ දත්ත කොටස සකසනු ඇත, ධජය පරීක්ෂා කර නතර කරයි.
යම් මෙහෙයුමකදී ඉල්ලීම අවහිර වූ අවස්ථා වලදී මෙය ක්රියා නොකරයි. ඇත්ත, බොහෝ දුරට මෙය ඔබගේ කාරණය නොවේ, මන්ද, ඔබට අනුව, එය සේවාදායක සම්පත් ටොන් ගණනක් භාවිතා කරයි. බාහිර වර්ගීකරණයේදී සහ වෙනත් විස්තරවලදී මෙය ක්රියා නොකරනු ඇත. නමුත් පොදුවේ මෙය සිදු නොවිය යුතුය, එය දෝෂයකි. මට නිර්දේශ කළ හැකි එකම දෙය ClickHouse යාවත්කාලීන කිරීමයි.
කියවීමේ බර යටතේ ප්රතිචාර කාලය ගණනය කරන්නේ කෙසේද?
අයිතම එකතු කිරීම් ගබඩා කරන මේසයක් තිබේ - විවිධ කවුන්ටර. රේඛා ගණන ආසන්න වශයෙන් මිලියන සියයකි. ඔබ 1K අයිතම සඳහා 1K RPS වත් කළහොත් පුරෝකථනය කළ හැකි ප්රතිචාර කාලය ගණනය කළ හැකිද?
සන්දර්භය අනුව විනිශ්චය කිරීම, අපි කියවීමේ බර ගැන කතා කරමු, ලිවීමේ ගැටළු නොමැති නිසා - දහසක්, ලක්ෂයක් හෝ සමහර විට පේළි මිලියන කිහිපයක් පවා ඇතුළත් කළ හැකිය.
කියවීමේ ඉල්ලීම් බෙහෙවින් වෙනස් ය. තෝරාගත් 1 හි, ClickHouse හට තත්පරයකට ඉල්ලීම් දස දහස් ගණනක් සිදු කළ හැක, එබැවින් එක් යතුරක් සඳහා වන ඉල්ලීම් සඳහා පවා දැනටමත් යම් සම්පත් අවශ්ය වනු ඇත. තවද එවැනි ලක්ෂ්‍ය විමසුම් සමහර ප්රධාන වටිනාකම් දත්ත සමුදායන්ට වඩා අපහසු වනු ඇත, මන්ද එක් එක් කියවීම සඳහා දර්ශක මගින් දත්ත තොගයක් කියවීම අවශ්ය වේ. අපගේ දර්ශකය ආමන්ත්‍රණය කරන්නේ එක් එක් වාර්තාව නොව, එක් එක් පරාසයයි. එනම්, ඔබට සම්පූර්ණ පරාසය කියවීමට සිදුවනු ඇත - මෙය පෙරනිමියෙන් පේළි 8192 කි. තවද ඔබට සම්පීඩිත දත්ත කොටස 64 KB සිට 1 MB දක්වා විසන්ධි කිරීමට සිදුවේ. සාමාන්‍යයෙන්, එවැනි ඉලක්කගත විමසුම් සම්පූර්ණ කිරීමට මිලි තත්පර කිහිපයක් ගතවේ. නමුත් මෙය සරලම විකල්පයයි.
අපි සරල අංක ගණිතයක් උත්සාහ කරමු. ඔබ මිලි තත්පර කිහිපයක් දහසකින් ගුණ කළහොත් ඔබට තත්පර කිහිපයක් ලැබේ. එය තත්පරයකට ඉල්ලීම් දහසක් සමඟ තබා ගත නොහැකි බවක් පෙනේ, නමුත් ඇත්ත වශයෙන්ම එය කළ හැකිය, මන්ද අපට ප්‍රොසෙසර් කෝර් කිහිපයක් තිබේ. එබැවින්, ප්රතිපත්තිමය වශයෙන්, ClickHouse සමහර විට 1000 RPS රඳවා තබා ගත හැකිය, නමුත් කෙටි ඉල්ලීම් සඳහා, විශේෂයෙන් ඉලක්ක කර ඇත.
ඔබට ක්ලික්හවුස් පොකුරක් සරල ඉල්ලීම් ගණනින් පරිමාණය කිරීමට අවශ්ය නම්, මම සරලම දේ නිර්දේශ කරමි - අනුරූ ගණන වැඩි කර අහඹු අනුරුවකට ඉල්ලීම් යවන්න. එක් අනුරුවක් තත්පරයකට ඉල්ලීම් පන්සියයක් නම්, එය සම්පූර්ණයෙන්ම යථාර්ථවාදී නම්, අනුරූ තුනක් එකහමාරක් හසුරුවනු ඇත.
සමහර විට, ඇත්ත වශයෙන්ම, ඔබට උපරිම ලකුණු කියවීම් ගණන සඳහා ClickHouse වින්‍යාසගත කළ හැකිය. මේ සඳහා අවශ්ය වන්නේ කුමක්ද? පළමුවැන්න නම් දර්ශකයේ කැටිති අඩු කිරීමයි. මෙම අවස්ථාවෙහිදී, එය එකකට අඩු නොකළ යුතුය, නමුත් දර්ශකයේ ඇතුළත් කිරීම් සංඛ්යාව එක් සේවාදායකයකට මිලියන කිහිපයක් හෝ දස දහස් ගණනක් වනු ඇත. මේසයේ පේළි මිලියන සියයක් තිබේ නම්, කැටිති 64 ලෙස සැකසිය හැක.
ඔබට සම්පීඩිත බ්ලොක් ප්රමාණය අඩු කළ හැකිය. මේ සඳහා සැකසුම් ඇත min සම්පීඩන බ්ලොක් ප්රමාණය, උපරිම සම්පීඩන බ්ලොක් ප්රමාණය. ඒවා අඩු කළ හැකි අතර, දත්ත සමඟ නැවත පිරවිය හැකි අතර, පසුව ඉලක්කගත විමසුම් වේගවත් වනු ඇත. නමුත් තවමත්, ClickHouse යනු ප්රධාන අගය දත්ත ගබඩාවක් නොවේ. කුඩා ඉල්ලීම් විශාල සංඛ්යාවක් load antipattern වේ.
කිරිල් ෂ්වාකොව්: සාමාන්ය ගිණුම් තියෙනවා නම් මම උපදෙස් දෙන්නම්. ClickHouse යම් ආකාරයක කවුන්ටරයක් ගබඩා කරන විට මෙය තරමක් සම්මත තත්වයකි. මට පරිශීලකයෙක් සිටී, ඔහු එවැනි රටකින්, සහ සමහර තුන්වන ක්ෂේත්‍රයකින්, මට යමක් වැඩි කළ යුතුය. MySQL ගන්න, අද්විතීය යතුරක් සාදන්න - MySQL හි එය අනුපිටපත් යතුරක් වන අතර, PostgreSQL හි එය ගැටුමකි - සහ ප්ලස් ලකුණක් එක් කරන්න. මෙය වඩා හොඳින් වැඩ කරනු ඇත.
ඔබ සතුව වැඩි දත්ත නොමැති විට, ClickHouse භාවිතා කිරීමේ වැඩි ප්‍රයෝජනයක් නොමැත. සාමාන්ය දත්ත සමුදායන් ඇති අතර ඔවුන් මෙය හොඳින් කරයි.
වැඩි දත්ත හැඹිලියේ ඇති වන පරිදි ක්ලික් හවුස් තුළ මට වෙනස් කළ හැක්කේ කුමක්ද?
අපි යම් තත්වයක් සිතමු - සේවාදායකයන් සතුව RAM 256 GB ඇත, දෛනික චර්යාවේදී ClickHouse 60-80 GB පමණ ගත වේ, උපරිම - 130 දක්වා. වැඩි දත්තයක් හැඹිලියේ ඇති වන පරිදි සක්‍රීය කර වෙනස් කළ හැකි දේ සහ ඒ අනුව, තැටියට සංචාර අඩුද?
සාමාන්‍යයෙන්, මෙහෙයුම් පද්ධතියේ පිටු හැඹිලිය මේ සඳහා හොඳ කාර්යයක් කරයි. ඔබ හුදෙක් ඉහළ කොටස විවෘත කළහොත්, එහි හැඹිලිගත හෝ නොමිලේ බලන්න - එය කොපමණ හැඹිලිගත වී ඇත්දැයි ද කියයි - එවිට සියලුම නිදහස් මතකය හැඹිලිය සඳහා භාවිතා කරන බව ඔබට පෙනෙනු ඇත. තවද මෙම දත්ත කියවන විට, එය තැටියෙන් නොව, RAM එකෙන් කියවනු ඇත. ඒ අතරම, හැඹිලිය ඵලදායි ලෙස භාවිතා වන බව මට පැවසිය හැකිය, මන්ද එය හැඹිලිගත වන්නේ සම්පීඩිත දත්ත බැවිනි.
කෙසේ වෙතත්, ඔබට තවත් සරල විමසුම් කිහිපයක් වේගවත් කිරීමට අවශ්ය නම්, ClickHouse තුළ ඇති විසංයෝජනය කළ දත්තවල හැඹිලියක් සක්‍රීය කළ හැකිය. එය හැඳින්වේ සම්පීඩිත නොකළ හැඹිලිය. config.xml වින්‍යාස ගොනුවේ, ඔබට අවශ්ය අගයට සම්පීඩිත නොවන හැඹිලි ප්රමාණය සකසන්න - මම නොමිලේ RAM වලින් අඩකට වඩා නිර්දේශ නොකරමි, මන්ද ඉතිරිය පිටු හැඹිලිය යටතට යනු ඇත.
මීට අමතරව, ඉල්ලීම් මට්ටමේ සැකසුම් දෙකක් ඇත. පළමු සැකසුම - සම්පීඩිත නොකළ හැඹිලි භාවිතා කරන්න - එහි භාවිතය ඇතුළත් වේ. සියලුම දත්ත කියවා හැඹිලිය ෆ්ලෂ් කළ හැකි බර ඉල්ලීම් හැර අනෙකුත් සියලුම ඉල්ලීම් සඳහා එය සක්‍රීය කිරීම නිර්දේශ කෙරේ. දෙවන සැකසුම යනු හැඹිලිය භාවිතා කිරීමට ඇති උපරිම පේළි ගණන වැනි දෙයකි. එය විශාල විමසුම් ස්වයංක්රීයව සීමා කරන අතර එමඟින් ඒවා හැඹිලිය මග හැරේ.
RAM හි ගබඩා කිරීම සඳහා ගබඩා_වින්‍යාසය වින්‍යාසගත කරන්නේ කෙසේද?
නව ClickHouse ප්‍රලේඛනයේ මම අදාළ කොටස කියෙව්වා . විස්තරයේ වේගවත් SSD සහිත උදාහරණයක් අඩංගු වේ.
පරිමාව උණුසුම් මතකය සමඟ එකම දේ වින්‍යාසගත කරන්නේ කෙසේදැයි මම කල්පනා කරමි. සහ තවත් එක් ප්රශ්නයක්. මෙම දත්ත සංවිධානය සමඟ තේරීම ක්රියා කරන්නේ කෙසේද, එය සම්පූර්ණ කට්ටලයම හෝ තැටියේ ඇති එක පමණක් කියවයිද, මෙම දත්ත මතකයේ සම්පීඩිතද? සහ එවැනි දත්ත සංවිධානයක් සමඟ පෙර තැන කොටස ක්රියා කරන්නේ කෙසේද?
මෙම සැකසුම දත්ත කොටස් ගබඩා කිරීමට බලපාන අතර, ඒවායේ ආකෘතිය කිසිදු ආකාරයකින් වෙනස් නොවේ.
අපි සමීපව බලමු.
ඔබට RAM හි දත්ත ගබඩාව වින්‍යාසගත කළ හැක. තැටිය සඳහා වින්‍යාස කර ඇති සියල්ල එහි මාර්ගයයි. ඔබ විසින් ගොනු පද්ධතියේ කිසියම් මාර්ගයකට සවිකර ඇති tmpfs කොටසක් නිර්මාණය කරයි. උණුසුම්ම කොටස සඳහා දත්ත ගබඩා කිරීමේ මාර්ගය ලෙස ඔබ මෙම මාර්ගය සඳහන් කරයි, දත්ත කෑලි පැමිණීමට පටන් ගෙන එහි ලිවීමට පටන් ගනී, සියල්ල හොඳයි.
නමුත් අඩු විශ්වසනීයත්වය නිසා මෙය කිරීමට මම නිර්දේශ නොකරමි, නමුත් ඔබට විවිධ දත්ත මධ්‍යස්ථානවල අවම වශයෙන් අනුපිටපත් තුනක්වත් තිබේ නම්, එය කළ හැකි ය. යමක් සිදුවුවහොත්, දත්ත ප්රතිෂ්ඨාපනය වේ. අපි හිතමු සර්වර් එක එකපාරටම ඕෆ් කරලා ආපහු ඔන් කළා කියලා. කොටස නැවත සවි කර ඇත, නමුත් එහි කිසිවක් නොතිබුණි. ClickHouse සේවාදායකය ආරම්භ වූ විට, එය මෙම කෑලි නොමැති බව දකියි, කෙසේ වෙතත්, ZooKeeper පාරදත්ත අනුව, ඒවා එහි තිබිය යුතුය. මොන රෙප්ලිකේස් තියෙනවද කියලා බලලා ඉල්ලලා ඩවුන්ලෝඩ් කරනවා. මේ ආකාරයෙන් දත්ත ප්රතිෂ්ඨාපනය වේ.
මෙම අර්ථයෙන් ගත් කල, RAM හි දත්ත ගබඩා කිරීම තැටියේ ගබඩා කිරීමට වඩා මූලික වශයෙන් වෙනස් නොවේ, මන්ද දත්ත තැටියට ලියන විට එය මුලින්ම පිටු හැඹිලියේ අවසන් වන අතර පසුව භෞතිකව ලියා ඇත. මෙය ගොනු පද්ධති සවිකිරීමේ විකල්පය මත රඳා පවතී. නමුත් යම් අවස්ථාවක දී, ඇතුල් කිරීමේදී ClickHouse fsync නොවන බව මම කියමි.
මෙම අවස්ථාවෙහිදී, RAM හි දත්ත තැටියේ ඇති ආකාරයටම ගබඩා කර ඇත. Select query එක ඒ විදියටම කියවන්න ඕන කෑලි තෝරලා, කෑලි වල අවශ්ය data ranges තෝරලා, කියවනවා. දත්ත RAM එකේ තිබුණත් තැටියේ තිබුණත්, prewhere හරියටම එකම විදිහට ක්රියා කරයි.
අඩු කාර්ඩිනලිටි ඵලදායී වන්නේ අද්විතීය අගයන් ගණන කොපමණද?
Low Cardinality දක්ෂ ලෙස නිර්මාණය කර ඇත. එය දත්ත ශබ්දකෝෂ සම්පාදනය කරයි, නමුත් ඒවා දේශීය වේ. පළමුව, එක් එක් කෑල්ල සඳහා විවිධ ශබ්ද කෝෂ ඇති අතර, දෙවනුව, එක් කැබැල්ලක් තුළ පවා ඒවා එක් එක් පරාසය සඳහා වෙනස් විය හැකිය. අද්විතීය අගයන් සංඛ්යාව සීමාවකට ළඟා වූ විට - මිලියනයක්, මම හිතන්නේ - ශබ්දකෝෂය සරලව තබා ඇති අතර නව එකක් නිර්මාණය වේ.
පිළිතුර පොදුවේ: එක් එක් දේශීය පරාසය සඳහා - කියන්න, එක් එක් දින සඳහා - කොහේ හරි අද්විතීය අගයන් මිලියනයක් දක්වා අඩු කාර්ඩිනලිටි ඵලදායී වේ. ඉන් පසුව, එක් ශබ්දකෝෂයක් පමණක් නොව, විවිධ ශබ්ද කෝෂ භාවිතා කරනු ලබන සරල පසුබෑමක් සිදුවනු ඇත. එය සාමාන්ය තන්තු තීරුවක් මෙන් ආසන්න වශයෙන් ක්රියා කරනු ඇත, සමහර විට ටිකක් අඩු කාර්යක්ෂම වේ, නමුත් බරපතල කාර්ය සාධන පිරිහීමක් සිදු නොවනු ඇත.
පේළි බිලියන පහක් සහිත වගුවක් සම්පූර්ණ පෙළ සෙවීම සඳහා හොඳම භාවිතයන් මොනවාද?
විවිධ පිළිතුරු ඇත. පළමුවැන්න නම් ClickHouse යනු සම්පූර්ණ පෙළ සෙවුම් යන්ත්‍රයක් නොවන බව පැවසීමයි. මේ සඳහා විශේෂ පද්ධති තිබේ, උදාහරණයක් ලෙස, и . කෙසේ වෙතත්, ඔවුන් Elasticsearch සිට ClickHouse වෙත මාරු වන බව පවසන පුද්ගලයින් මම වැඩි වැඩියෙන් දකිමි.
මෙය සිදු වන්නේ ඇයි? ඔවුන් මෙය පැහැදිලි කරන්නේ දර්ශක ගොඩනැගීමෙන් පටන් ගෙන සමහර වෙළුම් වල බර සමඟ සාර්ථකව කටයුතු කිරීම Elasticsearch නවත්වන බැවිනි. දර්ශක ඉතා අපහසු වන අතර, ඔබ ක්ලික්හවුස් වෙත දත්ත මාරු කරන්නේ නම්, ඒවා පරිමාව අනුව කිහිප ගුණයකින් වඩා කාර්යක්ෂමව ගබඩා කර ඇති බව පෙනේ. ඒ අතරම, සෙවුම් විමසුම් බොහෝ විට රූප විද්‍යාව සැලකිල්ලට ගනිමින් සමස්ත දත්ත පරිමාවේ යම් වාක්‍ය ඛණ්ඩයක් සොයා ගැනීමට අවශ්ය නොවන නමුත් සම්පූර්ණයෙන්ම වෙනස් ඒවා විය. උදාහරණයක් ලෙස, පසුගිය පැය කිහිපය තුළ ලොග් වල බයිට් අනුපිළිවෙලක් සොයා ගන්න.
මෙම අවස්ථාවෙහිදී, ඔබ ClickHouse හි දර්ශකයක් සාදන්න, එහි පළමු ක්ෂේත්‍රය දිනය සහ වේලාව වේ. තවද විශාලතම දත්ත කපා හැරීම දින පරාසය මත පදනම් වේ. තෝරාගත් දින පරාසය තුළ, රීතියක් ලෙස, බෲට් ෆෝර්ස් ක්රමය භාවිතයෙන් වුවද, සම්පූර්ණ පෙළ සෙවුමක් කිරීමට දැනටමත් හැකි ය. ClickHouse හි ඇති සමාන ක්‍රියාකරු ඔබට සොයා ගත හැකි වඩාත්ම කාර්යක්ෂම ක්‍රියාකරු වේ. ඔබට වඩා හොඳ දෙයක් හමු වුවහොත් මට කියන්න.
නමුත් තවමත්, සම්පූර්ණ ස්කෑන් කිරීමක් වගේ. සහ සම්පූර්ණ ස්කෑන් කිරීම CPU මත පමණක් නොව, තැටියේ ද මන්දගාමී විය හැක. හදිසියේම ඔබට දිනකට ටෙරාබයිට් එකක දත්ත තිබේ නම් සහ ඔබ දිවා කාලයේ වචනයක් සොයන්නේ නම්, ඔබට ටෙරාබයිට් ස්කෑන් කිරීමට සිදුවේ. තවද එය බොහෝ විට සාමාන්ය දෘඪ තැටි මත ඇති අතර, අවසානයේදී ඔබට SSH හරහා මෙම සේවාදායකයට ප්‍රවේශ වීමට නොහැකි වන ආකාරයෙන් ඒවා පටවනු ලැබේ.
මෙම අවස්ථාවේ දී, මම තවත් කුඩා උපක්රමයක් ඉදිරිපත් කිරීමට සූදානම්. එය පර්යේෂණාත්මක ය - එය ක්රියාත්මක විය හැකිය, එය නොවීමට ඉඩ ඇත. ClickHouse සතුව ට්‍රයිග්‍රෑම් බ්ලූම් ෆිල්ටර් ආකාරයෙන් සම්පූර්ණ පෙළ දර්ශක ඇත. Arenadata හි අපගේ සගයන් දැනටමත් මෙම දර්ශක උත්සාහ කර ඇති අතර, ඔවුන් බොහෝ විට අපේක්ෂිත පරිදිම ක්රියා කරයි.
ඒවා නිවැරදිව භාවිතා කිරීම සඳහා, ඒවා ක්රියා කරන ආකාරය පිළිබඳව ඔබට හොඳ අවබෝධයක් තිබිය යුතුය: බ්ලූම් ෆිල්ටරය යනු කුමක්ද සහ එහි ප්රමාණය තෝරා ගන්නේ කෙසේද. දත්තවල කලාතුරකින් දක්නට ලැබෙන සමහර දුර්ලභ වාක්‍ය ඛණ්ඩ, උප තන්තු පිළිබඳ විමසීම් සඳහා ඒවා උපකාර වන බව මට පැවසිය හැකිය. මෙම අවස්ථාවෙහිදී, උපපරාසයන් දර්ශක මගින් තෝරා ගනු ලබන අතර අඩු දත්ත කියවනු ලැබේ.
මෑතකදී, ClickHouse විසින් සම්පූර්ණ පෙළ සෙවීම සඳහා ඊටත් වඩා උසස් කාර්යයන් එක් කර ඇත. මෙය, පළමුව, UTF-8 සඳහා සහාය ඇතිව හෝ ASCII සඳහා පමණක් වන අවස්ථා-සංවේදී, සිද්ධි සංවේදී නොවන විකල්ප ඇතුළුව, එක් වරමකදී එකවර උපස්ථර සමූහයක් සඳහා සෙවීමකි. ඔබට අවශ්ය වඩාත්ම ඵලදායී එකක් තෝරන්න.
එක් පාස් එකක බහු සාමාන්ය ප්‍රකාශන සඳහා සෙවීම ද දර්ශනය වී ඇත. ඔබට එක් උපස්ථරයක් මෙන් X හෝ තවත් උපස්ථරයක් මෙන් X ලිවීමට අවශ්ය නොවේ. ඔබ වහාම ලියන්න, සෑම දෙයක්ම හැකි තරම් කාර්යක්ෂමව සිදු කරනු ලැබේ.
තෙවනුව, දැන් regexps සඳහා ආසන්න සෙවුමක් සහ උපස්ථර සඳහා ආසන්න සෙවුමක් ඇත. කවුරුහරි වචනයක් වැරදියට ලිව්වොත් ඒක උපරිම ගැලපීමට සොයනවා.
පරිශීලකයින් විශාල සංඛ්යාවක් සඳහා ClickHouse වෙත ප්රවේශය සංවිධානය කිරීමට හොඳම ක්රමය කුමක්ද?
පාරිභෝගිකයින් සහ විශ්ලේෂකයින් විශාල සංඛ්යාවක් සඳහා ප්රවේශය සංවිධානය කරන්නේ කෙසේදැයි අපට කියන්න. පෝලිමක් සාදා ගන්නේ කෙසේද, උපරිම සමගාමී විමසුම්වලට ප්රමුඛත්වය දෙන්නේ කෙසේද සහ කුමන මෙවලම් සමඟද?
පොකුර ප්රමාණවත් තරම් විශාල නම්, හොඳ විසඳුමක් වනුයේ තවත් සේවාදායකයන් දෙකක් ඉහළ නැංවීමයි, එය විශ්ලේෂකයින් සඳහා ප්‍රවේශ ස්ථානයක් බවට පත්වනු ඇත. එනම්, විශ්ලේෂකයින්ට පොකුරේ ඇති විශේෂිත කොටස් වෙත ප්‍රවේශ වීමට ඉඩ නොදෙන්න, නමුත් දත්ත නොමැතිව හිස් සේවාදායකයන් දෙකක් සාදා ඒවා මත ප්‍රවේශ අයිතිවාසිකම් වින්‍යාස කරන්න. මෙම අවස්ථාවේදී, බෙදා හරින ලද ඉල්ලීම් සඳහා පරිශීලක සැකසුම් දුරස්ථ සේවාදායකයන් වෙත මාරු කරනු ලැබේ. එනම්, ඔබ මෙම සේවාදායකයන් දෙකෙහි සෑම දෙයක්ම වින්‍යාස කර ඇති අතර, සැකසුම් සම්පූර්ණ පොකුරට බලපායි.
ප්රතිපත්තිමය වශයෙන්, මෙම සේවාදායකයන්ට දත්ත නොමැත, නමුත් ඉල්ලීම් ක්රියාත්මක කිරීම සඳහා ඒවායේ RAM ප්රමාණය ඉතා වැදගත් වේ. බාහිර එකතු කිරීම හෝ බාහිර වර්ග කිරීම සක්රිය කර තිබේ නම් තැටිය තාවකාලික දත්ත සඳහා ද භාවිතා කළ හැක.
හැකි සියලු සීමාවන් සමඟ සම්බන්ධ වී ඇති සැකසුම් දෙස බැලීම වැදගත් වේ. මම දැන් විශ්ලේෂකයෙකු ලෙස Yandex.Metrica පොකුරට ගොස් ඉල්ලීමක් කළහොත් පහර වලින් ගණන් තෝරන්න, එවිට මට ඉල්ලීම ක්රියාත්මක කළ නොහැකි බවට වහාම ව්යතිරේකයක් ලබා දෙනු ඇත. මට ස්කෑන් කිරීමට අවසර දී ඇති උපරිම පේළි ගණන බිලියන සියයක් වන අතර, පොකුරේ එක් වගුවක ඒවායින් ට්‍රිලියන පනහක් ඇත. මෙය පළමු සීමාවයි.
අපි කියමු මම පේළි සීමාව ඉවත් කර නැවත විමසුම ක්රියාත්මක කළෙමි. එවිට මම පහත ව්‍යතිරේකය දකිනු ඇත - සැකසීම සක්‍රීය කර ඇත දිනය අනුව බල දර්ශකය. මම දින පරාසයක් සඳහන් කර නොමැති නම් මට විමසුම සම්පූර්ණ කළ නොහැක. එය අතින් සඳහන් කිරීමට ඔබ විශ්ලේෂකයින් මත විශ්වාසය තැබිය යුතු නැත. සාමාන්ය අවස්ථාවක් වන්නේ දින පරාසයක් ලියා ඇති විට, එහිදී සිදුවීම් දිනය සතිය අතර වේ. ඉන්පසු ඔවුන් හුදෙක් වරහනක් වැරදි ස්ථානයක සඳහන් කර ඇති අතර, ඒ වෙනුවට එය හෝ - හෝ URL ගැලපීම බවට පත් විය. සීමාවක් නොමැති නම්, එය URL තීරුව රිංගා සම්පත් ටොන් ගණනක් නාස්ති කරයි.
මීට අමතරව, ClickHouse හි ප්‍රමුඛතා සැකසුම් දෙකක් ඇත. අවාසනාවකට මෙන්, ඔවුන් ඉතා ප්රාථමික ය. එකක් සරලව හැඳින්වේ ප්රමුඛත්වය. ප්‍රමුඛතාවය ≠ 0, සහ යම් ප්‍රමුඛතාවයක් සහිත ඉල්ලීම් ක්රියාත්මක කරන්නේ නම්, නමුත් ඊට වඩා අඩු ප්‍රමුඛතා අගයක් සහිත ඉල්ලීමක්, එනම් ඉහළ ප්‍රමුඛතාවක්, ක්රියාත්මක වන්නේ නම්, වැඩි ප්‍රමුඛතා අගයක් සහිත ඉල්ලීමක්, එනම් අඩු ප්‍රමුඛතාවයක් සහිත ඉල්ලීමක් , හුදෙක් අත්හිටුවා ඇති අතර මෙම කාලය තුළ කිසිසේත්ම ක්රියා නොකරනු ඇත.
මෙය ඉතා ගොරහැඩි සැකසුමක් වන අතර පොකුරේ නිරන්තර බරක් ඇති අවස්ථාවන් සඳහා සුදුසු නොවේ. නමුත් ඔබට වැදගත් වන කෙටි, පිපිරුම් ඉල්ලීම් තිබේ නම් සහ පොකුර බොහෝ දුරට ක්රියා විරහිත නම්, මෙම සැකසුම සුදුසු වේ.
ඊළඟ ප්‍රමුඛතා සැකසුම ලෙස හැඳින්වේ OS නූල් ප්‍රමුඛතාවය. එය ලිනක්ස් උපලේඛනය සඳහා සියලුම ඉල්ලීම් ක්රියාත්මක කිරීමේ නූල් සඳහා හොඳ අගයක් සකසයි. එය එසේ ක්රියා කරයි, නමුත් එය තවමත් ක්රියාත්මක වේ. ඔබ අවම ලස්සන අගයක් සකසන්නේ නම් - එය අගයෙන් විශාලතම වන අතර, එම නිසා අඩුම ප්‍රමුඛතාවය - සහ ඉහළ ප්‍රමුඛතාවයක් සහිත ඉල්ලීම් සඳහා -19 සකසන්නේ නම්, එවිට CPU ඉහළ ප්‍රමුඛතා ඉල්ලීම්වලට වඩා හතර ගුණයකින් අඩු ප්‍රමුඛතා ඉල්ලීම් පරිභෝජනය කරයි.
ඔබට උපරිම ඉල්ලීම ක්රියාත්මක කිරීමේ කාලය වින්‍යාස කිරීමට අවශ්ය වේ - කියන්න, මිනිත්තු පහක්. විමසුම් ක්රියාත්මක කිරීමේ අවම වේගය සිසිල්ම දෙයයි. මෙම සැකසුම දිගු කලක් තිස්සේ පවතින අතර, ClickHouse මන්දගාමී නොවන බව තහවුරු කිරීම පමණක් නොව, එය බල කිරීම අවශ්ය වේ.
සිතන්න, ඔබ පිහිටුවා ඇත: සමහර විමසුම් තත්පරයකට පේළි මිලියනයකට වඩා අඩු නම්, ඔබට එය කළ නොහැක. මෙය අපගේ හොඳ නම, අපගේ හොඳ දත්ත සමුදාය අපකීර්තියට පත් කරයි. අපි මේක තහනම් කරමු. ඇත්ත වශයෙන්ම සැකසුම් දෙකක් තිබේ. එකක් ලෙස හැඳින්වේ min ක්රියාත්මක කිරීමේ වේගය - තත්පරයට පේළි වලින්, සහ තත්පර මිනි ක්රියාත්මක කිරීමේ වේගය පරීක්ෂා කිරීමට පෙර දෙවැන්න කල් ඉකුත්වීම ලෙස හැඳින්වේ - පෙරනිමියෙන් තත්පර පහළොවක්. එනම්, තත්පර පහළොවක් හැකි ය, පසුව, එය මන්දගාමී නම්, ව්යතිරේකයක් දමා ඉල්ලීම නවත්වන්න.
ඔබට කෝටා සැකසීමටද අවශ්ය වේ. ClickHouse සතුව සම්පත් පරිභෝජනය ගණනය කරන ගොඩනඟන ලද කෝටා විශේෂාංගයක් ඇත. එහෙත්, අවාසනාවකට මෙන්, CPU, තැටි වැනි දෘඪාංග සම්පත් නොව තාර්කික ඒවා - සැකසූ ඉල්ලීම් ගණන, රේඛා සහ බයිට් කියවා ඇත. ඔබට වින්‍යාසගත කළ හැකිය, උදාහරණයක් ලෙස, මිනිත්තු පහක් ඇතුළත උපරිම ඉල්ලීම් සියයක් සහ පැයකට ඉල්ලීම් දහසක්.
එය වැදගත් වන්නේ ඇයි? සමහර විශ්ලේෂණ විමසුම් ClickHouse සේවාලාභියා වෙතින් සෘජුවම අතින් සිදු කෙරෙන නිසා. සහ සියල්ල හොඳින් වනු ඇත. නමුත් ඔබේ ආයතනයේ උසස් විශ්ලේෂකයින් සිටී නම්, ඔවුන් පිටපතක් ලියන අතර, පිටපතේ දෝෂයක් ඇති විය හැක. තවද මෙම දෝෂය හේතුවෙන් ඉල්ලීම අනන්ත ලූපයක් තුළ ක්රියාත්මක වේ. මේකෙන් තමයි අපි ආරක්ෂා වෙන්න ඕන.
එක් විමසුමක ප්‍රතිඵල සේවාදායකයින් දහ දෙනෙකුට ලබා දිය හැකිද?
එකම වේලාවක ඉතා විශාල ඉල්ලීම් සමඟ පැමිණීමට කැමති පරිශීලකයින් කිහිප දෙනෙකු අප සතුව ඇත. ඉල්ලීම විශාල වන අතර ප්රතිපත්තිමය වශයෙන් ඉක්මනින් ක්රියාත්මක වේ, නමුත් එකවර එවැනි ඉල්ලීම් රාශියක් තිබීම නිසා එය ඉතා වේදනාකාරී වේ. එක දිගට දහ පාරක් ආපු එකම රික්වෙස්ට් එක එක පාරක් ක්රියාත්මක කරලා ප්‍රතිඵලය සේවාදායකයින් දහයකට දෙන්න පුළුවන්ද?
ගැටළුව වන්නේ අතරමැදි දත්තවල හැඹිලියේ හෝ හැඹිලියේ ප්‍රතිඵල අප සතුව නොමැති වීමයි. මෙහෙයුම් පද්ධතියේ පිටු හැඹිලියක් ඇත, එය නැවත තැටියෙන් දත්ත කියවීමෙන් ඔබව වළක්වනු ඇත, නමුත්, අවාසනාවකට මෙන්, දත්ත තවමත් විසංයෝජනය, deserialized සහ නැවත සකසනු ඇත.
අතරමැදි දත්ත හැඹිලිගත කිරීමෙන් හෝ යම් ආකාරයක පෝලිමක සමාන විමසුම් පෙළගස්වා ප්‍රතිඵල හැඹිලියක් එක් කිරීමෙන් මෙය කෙසේ හෝ වළක්වා ගැනීමට මම කැමැත්තෙමි. අපට දැනට සංවර්ධනයේ එක් ඇදීමේ ඉල්ලීමක් ඇත, එය ඉල්ලීම් හැඹිලියක් එක් කරයි, නමුත් ඇතුලේ සහ සම්බන්ධ වන කොටස්වල උප විමසුම් සඳහා පමණි - එනම් විසඳුම අසම්පූර්ණයි.
කොහොම වුණත් අපිත් එවැනි තත්ත්වයකට මුහුණ දෙනවා. විශේෂයෙන් කැනොනිකල් උදාහරණයක් වන්නේ පිටුගත විමසුම් ය. වාර්තාවක් ඇත, එහි පිටු කිහිපයක් ඇත, 10 සීමාව සඳහා ඉල්ලීමක් ඇත. එවිට එකම දෙය, නමුත් 10,10 සීමා කරන්න. ඊළඟට තවත් පිටුවක්. ප්රශ්නය නම්, අපි මේ සියල්ල සෑම විටම ගණන් කරන්නේ ඇයි? නමුත් දැන් විසඳුමක් නැත, එය වළක්වා ගැනීමට ක්රමයක් නැත.
ClickHouse අසල පැති කාර් එකක් ලෙස තබා ඇති විකල්ප විසඳුමක් ඇත - .
කිරිල් ෂ්වාකොව්: ClickHouse Proxy සතුව බිල්ට්-ඉන් රේට් ලිමිටරයක් සහ බිල්ට් ප්‍රතිඵල හැඹිලියක් ඇත. ඔය වගේ ප්රශ්නයක් විසදෙන නිසා එතන ගොඩක් settings හැදුවා. ප්‍රොක්සි මඟින් ඉල්ලීම් පෝලිම් තැබීමෙන් සීමා කිරීමට සහ ඉල්ලීම් හැඹිලිය කොපමණ කාලයක් ජීවත් වේද යන්න වින්‍යාස කිරීමට ඉඩ සලසයි. ඉල්ලීම් සැබවින්ම සමාන නම්, ප්‍රොක්සි ඒවා බොහෝ වාරයක් යවනු ඇත, නමුත් ක්ලික්හවුස් වෙත යන්නේ එක් වරක් පමණි.
Nginx හි නිදහස් අනුවාදයේ හැඹිලියක් ද ඇත, මෙයද ක්රියා කරයි. Nginx හි සැකසුම් පවා ඇත, ඉල්ලීම් එකවර පැමිණියහොත්, එකක් සම්පූර්ණ වන තුරු එය අනෙක් අය මන්දගාමී කරයි. නමුත් ClickHouse Proxy එකේ තමයි Setup එක ගොඩක් හොඳට කරලා තියෙන්නේ. එය විශේෂයෙන් මෙම ඉල්ලීම් සඳහා ClickHouse සඳහා විශේෂයෙන් සාදන ලදී, එබැවින් එය වඩාත් සුදුසු වේ. හොඳයි, එය ස්ථාපනය කිරීම පහසුය.
අසමමුහුර්ත මෙහෙයුම් සහ ද්‍රව්‍යකරණය වූ අදහස් ගැන කුමක් කිව හැකිද?
නැවත ධාවනය කිරීමේ එන්ජිම සමඟ මෙහෙයුම් අසමමුහුර්ත බව ගැටළුවක් ඇත - පළමුව දත්ත ලියා ඇත, පසුව එය කඩා වැටේ. සමහර සමස්ථයන් සහිත ද්‍රව්‍යගත ටැබ්ලටයක් ලකුණ යටතේ ජීවත් වන්නේ නම්, අනුපිටපත් එයට ලියනු ලැබේ. තවද සංකීර්ණ තර්කනයක් නොමැති නම්, දත්ත අනුපිටපත් වනු ඇත. ඔබට ඒ ගැන කුමක් කළ හැකිද?
පැහැදිලි විසඳුමක් ඇත - අසමමුහුර්ත බිඳවැටීමේ මෙහෙයුමකදී යම් පන්තියක matviews මත ප්‍රේරකයක් ක්රියාත්මක කිරීම. සමාන ක්‍රියාකාරීත්වයක් ක්රියාත්මක කිරීමට රිදී උණ්ඩ හෝ සැලසුම් තිබේද?
ඩුප්ලිකේෂන් ක්රියා කරන ආකාරය තේරුම් ගැනීම වටී. මම දැන් ඔබට පවසන දේ ප්රශ්නයට අදාළ නොවේ, නමුත් එය මතක තබා ගැනීම වටී.
අනුකරණය කරන ලද වගුවකට ඇතුල් කරන විට, ඇතුල් කරන ලද සම්පූර්ණ කොටස්වල අඩුවීමක් ඇත. ඔබ එකම අනුපිළිවෙලෙහි එකම පේළි එකම අංකයක් අඩංගු එම බ්ලොක් එක නැවත ඇතුල් කළහොත්, දත්ත අනුපිටපත් වේ. ඇතුල් කිරීමට ප්රතිචාර වශයෙන් ඔබට "Ok" ලැබෙනු ඇත, නමුත් ඇත්ත වශයෙන්ම එක් දත්ත පැකට්ටුවක් ලියා ඇති අතර එය අනුපිටපත් නොකෙරේ.
මෙය නිශ්චිතභාවය සඳහා අවශ්ය වේ. ඇතුල් කිරීමේදී ඔබට "Ok" ලැබෙන්නේ නම්, ඔබගේ දත්ත ඇතුලත් කර ඇත. ඔබට ClickHouse වෙතින් දෝෂයක් ලැබුනේ නම්, එයින් අදහස් වන්නේ ඒවා ඇතුළත් කර නොමැති අතර ඔබ නැවත ඇතුල් කිරීම කළ යුතු බවයි. නමුත් ඇතුල් කිරීමේදී සම්බන්ධතාවය කැඩී ඇත්නම්, දත්ත ඇතුළත් කළද නැද්ද යන්න ඔබ නොදනී. එකම විකල්පය වන්නේ ඇතුල් කිරීම නැවත නැවත කිරීමයි. දත්ත ඇත්ත වශයෙන්ම ඇතුළත් කර ඔබ එය නැවත ඇතුළත් කළේ නම්, අවහිර කිරීම් අඩු කිරීමක් ඇත. අනුපිටපත් වැළැක්වීම සඳහා මෙය අවශ්ය වේ.
එමෙන්ම එය ද්‍රව්‍යකරණය වූ දසුන් සඳහා ක්රියා කරන ආකාරයද වැදගත් වේ. ප්රධාන වගුවට ඇතුළු කළ විට දත්ත අනුපිටපත් කර ඇත්නම්, එය ද්‍රව්‍යකරණය වූ දසුනට ද නොයනු ඇත.
දැන් ප්රශ්නය ගැන. ඔබ තනි රේඛාවල අනුපිටපත් පටිගත කරන නිසා ඔබේ තත්වය වඩාත් සංකීර්ණ වේ. එනම්, එය අනුපිටපත් කර ඇති සම්පූර්ණ ඇසුරුම නොවේ, නමුත් නිශ්චිත රේඛා, සහ ඔවුන් පසුබිම තුළ කඩා වැටේ. ඇත්ත වශයෙන්ම, දත්ත ප්රධාන වගුවේ බිඳ වැටෙනු ඇත, නමුත් නොකැඩූ දත්ත ද්‍රව්‍යකරණය වූ දසුනට යන අතර, ඒකාබද්ධ කිරීමේදී ද්‍රව්‍යකරණය වූ දසුන්වලට කිසිවක් සිදු නොවේ. මක්නිසාද යත් ද්‍රව්‍යමය දර්ශනයක් ඇතුළු කිරීමේ ප්‍රේරකයකට වඩා වැඩි දෙයක් නොවන බැවිනි. වෙනත් මෙහෙයුම් වලදී, එයට අමතර කිසිවක් සිදු නොවේ.
අනික මට ඔයාව මෙතන සතුටින් තියන්න බෑ. ඔබ මෙම නඩුව සඳහා නිශ්චිත විසඳුමක් සෙවිය යුතුය. උදාහරණයක් ලෙස, එය ද්‍රව්‍යමය දසුනකින් නැවත ධාවනය කළ හැකිද, සහ අඩුකිරීමේ ක්රමය එකම ආකාරයකින් ක්රියා කළ හැකිය. නමුත් අවාසනාවකට, සෑම විටම නොවේ. එකතු කරනවා නම් හරියන්නේ නැහැ.
කිරිල් ෂ්වාකොව්: එදා අපි කිහිලිකරු ඉදිකිරීමත් කළා. වෙළඳ ප්‍රචාරණ හැඟීම් තිබීමේ ගැටලුවක් ඇති අතර, අපට තථ්‍ය කාලය තුළ පෙන්විය හැකි සමහර දත්ත තිබේ - මේවා හුදෙක් හැඟීම් පමණි. ඒවා කලාතුරකින් අනුපිටපත් වේ, නමුත් මෙය සිදු වුවහොත්, අපි කෙසේ හෝ පසුව ඒවා බිඳ දමමු. සහ අනුපිටපත් කළ නොහැකි දේවල් තිබුණා - ක්ලික් කිරීම් සහ මේ සම්පූර්ණ කතාව. ඒත් මටත් ඕන වුණා ඒවා වහාම වාගේ පෙන්වන්න.
ද්‍රව්‍යමය වූ අදහස් ඇති කළේ කෙසේද? එය කෙලින්ම ලියා ඇති දර්ශන තිබුණි - එය අමු දත්ත වලට ලියා ඇත, සහ බැලීම් වලට ලියා ඇත. එහිදී, යම් අවස්ථාවක දී දත්ත ඉතා නිවැරදි නොවේ, එය අනුපිටපත්, සහ යනාදි. මේසයේ දෙවන කොටස ඇත, එහිදී ඒවා ද්‍රව්‍යමය අදහස්වලට සමාන වේ, එනම් ඒවා ව්‍යුහයෙන් සම්පූර්ණයෙන්ම සමාන වේ. වරකට අපි දත්ත නැවත ගණනය කරන්නෙමු, අනුපිටපත් නොමැතිව දත්ත ගණන් කරන්නෙමු, එම වගු වලට ලියන්න.
අපි API හරහා ගියා - මෙය ClickHouse හි අතින් ක්රියා නොකරනු ඇත. සහ API පෙනෙන්නේ: මම මේසයට අවසාන එකතු කිරීමේ දිනය ඇති විට, නිවැරදි දත්ත දැනටමත් ගණනය කර ඇති බවට සහතික වන අතර, එය එක් වගුවකට සහ තවත් වගුවකට ඉල්ලීමක් කරයි. එකකින් ඉල්ලීම නිශ්චිත කාලයක් දක්වා තෝරා ගන්නා අතර අනෙකෙන් එය තවමත් ගණනය කර නොමැති දේ ලබා ගනී. එය ක්රියා කරයි, නමුත් ClickHouse හරහා පමණක් නොවේ.
ඔබට යම් ආකාරයක API තිබේ නම් - විශ්ලේෂකයින් සඳහා, පරිශීලකයින් සඳහා - එවිට, ප්රතිපත්තිමය වශයෙන්, මෙය විකල්පයකි. ඔබ සැමවිටම ගණන් කරයි, සෑම විටම ගණන් කරයි. මෙය දිනකට වරක් හෝ වෙනත් වේලාවක සිදු කළ හැකිය. ඔබට අවශ්ය නොවන සහ විවේචනාත්මක නොවන පරාසයක් ඔබම තෝරාගන්න.
ClickHouse එකේ logs ගොඩක් තියෙනවා. සර්වර් එකට වෙන හැම දෙයක්ම එක බැල්මකින් දකින්නේ කොහොමද?
ClickHouse හි විවිධ ලඝු-සටහන් ඉතා විශාල සංඛ්යාවක් ඇති අතර, මෙම සංඛ්යාව වැඩි වෙමින් පවතී. නව අනුවාද වලදී, ඒවායින් සමහරක් පෙරනිමියෙන් පවා සක්‍රීය කර ඇත; පැරණි අනුවාද වල ඒවා යාවත්කාලීන කිරීමේදී සක්‍රීය කළ යුතුය. කෙසේ වෙතත්, ඒවායින් වැඩි වැඩියෙන් තිබේ. අවසාන වශයෙන්, මම දැන් මගේ සේවාදායකය සමඟ සිදුවන්නේ කුමක්දැයි බැලීමට කැමතියි, සමහර විට යම් ආකාරයක සාරාංශ උපකරණ පුවරුවක.
ඔබ සතුව ClickHouse කණ්ඩායමක් හෝ ඔබේ මිතුරන්ගේ කණ්ඩායම් තිබේද, එය නිමි භාණ්ඩයක් ලෙස මෙම ලඝු-සටහන් ප්‍රදර්ශනය කරන සූදානම් කළ උපකරණ පුවරු වල යම් ක්‍රියාකාරීත්වයකට සහාය දක්වයිද? අවසාන වශයෙන්, ClickHouse හි ලොග් දෙස බැලීම විශිෂ්ටයි. නමුත් එය දැනටමත් උපකරණ පුවරුවක ආකාරයෙන් සකස් කර ඇත්නම් එය ඉතා සිසිල් වනු ඇත. මට එයින් පයින් පහරක් ලැබෙනු ඇත.
ප්‍රමිතිගත නොවූවත් උපකරණ පුවරු තිබේ. අපගේ සමාගම තුළ, කණ්ඩායම් 60 ක් පමණ ක්ලික්හවුස් භාවිතා කරන අතර, අමුතුම දෙය නම්, ඔවුන්ගෙන් බොහෝ දෙනෙකුට ඔවුන් විසින්ම සාදන ලද උපකරණ පුවරු සහ තරමක් වෙනස් ඒවා තිබීමයි. සමහර කණ්ඩායම් අභ්යන්තර Yandex.Cloud ස්ථාපනය භාවිතා කරයි. අවශ්ය සියල්ල නොවුනත්, සූදානම් කළ වාර්තා කිහිපයක් තිබේ. අනෙක් අයට ඔවුන්ගේම ඇත.
Metrica හි මගේ සගයන්ට Grafana හි ඔවුන්ගේම උපකරණ පුවරුවක් ඇති අතර, ඔවුන්ගේ පොකුර සඳහා මට මගේම ඇත. මම බලන්නේ serif cache එකට cache hit වගේ දේවල්. ඊටත් වඩා දුෂ්කර වන්නේ අපි විවිධ මෙවලම් භාවිතා කිරීමයි. මම මගේ උපකරණ පුවරුව නිර්මාණය කළේ Graphite-web නම් ඉතා පැරණි මෙවලමක් භාවිතා කරමිනි. ඔහු සම්පූර්ණයෙන්ම කැතයි. ග්‍රැෆානා වඩාත් පහසු සහ ලස්සන විය හැකි වුවද මම තවමත් එය මේ ආකාරයෙන් භාවිතා කරමි.
ඩෑෂ්බෝඩ් වල මූලික දේත් එහෙමයි. මේවා පොකුර සඳහා පද්ධති මිනුම් වේ: CPU, මතකය, තැටිය, ජාලය. වෙනත් - සමකාලීන ඉල්ලීම් ගණන, එකවර ඒකාබද්ධ කිරීම් ගණන, තත්පරයකට ඉල්ලීම් ගණන, MergeTree වගු කොටස් සඳහා උපරිම කුට්ටි ගණන, අනුකරණ ප්‍රමාදය, අනුකරණ පෝලිම් ප්රමාණය, තත්පරයට ඇතුළු කළ පේළි ගණන, තත්පරයට ඇතුළු කළ කුට්ටි ගණන. මේ සියල්ල ලබා ගන්නේ ලඝු-සටහන් වලින් නොව ප්‍රමිතික වලින්.
ව්ලැඩිමීර් කොලොබෙව්: ඇලෙක්සි, මම එය ටිකක් නිවැරදි කිරීමට කැමතියි. Grafana තියෙනවා. Grafana සතුව දත්ත මූලාශ්‍රයක් ඇත, එය ClickHouse වේ. එනම්, මට Grafana වෙතින් කෙලින්ම ClickHouse වෙත ඉල්ලීම් කළ හැකිය. ClickHouse හි ලඝු-සටහන් සහිත වගුවක් ඇත, එය සෑම කෙනෙකුටම සමාන වේ. එහි ප්‍රතිඵලයක් වශයෙන්, මට ග්‍රැෆානා හි මෙම ලොග් වගුව වෙත ප්‍රවේශ වී මගේ සේවාදායකය විසින් කරන ලද ඉල්ලීම් බැලීමට අවශ්‍යයි. මේ වගේ ඩෑෂ් බෝඩ් එකක් තිබ්බොත් ගොඩක් හොඳයි.
මමම බයිසිකල් පැදෙව්වා. නමුත් මට ප්රශ්නයක් තිබේ - ඒ සියල්ල ප්‍රමිතිගත නම් සහ ග්‍රැෆානා සෑම කෙනෙකුම භාවිතා කරන්නේ නම්, Yandex හි එවැනි නිල උපකරණ පුවරුවක් නැත්තේ ඇයි?
කිරිල් ෂ්වාකොව්: ඇත්ත වශයෙන්ම, ClickHouse වෙත යන දත්ත මූලාශ්රය දැන් Altinity සඳහා සහය දක්වයි. ඒවගේම මට අවශ්ය වන්නේ හාරන්නේ කොතැනද සහ කවුරුන් තල්ලු කළ යුතුද යන්න පිළිබඳ දෛශිකයක් ලබා දීමට පමණි. Yandex තවමත් ClickHouse සාදන නිසා ඔබට ඔවුන්ගෙන් ඇසිය හැකිය, එය වටා ඇති කතාව නොවේ. Altinity යනු දැනට ClickHouse ප්‍රවර්ධනය කරන ප්රධාන සමාගමයි. ඔවුන් ඔහුව අත් නොහරිනු ඇත, නමුත් ඔහුට සහාය වනු ඇත. මන්ද, ප්රතිපත්තිමය වශයෙන්, ග්‍රැෆානා වෙබ් අඩවියට උපකරණ පුවරුවක් උඩුගත කිරීම සඳහා, ඔබට අවශ්ය වන්නේ ලියාපදිංචි වී එය උඩුගත කිරීම පමණි - විශේෂ ගැටළු නොමැත.
ඇලෙක්සි මිලොවිඩොව්: පසුගිය වසර පුරා, ClickHouse බොහෝ විමසුම් පැතිකඩ කිරීමේ හැකියාවන් එක් කර ඇත. සම්පත් භාවිතය පිළිබඳ එක් එක් ඉල්ලීම සඳහා ප්‍රමිතික ඇත. සහ මෑතකදී, අපි සෑම මිලි තත්පරයක්ම විමසුමක් වැය කරන්නේ කොතැනදැයි බැලීමට ඊටත් වඩා පහළ මට්ටමේ විමසුම් පැතිකඩක් එක් කළෙමු. නමුත් මෙම ක්‍රියාකාරීත්වය භාවිතා කිරීමට, මට කොන්සෝල සේවාදායකයා විවෘත කර ඉල්ලීමක් ටයිප් කළ යුතුය, එය මට සැමවිටම අමතක වේ. මම එය කොහේ හරි සුරැකූ අතර හරියටම කොතැනදැයි අමතක කරමි.
විමසුම් පන්තිය අනුව කාණ්ඩ කර ඇති ඔබේ බර විමසුම් මෙන්න, යැයි කියන මෙවලමක් තිබුණා නම් මම කැමතියි. මම එකක් තද කළා, ඔවුන් මට කියනවා ඒකයි බරයි කියලා. දැන් එහෙම විසඳුමක් නැහැ. “මට කියන්න, ග්‍රැෆානා සඳහා සූදානම් කළ උපකරණ පුවරු තිබේද?” කියා මිනිසුන් මගෙන් ඇසූ විට, මම මෙසේ කියමි: “ග්‍රැෆානා වෙබ් අඩවියට යන්න, “ඩෑෂ්බෝඩ්” ප්‍රජාවක් ඇත, උපකරණ පුවරුවක් තිබේ. ඩිම්කා වෙතින්, කොස්ටියන් වෙතින් උපකරණ පුවරුවක් ඇත. එය කුමක්දැයි මම නොදනිමි, මම එය මා විසින්ම භාවිතා කර නැත.
සේවාදායකය OOM වෙත කඩා නොවැටෙන පරිදි ඒකාබද්ධ කිරීම් වලට බලපෑම් කරන්නේ කෙසේද?
මට table එකක් තියෙනවා, table එකේ තියෙන්නේ එක partition එකක්, ඒක ReplacingMergeTree. මම අවුරුදු හතරක් තිස්සේ එහි දත්ත ලියමින් සිටිමි. මට ඒකේ වෙනසක් කරලා දත්ත ටිකක් මකන්න ඕන වුණා.
මම මෙය කළ අතර, මෙම ඉල්ලීම සැකසීමේදී, පොකුරේ ඇති සියලුම සේවාදායකයන්හි සියලුම මතකය පරිභෝජනය කරන ලද අතර, පොකුරේ ඇති සියලුම සේවාදායකයන් OOM වෙත ගියේය. ඉන්පසු ඔවුන් සියල්ලෝම එකට නැඟිට, මෙම මෙහෙයුමම, මෙම දත්ත අවහිර කිරීම ඒකාබද්ධ කිරීමට පටන් ගත් අතර, නැවතත් OOM වෙත වැටුණි. එවිට ඔවුන් නැවත නැඟිට නැවතත් වැටුණා. ඒ වගේම මේ වැඩේ නතර වුණේ නැහැ.
එවිට පෙනී ගියේ මෙය ඇත්ත වශයෙන්ම යාලුවනේ නිවැරදි කළ දෝෂයක් බවයි. මේක හරිම අපූරුයි, බොහොම ස්තුතියි. නමුත් ශේෂයක් ඉතිරි විය. දැන්, මම මේසයේ යම් ආකාරයක ඒකාබද්ධ කිරීමක් ගැන සිතන විට, මට ප්රශ්නයක් ඇත - මට කෙසේ හෝ මෙම ඒකාබද්ධ කිරීම්වලට බලපෑම් කළ නොහැක්කේ ඇයි? උදාහරණයක් ලෙස, අවශ්ය RAM ප්රමාණයෙන් හෝ, ප්රතිපත්තිමය වශයෙන්, මෙම විශේෂිත වගුව සකසන ප්රමාණයෙන් ඒවා සීමා කරන්න.
මා සතුව "මිතික" නම් වගුවක් ඇත, කරුණාකර එය මා වෙනුවෙන් නූල් දෙකකින් සකසන්න. සමාන්තරව ඒකාබද්ධ කිරීම් දහයක් හෝ පහක් නිර්මාණය කිරීමට අවශ්ය නැත, එය දෙකකින් කරන්න. මම හිතන්නේ මට දෙදෙනෙකුට ප්රමාණවත් මතකයක් ඇති නමුත් එය දහයක් සැකසීමට ප්රමාණවත් නොවනු ඇත. බිය ඉතිරි වන්නේ ඇයි? මේසය වර්ධනය වෙමින් පවතින නිසාත්, යම් දිනක මට ප්රතිපත්තිමය වශයෙන්, තවදුරටත් දෝෂයක් නිසා ඇති වන තත්වයකට මුහුණ දීමට සිදුවනු ඇති නිසාත්, දත්ත එතරම් විශාල ප්‍රමාණයකින් වෙනස් වන නිසා මට ප්රමාණවත් මතකයක් නොමැති බැවිනි. සේවාදායකය. ඉන්පසු ඒකාබද්ධ කිරීමේදී සේවාදායකය OOM වෙත කඩා වැටෙනු ඇත. එපමණක් නොව, මට විකෘතිය අවලංගු කළ හැක, නමුත් Merji තවදුරටත් එහි නොමැත.
ඔබ දන්නවා, ඒකාබද්ධ කිරීමේදී, සේවාදායකය OOM වලට වැටෙන්නේ නැත, මන්ද ඒකාබද්ධ කිරීමේදී RAM ප්රමාණය භාවිතා වන්නේ එක් කුඩා දත්ත පරාසයකට පමණි. එබැවින් දත්ත ප්රමාණය නොසලකා සෑම දෙයක්ම හොඳින් සිදුවනු ඇත.
ව්ලැඩිමීර් කොලොබෙව්: හොඳයි. මෙන්න මොහොත කොතරම්ද යත්, දෝෂය නිවැරදි කිරීමෙන් පසු, මම මා වෙනුවෙන් නව අනුවාදයක් බාගත කළ අතර, තවත් මේසයක් මත, බොහෝ කොටස් ඇති කුඩා එකක්, මම සමාන මෙහෙයුමක් සිදු කළෙමි. ඒකාබද්ධ කිරීමේදී, සේවාදායකයේ 100 GB පමණ RAM ප්‍රමාණයක් දැවී ගියේය. මට 150 ක් වාඩිලාගෙන, 100 ක් කෑවා, සහ 50 GB කවුළුවක් ඉතිරිව තිබුණා, ඒ නිසා මම OOM එකට වැටුණේ නැහැ.
එය ඇත්ත වශයෙන්ම 100 GB RAM පරිභෝජනය කරන්නේ නම් OOM වෙත වැටීමෙන් දැනට මා ආරක්ෂා කරන්නේ කුමක් ද? ඒකාබද්ධයේ ඇති RAM එක හදිසියේම අවසන් වුවහොත් කුමක් කළ යුතුද?
ඇලෙක්සි මිලොවිඩොව්: ඒකාබද්ධ කිරීම සඳහා විෙශේෂෙයන් RAM පරිභෝජනය සීමා ෙනොවන එවැනි ගැටළුවක් පවතී. දෙවන ගැටළුව නම්, යම් ආකාරයක ඒකාබද්ධ කිරීමක් පවරා ඇත්නම්, එය අනුවර්තන ලොගයේ සටහන් කර ඇති බැවින් එය ක්රියාත්මක කළ යුතුය. අනුරූ ලඝු-සටහන යනු අනුරුව ස්ථාවර තත්ත්වයකට ගෙන ඒමට අවශ්ය ක්රියා වේ. ඔබ මෙම අනුකරණ ලොගය ආපසු හරවන අතින් හැසිරවීම් සිදු නොකරන්නේ නම්, ඒකාබද්ධ කිරීම එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් සිදු කිරීමට සිදුවනු ඇත.
ඇත්ත වශයෙන්ම, OOM ට එරෙහිව "හරියටම" ආරක්ෂා කරන RAM සීමාවක් තිබීම අතිරික්ත නොවේ. එය ඒකාබද්ධ කිරීම සම්පූර්ණ කිරීමට උදව් නොකරනු ඇත, එය නැවත ආරම්භ වනු ඇත, යම් සීමාවකට ළඟා වනු ඇත, ව්යතිරේකයක් විසි කරන්න, ඉන්පසු නැවත ආරම්භ කරන්න - මෙයින් හොඳ කිසිවක් නොලැබේ. නමුත් ප්රතිපත්තිමය වශයෙන්, මෙම සීමාව හඳුන්වා දීම ප්රයෝජනවත් වනු ඇත.
ClickHouse සඳහා Golang ධාවකය සංවර්ධනය කරන්නේ කෙසේද?
Kirill Shvakov විසින් ලියන ලද Golang ධාවකය, දැන් ClickHouse කණ්ඩායම විසින් නිල වශයෙන් සහාය දක්වයි. ඔහු , ඔහු දැන් විශාල හා සැබෑ ය.
කුඩා සටහනක්. සාමාන්ය ආකාරයේ අසීමිත අනුපිළිවෙලෙහි පුදුම සහ ආදරණීය ගබඩාවක් ඇත - මෙය Vertica වේ. ඔවුන්ට ඔවුන්ගේම නිල පයිතන් ධාවකයක් ද ඇත, එයට Vertica සංවර්ධකයින් සහාය දක්වයි. කිහිප වතාවක්ම ගබඩා අනුවාද සහ ධාවක අනුවාද තරමක් නාටකාකාර ලෙස අපසරනය වූ අතර රියදුරු යම් අවස්ථාවක දී ක්රියා කිරීම නැවැත්වීය. සහ දෙවන කරුණ. මෙම නිල රියදුරු සඳහා සහාය, මට පෙනෙන පරිදි, "තන පුඩුව" පද්ධතිය මගින් සිදු කරනු ලැබේ - ඔබ ඔවුන්ට ගැටලුවක් ලියන අතර එය සදහටම එල්ලී ඇත.
මට ප්‍රශ්න දෙකක් තියෙනවා. දැන් Kirill's Golang ධාවකය Golang සිට ClickHouse සමඟ සන්නිවේදනය කිරීමේ පෙරනිමි මාර්ගයයි. යමෙකු තවමත් http අතුරු මුහුණත හරහා සන්නිවේදනය කරන්නේ නම් මිස ඔහු එයට කැමති නිසා. මෙම ධාවකයේ සංවර්ධනය ඉදිරියට යන්නේ කෙසේද? එය නිධිය තුළම කිසියම් බිඳෙන වෙනස්කම් සමඟ සමමුහුර්ත වේද? සහ ගැටලුවක් සලකා බැලීමේ ක්රියා පටිපාටිය කුමක්ද?
කිරිල් ෂ්වාකොව්: පළමුවැන්න නිලධාරිවාදීව සියල්ල සංවිධානය වන්නේ කෙසේද යන්නයි. මෙම කරුණ සාකච්ඡා නොකළ බැවින් මට පිළිතුරු දීමට කිසිවක් නැත.
ගැටළුව පිළිබඳ ප්රශ්නයට පිළිතුරු දීමට, අපට රියදුරුගේ කුඩා ඉතිහාසයක් අවශ්ය වේ. මම වැඩ කළේ දත්ත ගොඩක් තිබුණු සමාගමක. එය කොතැනක හෝ ගබඩා කළ යුතු සිදුවීම් විශාල සංඛ්යාවක් සහිත වෙළඳ දැන්වීම් දඟ පන්දු යවන්නකි. සහ යම් අවස්ථාවක ClickHouse දර්ශනය විය. අපි එය දත්ත වලින් පුරවා, මුලදී සියල්ල හොඳයි, නමුත් පසුව ClickHouse බිඳ වැටුණා. ඒ වෙලාවේ අපි තීරණය කළා අපිට ඒක අවශ්ය නැහැ කියලා.
වසරකට පසුව, අපි ClickHouse භාවිතා කිරීමේ අදහස වෙත ආපසු ගිය අතර, අපට කෙසේ හෝ එහි දත්ත ලිවීමට අවශ්ය විය. හඳුන්වාදීමේ පණිවිඩය මෙයයි: දෘඩාංග ඉතා දුර්වලයි, සම්පත් ස්වල්පයක් ඇත. නමුත් අපි සෑම විටම මේ ආකාරයෙන් වැඩ කර ඇති අතර, එබැවින් අපි ස්වදේශීය ප්රොටෝකෝලය දෙස බැලුවෙමු.
අපි Go වල වැඩ කරපු නිසා Go Driver කෙනෙක් අවශ්ය බව පැහැදිලියි. මම එය සම්පූර්ණයෙන්ම පාහේ කළා - එය මගේ වැඩ කාර්යයයි. අපි එය යම් නිශ්චිත ස්ථානයකට ගෙන ආ අතර, ප්රතිපත්තිමය වශයෙන් අප හැර වෙනත් කිසිවෙකු එය භාවිතා කරනු ඇතැයි කිසිවෙකු උපකල්පනය කළේ නැත. ඊට පස්සේ CloudFlare ආවේ හරියටම එකම ප්‍රශ්නෙකින්, ඒ වගේම කාලයක් අපි ඔවුන් සමඟ ඉතා සුමටව වැඩ කළා, ඔවුන්ට එකම කාර්යයන් තිබූ නිසා. එපමණක් නොව, අපි මෙය ClickHouse හි සහ රියදුරු තුළත් කළෙමු.
ක්ලික් හවුස් සහ වැඩ සම්බන්ධයෙන් මගේ ක්‍රියාකාරකම් ටිකක් වෙනස් වූ නිසා යම් අවස්ථාවක දී, මම එය කිරීම නැවැත්තුවා. ඒ නිසා ප්‍රශ්න වහලා නැහැ. කාලානුරූපව, තමන්ටම යමක් අවශ්ය අය ගබඩාවට කැප වෙති. ඊට පස්සේ පුල් රික්වෙස්ට් එක බලලා සමහර වෙලාවට මමම මොනවා හරි එඩිට් කරත් එහෙම වෙන්නේ කලාතුරකින්.
මට රියදුරු වෙත ආපසු යාමට අවශ්‍යයි. මීට වසර කිහිපයකට පෙර, මේ සියල්ල ආරම්භ වූ විට, ClickHouse ද වෙනස් සහ විවිධ හැකියාවන්ගෙන් යුක්ත විය. දැන් අපිට ඩ්‍රයිවර් එක හොදට වැඩ කරන විදියට රීමේක් කරන හැටි ගැන අවබෝධයක් තියෙනවා. මෙය සිදුවුවහොත්, සමුච්චිත කිහිලිකරු හේතුවෙන් 2 අනුවාදය ඕනෑම අවස්ථාවක නොගැලපේ.
මෙම කාරණය සංවිධානය කරන්නේ කෙසේදැයි මම නොදනිමි. මටම වැඩි කාලයක් නැහැ. සමහර අය ඩ්‍රයිවර් එක ඉවර කරොත් මට උදව් කරලා කරන්න ඕන දේ කියන්න පුළුවන්. නමුත් ව්යාපෘතියේ සංවර්ධනය සඳහා Yandex හි ක්රියාකාරී සහභාගීත්වය තවමත් සාකච්ඡා කර නොමැත.
ඇලෙක්සි මිලොවිඩොව්: ඇත්තටම මේ රියදුරන් ගැන තවම නිලධාරි තන්ත්‍රයක් නැහැ. එකම දෙය නම් ඒවා නිල සංවිධානයකට ඉදිරිපත් කිරීමයි, එනම් මෙම ධාවකය Go සඳහා නිල පෙරනිමි විසඳුම ලෙස හඳුනාගෙන ඇත. තව ඩ්‍රයිවර්ස්ලා ඉන්නවා, හැබැයි එන්නේ වෙනම.
මෙම රියදුරන් සඳහා අපට අභ්යන්තර සංවර්ධනයක් නොමැත. ප්රශ්නය වන්නේ මෙම විශේෂිත රියදුරෙකු සඳහා නොව, සියලුම ප්‍රජා රියදුරන්ගේ දියුණුව සඳහා අපට තනි පුද්ගලයෙකු බඳවා ගත හැකිද, නැතහොත් අපට පිටතින් කෙනෙකු සොයා ගත හැකිද යන්නයි.
lazy_load සැකසුම සබල කර නැවත පණගැන්වීමෙන් පසු බාහිර ශබ්ද කෝෂය පූරණය නොවේ. කුමක් කරන්න ද?
අප සතුව lazy_load සැකසුම සක්‍රීය කර ඇති අතර, සේවාදායකය නැවත පණගැන්වීමෙන් පසුව, ශබ්දකෝෂය තනිවම පූරණය නොවේ. පරිශීලකයා මෙම ශබ්දකෝෂයට පිවිසීමෙන් පසුව පමණක් එය මතු කරයි. ඒවගේම මම ඒකට ප්‍රථම වරට ප්‍රවේශ වූ විට එය දෝෂයක් ලබා දෙයි. ClickHouse භාවිතයෙන් ශබ්ද කෝෂ ස්වයංක්රීයව පූරණය කළ හැකිද, නැතහොත් පරිශීලකයින්ට දෝෂ නොලැබෙන පරිදි ඔවුන්ගේ සූදානම ඔබම පාලනය කිරීමට අවශ්‍යද?
සමහර විට අපට ClickHouse හි පැරණි අනුවාදයක් තිබේ, එබැවින් ශබ්දකෝෂය ස්වයංක්රීයව පූරණය නොවීය. මෙය එසේ විය හැකිද?
පළමුව, විමසුමක් භාවිතයෙන් ශබ්දකෝෂ බලහත්කාරයෙන් පූරණය කළ හැක පද්ධති රීලෝඩ් ශබ්දකෝෂ. දෙවනුව, දෝෂය සම්බන්ධයෙන් - ශබ්ද කෝෂය දැනටමත් පටවා තිබේ නම්, විමසුම් පටවා ඇති දත්ත මත පදනම්ව ක්රියා කරයි. ශබ්ද කෝෂය තවමත් පූරණය කර නොමැති නම්, ඉල්ලීම අතරතුර එය කෙලින්ම පූරණය වේ.
බර ශබ්දකෝෂ සඳහා මෙය ඉතා පහසු නොවේ. උදාහරණයක් ලෙස, ඔබට MySQL වෙතින් පේළි මිලියනයක් ඇද ගත යුතුය. යමෙක් සරල තේරීමක් කරයි, නමුත් මෙම තේරීම එකම පේළි මිලියනයක් සඳහා රැඳී සිටිනු ඇත. මෙහි විසඳුම් දෙකක් තිබේ. පළමුවැන්න නම් lazy_load ක්රියා විරහිත කිරීමයි. දෙවනුව, සේවාදායකය ක්රියාත්මක වන විට, එය මත පැටවීමට පෙර, කරන්න පද්ධතිය රීලෝඩ් ශබ්ද කෝෂය නැත්නම් ශබ්දකෝෂයක් භාවිතා කරන විමසුමක් කරන්න. එවිට ශබ්දකෝෂය පූරණය වේ. ClickHouse ස්වයංක්රීයව ඒවා පූරණය නොකරන නිසා, lazy_load සැකසීම සක්‍රීය කර ඇති ශබ්දකෝෂ තිබීම පාලනය කිරීමට ඔබට අවශ්ය වේ.
අවසාන ප්රශ්නයට පිළිතුර එක්කෝ අනුවාදය පැරණි හෝ එය නිදොස් කළ යුතුය.
අවම වශයෙන් එක් ශබ්දකෝෂයක් දෝෂයකින් බිඳ වැටුණහොත් පද්ධති රීලෝඩ් ශබ්දකෝෂ බොහෝ ශබ්ද කෝෂවලින් කිසිවක් පූරණය නොකරන බව සමඟ කුමක් කළ යුතුද?
පද්ධති රීලෝඩ් ශබ්දකෝෂ පිළිබඳ තවත් ප්රශ්නයක් තිබේ. අපට ශබ්දකෝෂ දෙකක් තිබේ - එකක් පටවා නැත, දෙවැන්න පටවා ඇත. මෙම අවස්ථාවෙහිදී, පද්ධති රීලෝඩ් ශබ්දකෝෂ කිසිදු ශබ්දකෝෂයක් පූරණය නොකරන අතර, ඔබට පද්ධති රීලෝඩ් ශබ්දකෝෂය භාවිතයෙන් නිශ්චිත එකක් එහි නමෙන් ලක්ෂ්‍යයෙන් පූරණය කළ යුතුය. මේකත් ClickHouse අනුවාදයට සම්බන්ධද?
මට ඔයාව සතුටු කරන්න ඕන. මෙම හැසිරීම වෙනස් විය. ඒ කියන්නේ ClickHouse එක update කලොත් ඒකත් වෙනස් වෙනවා. ඔබගේ වර්තමාන හැසිරීම ගැන ඔබ සතුටු නොවන්නේ නම් පද්ධති රීලෝඩ් ශබ්දකෝෂ, යාවත්කාලීන කරන්න, සහ එය වඩා හොඳ සඳහා වෙනස් වේ යැයි අපි බලාපොරොත්තු වෙමු.
ක්ලික්හවුස් වින්‍යාසය තුළ විස්තර වින්‍යාස කිරීමට ක්රමයක් තිබේද, නමුත් දෝෂ ඇති විට ඒවා ප්‍රදර්ශනය නොකරන්නද?
මීළඟ ප්රශ්නය ශබ්දකෝෂයට අදාළ දෝෂ, එනම් විස්තර ගැන ය. අපි ශබ්දකෝෂය සඳහා ClickHouse වින්‍යාසය තුළ සම්බන්ධතා විස්තර සඳහන් කර ඇති අතර, දෝෂයක් ඇත්නම්, ප්රතිචාර වශයෙන් අපට මෙම විස්තර සහ මුරපදය ලැබේ.
අපි ODBC ධාවක වින්‍යාසයට විස්තර එකතු කිරීමෙන් මෙම දෝෂය විසඳා ගත්තෙමු. ක්ලික්හවුස් වින්‍යාසය තුළ විස්තර වින්‍යාස කිරීමට ක්රමයක් තිබේද, නමුත් දෝෂ ඇති විට මෙම විස්තර නොපෙන්වයිද?
මෙහි සැබෑ විසඳුම වන්නේ odbc.ini හි මෙම අක්තපත්‍ර සඳහන් කිරීම සහ ClickHouse තුළම ODBC දත්ත මූලාශ්‍ර නාමය පමණක් සඳහන් කිරීමයි. වෙනත් ශබ්ද කෝෂ මූලාශ්‍ර සඳහා මෙය සිදු නොවනු ඇත - MySQL සමඟ ශබ්දකෝෂය සඳහා හෝ අනෙක් ඒවා සඳහා, ඔබට දෝෂ පණිවිඩයක් ලැබුණු විට මුරපදය නොපෙනේ. ODBC සඳහා, මමත් බලන්නම් - එය තිබේ නම්, ඔබට එය ඉවත් කිරීමට අවශ්ය වේ.
ප්‍රසාද දීමනාව: රැස්වීම් වලින් විශාලනය සඳහා පසුබිම්
පින්තූරය මත ක්ලික් කිරීමෙන්, වඩාත් ස්ථීර පාඨකයන් සඳහා රැස්වීම්වලින් ලැබෙන ප්‍රසාද පසුබිම් විවෘත වේ. අපි Avito තාක්‍ෂණ මැස්කොට් සමඟ එක්ව ගින්න නිවා දමමු, අපි පද්ධති පරිපාලකගේ කාමරයේ හෝ පැරණි පාසල් පරිගණක සමාජයේ සගයන් සමඟ සාකච්ඡා කරමු, අපි ග්‍රැෆිටි පසුබිමට එරෙහිව පාලම යට දිනපතා රැස්වීම් පවත්වමු.
මූලාශ්රය: www.habr.com