HighLoad++ මොස්කව් 2018, කොන්ග්‍රස් ශාලාව. නොවැම්බර් 9, 15:00
සාරාංශ සහ ඉදිරිපත් කිරීම:
Yuri Nasretdinov (VKontakte): අපගේ සමාගම තුළ ClickHouse ක්රියාත්මක කිරීමේ අත්දැකීම් ගැන වාර්තාව කතා කරනු ඇත - අපට එය අවශ්ය වන්නේ ඇයි, අපි කොපමණ දත්ත ගබඩා කරන්නේ, අපි එය ලියන ආකාරය සහ යනාදියයි.
අතිරේක ද්රව්ය:
යූරි නස්රෙට්ඩිනොව්: - ආයුබෝවන් සියල්ලටම! මම දැනටමත් හඳුන්වා දී ඇති පරිදි මගේ නම යූරි නස්රෙට්ඩිනොව්. මම VKontakte හි වැඩ කරමි. අපගේ සේවාදායක බලඇණියෙන් (දස දහස් ගණනින්) අපි ClickHouse වෙත දත්ත ඇතුළත් කරන ආකාරය ගැන මම කතා කරමි.
ලඝු-සටහන් මොනවාද සහ ඒවා එකතු කරන්නේ ඇයි?
අපි ඔබට පවසන දේ: අපි කළ දේ, අපට “ClickHouse” අවශ්ය වූයේ ඇයි, අපි එය තෝරා ගත්තේ ඇයි, විශේෂයෙන් කිසිවක් වින්‍යාස නොකර ඔබට ආසන්න වශයෙන් ලබා ගත හැකි කාර්ය සාධනය. මම ඔබට තවදුරටත් බෆර් වගු ගැන, ඒවා සමඟ ඇති වූ ගැටළු සහ විවෘත මූලාශ්‍රයෙන් අප විසින් සකස් කරන ලද අපගේ විසඳුම් ගැන කියන්නම් - KittenHouse සහ Lighthouse.
අපට කිසිවක් කිරීමට අවශ්ය වූයේ ඇයි (VKontakte හි සෑම දෙයක්ම හොඳයි, හරිද?). අපට දෝශ නිරාකරණ ලඝු එකතු කිරීමට අවශ්ය විය (සහ එහි ටෙරාබයිට් සිය ගණනක් දත්ත තිබුණි), සමහර විට කෙසේ හෝ සංඛ්‍යාලේඛන ගණනය කිරීම වඩාත් පහසු වනු ඇත; සහ අපට මේ සියල්ල කළ යුතු සර්වර් දස දහස් ගණනක ඇණියක් ඇත.
අපි තීරණය කළේ ඇයි? ලඝු-සටහන් ගබඩා කිරීම සඳහා අපට විසඳුම් තිබුණා. මෙන්න - එවැනි පොදු "Backend VK" ඇත. එයට දායක වීමට මම තරයේ නිර්දේශ කරමි.
ලඝු-සටහන් මොනවාද? මෙය හිස් අරා ආපසු ලබා දෙන එන්ජිමකි. VK හි එන්ජින් අන් අය මයික්‍රො සර්විස් ලෙස හඳුන්වනු ලැබේ. මෙන්න සිනාමුසු ස්ටිකරයක් (සෑහෙන තරම් කැමති). එහෙම කොහොම ද? හොඳයි, තවදුරටත් සවන් දෙන්න!
ලොග් ගබඩා කිරීමට භාවිතා කළ හැක්කේ කුමක්ද? හදප් නොකියාම බැරිය. ඉන්පසුව, උදාහරණයක් ලෙස, Rsyslog (මෙම ලොග් ගොනු ගොනු තුළ ගබඩා කිරීම). LSD. LSD යනු කුමක්දැයි දන්නේ කවුද? නැහැ, මේ LSD නෙවෙයි. පිළිවෙළින් ද ගොනු ගබඩා කරන්න. හොඳයි, ClickHouse යනු අමුතු විකල්පයකි.
Clickhouse සහ තරඟකරුවන්: අවශ්යතා සහ අවස්ථා
අපට අවශ්ය කුමක්ද? අපි මෙහෙයුම ගැන ඕනෑවට වඩා කරදර විය යුතු නැති බව සහතික කිරීමට අවශ්ය, එය කොටුව පිටත වැඩ කිරීමට, වඩාත් සුදුසු අවම වින්යාසය සමග. අපි ගොඩක් ලියන්න ඕනේ, ඉක්මනින් ලියන්න. ඒ වගේම අපි එය සෑම ආකාරයකම මාස, අවුරුදු, එනම් දිගු කාලයක් තබා ගැනීමට අවශ්යයි. ඔවුන් අප වෙත පැමිණ, “මෙහි යමක් ක්රියාත්මක නොවේ” යැයි පැවසූ යම් ගැටලුවක් අපට තේරුම් ගැනීමට අවශ්ය විය හැකිය, එය මාස 3 කට පෙරය), සහ මාස 3 කට පෙර සිදු වූ දේ අපට දැකීමට අවශ්ය වනු ඇත " දත්ත සම්පීඩනය - එය ප්ලස් එකක් වන්නේ මන්දැයි පැහැදිලිය - එය ගතවන ඉඩ ප්රමාණය අඩු කරන බැවිනි.
අපට එවැනි සිත්ගන්නා අවශ්‍යතාවයක් තිබේ: අපි සමහර විට සමහර විධානවල ප්‍රතිදානය ලියන්නෙමු (උදාහරණයක් ලෙස, ලඝු-සටහන්), එය ඉතා පහසුවෙන් කිලෝබයිට් 4 කට වඩා වැඩි විය හැකිය. තවද මෙම දෙය UDP හරහා ක්රියාත්මක වන්නේ නම්, එය වියදම් කිරීමට අවශ්ය නොවේ ... එය සම්බන්ධතාවය සඳහා "උඩිස්" කිසිවක් නොමැති අතර විශාල සේවාදායකයන් සඳහා මෙය ප්ලස් එකක් වනු ඇත.
අපි බලමු open source මොනවද අපිට දෙන්නේ කියලා. පළමුව, අපට ලොග් එන්ජිම ඇත - මෙය අපගේ එන්ජිමයි; ප්‍රතිපත්තිමය වශයෙන්, ඔහුට සෑම දෙයක්ම කළ හැකිය, ඔහුට දිගු රේඛා ලිවිය හැකිය. හොඳයි, එය විනිවිද පෙනෙන ලෙස දත්ත සම්පීඩනය නොකරයි - අපට අවශ්ය නම් අපට විශාල තීරු සම්පීඩනය කළ හැකිය ... ඇත්ත වශයෙන්ම අපට අවශ්ය නැත (හැකි නම්). එකම ප්රශ්නය නම් ඔහුට දිය හැක්කේ ඔහුගේ මතකයට ගැළපෙන දේ පමණක් වීමයි; ඉතිරිය කියවීමට, ඔබ මෙම එන්ජිමේ බින්ලොග් ලබා ගත යුතු අතර, ඒ අනුව, එය සෑහෙන කාලයක් ගත වේ.
වෙනත් විකල්ප මොනවාද? උදාහරණයක් ලෙස, "Hadup". ක්රියාත්මක වීමේ පහසුව... හඩප් සෙට් කරන්න ලේසියි කියලා කවුද හිතන්නේ? ඇත්ත වශයෙන්ම, පටිගත කිරීමේදී ගැටළු නොමැත. කියවන විට සමහර විට ප්රශ්න මතු වේ. ප්‍රතිපත්තිමය වශයෙන්, මම බොහෝ විට නොකියමි, විශේෂයෙන් ලඝු-සටහන් සඳහා. දිගු කාලීන ගබඩා කිරීම - ඇත්ත වශයෙන්ම, ඔව්, දත්ත සම්පීඩනය - ඔව්, දිගු නූල් - ඔබට පටිගත කළ හැකි බව පැහැදිලිය. නමුත් සේවාදායකයන් විශාල සංඛ්යාවක් සිට පටිගත කිරීම ... ඔබ තවමත් ඔබම යමක් කළ යුතුය!
Rsyslog. ඇත්ත වශයෙන්ම, අපි එය උපස්ථ විකල්පයක් ලෙස භාවිතා කළෙමු, එවිට අපට එය බින්ලොග් බැහැර නොකර කියවිය හැකි නමුත් එයට දිගු රේඛා ලිවිය නොහැක; ප්‍රතිපත්තිමය වශයෙන්, එයට කිලෝබයිට් 4 කට වඩා ලිවිය නොහැක. ඔබ විසින්ම ඒ ආකාරයෙන්ම දත්ත සම්පීඩනය කළ යුතුය. කියවීම ගොනු වලින් පැමිණේ.
එවිට LSD හි "badushka" වර්ධනය වේ. අත්යවශ්යයෙන්ම “Rsyslog” ට සමාන ය: එය දිගු නූල් සඳහා සහය දක්වයි, නමුත් එය UDP හරහා ක්‍රියා කළ නොහැකි අතර, ඇත්ත වශයෙන්ම, මේ නිසා, අවාසනාවකට මෙන්, එහි බොහෝ දේ නැවත ලිවිය යුතුය. දස දහස් ගණනක සේවාදායකයන්ගෙන් පටිගත කිරීමට හැකි වන පරිදි LSD ප්‍රතිනිර්මාණය කළ යුතුය.
මෙහි! විහිලු විකල්පයක් නම් ElasticSearch වේ. කොහොම කියන්නද? ඔහු කියවීම සමඟ හොඳින් කටයුතු කරයි, එනම්, ඔහු ඉක්මනින් කියවයි, නමුත් ලිවීමට එතරම් හොඳ නැත. පළමුව, එය දත්ත සම්පීඩනය කරන්නේ නම්, එය ඉතා දුර්වල වේ. බොහෝ දුරට ඉඩ, සම්පූර්ණ සෙවීමක් සඳහා මුල් පරිමාවට වඩා විශාල දත්ත ව්‍යුහයන් අවශ්ය වේ. එය ක්රියාත්මක කිරීමට අපහසු වන අතර බොහෝ විට එය සමඟ ගැටළු මතු වේ. තවද, නැවතත්, ඉලාස්ටික් තුළ පටිගත කිරීම - අප විසින්ම සියල්ල කළ යුතුය.
මෙන්න ClickHouse යනු කදිම විකල්පයකි, ඇත්ත වශයෙන්ම. එකම දේ සර්වර් දස දහස් ගණනකින් පටිගත කිරීම ගැටලුවක්. නමුත් අවම වශයෙන් එක් ගැටළුවක් තිබේ, එය කෙසේ හෝ විසඳා ගැනීමට උත්සාහ කළ හැකිය. තවද වාර්තාවේ ඉතිරි කොටස මෙම ගැටලුව ගැන ය. ClickHouse වෙතින් ඔබට අපේක්ෂා කළ හැක්කේ කුමන ආකාරයේ කාර්ය සාධනයක් ද?
අපි එය ඇතුල් කරන්නේ කෙසේද? MergeTree
ඔබ අතරින් "ClickHouse" ගැන අසා නැති හෝ නොදන්නේ කවුද? මට ඔයාට කියන්න ඕන නේද? ඉතා වේගවත්. එහි ඇතුළු කිරීම - තත්පරයකට ගිගාබිට් 1-2, තත්පරයට ගිගාබිට් 10 දක්වා පිපිරීම් ඇත්ත වශයෙන්ම මෙම වින්‍යාසයට ඔරොත්තු දිය හැකිය - 6-core Xeons දෙකක් (එනම්, වඩාත්ම බලවත් නොවේ), RAM 256 ගිගාබයිට්, ටෙරාබයිට් 20 ක් ඇත. RAID හි (කිසිවෙකු වින්‍යාස කර නැත, පෙරනිමි සැකසුම්). ක්ලික්හවුස් සංවර්ධක ඇලෙක්සි මිලොවිඩොව්, අපි කිසිවක් වින්‍යාස නොකළ නිසා (සියල්ල අපට එලෙස ක්රියාත්මක වූ නිසා) අඬමින් වාඩි වී සිටින්නට ඇත. ඒ අනුව දත්ත හොඳින් සම්පීඩනය කළහොත් තත්පරයට රේඛා බිලියන 6ක පමණ ස්කෑන් වේගයක් ලබා ගත හැක. ඔබ පෙළ තන්තුවක % ට කැමති නම් - තත්පරයට රේඛා මිලියන 100, එනම් එය තරමක් වේගවත් බව පෙනේ.
අපි එය ඇතුල් කරන්නේ කෙසේද? හොඳයි, ඔබ දන්නවා VK PHP භාවිතා කරන බව. අපි සෑම PHP සේවකයෙකුගෙන්ම HTTP හරහා “ClickHouse” වෙත, එක් එක් වාර්තාව සඳහා MergeTree වගුවට ඇතුළත් කරන්නෙමු. මෙම යෝජනා ක්රමයේ ගැටලුවක් දකින්නේ කවුද? කිසියම් හේතුවක් නිසා, සෑම කෙනෙකුම තම දෑත් ඔසවා නැත. මම ඔබට කියන්නම්.
පළමුව, සේවාදායකයන් විශාල ප්‍රමාණයක් ඇත - ඒ අනුව, සම්බන්ධතා රාශියක් ඇත (නරක). එවිට තත්පරයකට වරක් වඩා වැඩි වාර ගණනක් MergeTree වෙත දත්ත ඇතුල් කිරීම වඩා හොඳය. ඒ ඇයි කියලා කවුද දන්නේ? හරි හරි. මම මේ ගැන තව ටිකක් කියන්නම්. තවත් සිත්ගන්නා ප්රශ්නයක් නම්, අපි විශ්ලේෂණ කරන්නේ නැත, අපට දත්ත පොහොසත් කිරීමට අවශ්ය නැත, අපට අතරමැදි සේවාදායකයන් අවශ්ය නොවේ, අපට කෙලින්ම “ClickHouse” වෙත ඇතුළු කිරීමට අවශ්යය (වඩාත් සුදුසු - වඩාත් සෘජු, වඩා හොඳය).
ඒ අනුව, MergeTree හි ඇතුළත් කිරීම සිදු කරන්නේ කෙසේද? තත්පරයකට වරක් හෝ අඩු වාර ගණනක් එයට ඇතුල් කිරීම වඩා හොඳ වන්නේ ඇයි? කාරණය නම් “ClickHouse” යනු තීරු දත්ත ගබඩාවක් වන අතර එය ප්‍රාථමික යතුරේ ආරෝහණ අනුපිළිවෙලට දත්ත වර්ග කරන අතර, ඔබ ඇතුළු කිරීමක් සිදු කරන විට, දත්ත වර්ග කර ඇති තීරු ගණනට අවම වශයෙන් සමාන ගොනු ගණනාවක් නිර්මාණය වේ. ප්‍රාථමික යතුරේ ආරෝහණ අනුපිළිවෙලින් (වෙනම නාමාවලියක් සාදනු ලැබේ, එක් එක් ඇතුල් කිරීම සඳහා තැටියේ ගොනු කට්ටලයක්). එවිට ඊළඟ ඇතුළත් කිරීම පැමිණේ, සහ පසුබිම තුළ ඒවා විශාල "කොටස්" බවට ඒකාබද්ධ වේ. දත්ත වර්ග කර ඇති බැවින්, බොහෝ මතකය පරිභෝජනය නොකර වර්ග කළ ගොනු දෙකක් "ඒකාබද්ධ" කළ හැකිය.
නමුත්, ඔබ අනුමාන කළ හැකි පරිදි, ඔබ එක් එක් ඇතුල් කිරීම සඳහා ගොනු 10 ක් ලියන්නේ නම්, ක්ලික්හවුස් (හෝ ඔබේ සේවාදායකය) ඉක්මනින් අවසන් වනු ඇත, එබැවින් විශාල කණ්ඩායම් වලට ඇතුල් කිරීම රෙකමදාරු කරනු ලැබේ. ඒ අනුව, අපි කිසි විටෙකත් පළමු යෝජනා ක්රමය නිෂ්පාදනයට දියත් නොකළෙමු. අපි වහාම එකක් දියත් කළෙමු, මෙහි අංක 2 හි ඇත:
මෙතන හිතන්න අපි දියත් කරපු servers දාහක් විතර තියෙනවා, තියෙන්නේ PHP විතරයි කියලා. තවද සෑම සේවාදායකයකම අපගේ දේශීය නියෝජිතයා ඇත, එය අපි “කිටන්හවුස්” ලෙස හැඳින්වුවෙමු, එය “ක්ලික්හවුස්” සමඟ එක් සම්බන්ධතාවයක් පවත්වා ගෙන තත්පර කිහිපයකට වරක් දත්ත ඇතුළත් කරයි. දත්ත ඇතුළත් කරන්නේ MergeTree වෙත නොව, බෆර වගුවකට, එය කෙලින්ම MergeTree වෙත ඇතුළු කිරීම වැළැක්වීමට නිශ්චිතවම සේවය කරයි.
බෆර වගු සමඟ වැඩ කිරීම
එය කුමක්ද? බෆර වගු යනු ඛණ්ඩනය වූ මතක කැබැල්ලකි (එනම්, එය නිතර නිතර එයට ඇතුල් කළ හැක). ඒවා කැබලි කිහිපයකින් සමන්විත වන අතර, එක් එක් කෑලි ස්වාධීන බෆරයක් ලෙස ක්‍රියා කරන අතර ඒවා ස්වාධීනව සෝදා හරිනු ලැබේ (ඔබට බෆරයේ බොහෝ කෑලි තිබේ නම්, තත්පරයට බොහෝ ඇතුළු කිරීම් ඇත). මෙම වගු වලින් කියවිය හැකිය - එවිට ඔබ බෆරයේ සහ මව් වගුවේ අන්තර්ගතයේ එකමුතුව කියවා ඇත, නමුත් මේ මොහොතේ ලිවීම අවහිර කර ඇත, එබැවින් එතැන් සිට කියවීම නොකිරීමට වඩා හොඳය. බෆර වගු ඉතා හොඳ QPS පෙන්වයි, එනම්, QPS 3 දක්වා ඇතුළු කිරීමේදී ඔබට කිසිදු ගැටළුවක් ඇති නොවේ. සේවාදායකයේ බලය නැති වුවහොත් දත්ත නැති විය හැකි බව පැහැදිලිය, මන්ද එය මතකයේ පමණක් ගබඩා කර ඇත.
ඒ අතරම, බෆරයක් සහිත යෝජනා ක්රමය ALTER සංකීර්ණ කරයි, මන්ද ඔබ මුලින්ම පැරණි යෝජනා ක්රමය සමඟ පැරණි බෆර වගුව අතහැර දැමිය යුතුය (දත්ත ඕනෑම තැනක අතුරුදහන් නොවනු ඇත, මන්ද එය වගුව මකා දැමීමට පෙර එය සෝදා හරිනු ඇත). එවිට ඔබට අවශ්ය වගුව "වෙනස්" කර නැවත බෆර් වගුව සාදන්න. ඒ අනුව, බෆර් වගුවක් නොමැති අතර, ඔබගේ දත්ත ඕනෑම තැනක ගලා නොයනු ඇත, නමුත් ඔබට එය අවම වශයෙන් දේශීයව තැටියේ තබා ගත හැකිය.
Kittenhouse යනු කුමක්ද සහ එය ක්‍රියා කරන්නේ කෙසේද?
KittenHouse යනු කුමක්ද? මේක proxy එකක්. කුමන භාෂාව අනුමාන කරන්නද? මම මගේ වාර්තාවේ වඩාත්ම උද්දීපනය කරන මාතෘකා එකතු කළෙමි - “ක්ලික්හවුස්”, යන්න, සමහර විට මට වෙනත් දෙයක් මතකයි. ඔව්, මෙය Go වලින් ලියා ඇත, මන්ද මම C වලින් ලියන්නේ කෙසේදැයි ඇත්තටම නොදන්නා නිසා, මට අවශ්ය නැත.
ඒ අනුව, එය එක් එක් සේවාදායකය සමඟ සම්බන්ධතාවයක් පවත්වා ගෙන යන අතර මතකයට ලිවිය හැකිය. උදාහරණයක් ලෙස, අපි ක්ලික්හවුස් වෙත දෝෂ ලොග් ලියන්නේ නම්, ක්ලික්හවුස් දත්ත ඇතුළු කිරීමට කාලය නොමැති නම් (සියල්ලට පසු, ඕනෑවට වඩා ලියා ඇත්නම්), එවිට අපි මතකය ඉදිමෙන්නේ නැත - අපි ඉතිරිය ඉවතට විසි කරමු. මොකද අපි තත්පරයකට ගිගාබිට් කිහිපයක් දෝශ ලිව්වොත් සමහර විට අපිට සමහර විට එලියට විසි කරන්න පුළුවන්. Kittenhouse මෙය කළ හැකිය. ඊට අමතරව, එය විශ්වාසදායක බෙදාහැරීමක් සිදු කළ හැකිය, එනම්, දේශීය යන්ත්රයේ තැටියට ලිවීම සහ සෑම අවස්ථාවකදීම (එහි, සෑම තත්පර දෙකකට වරක්) මෙම ගොනුවෙන් දත්ත ලබා දීමට උත්සාහ කරයි. මුලදී අපි සාමාන්‍ය අගයන් ආකෘතිය භාවිතා කළෙමු - සමහර ද්විමය ආකෘතියක් නොව, පෙළ ආකෘතියක් (සාමාන්‍ය SQL හි මෙන්).
නමුත් පසුව මෙය සිදු විය. අපි විශ්වාසදායක බෙදාහැරීමක් භාවිතා කළා, ලොග් ලිව්වා, පසුව තීරණය කළා (එය කොන්දේසි සහිත පරීක්ෂණ පොකුරක්) ... එය පැය කිහිපයක් නිවා දමා නැවත ගෙන එන ලදී, සහ සේවාදායකයන් දහසකින් ඇතුළු කිරීමක් ආරම්භ විය - ක්ලික්හවුස් තවමත් සතුව ඇති බව පෙනී ගියේය. “සම්බන්ධතා මත නූල්” - ඒ අනුව, සම්බන්ධතා දහසක් තුළ, සක්‍රීය ඇතුළත් කිරීමක් සේවාදායකයේ බර සාමාන්‍ය එකහමාරක් පමණ වේ. පුදුමයට කරුණක් නම්, සේවාදායකය ඉල්ලීම් පිළිගත් නමුත්, ටික වේලාවකට පසුව දත්ත තවමත් ඇතුළත් කර ඇත; නමුත් සේවාදායකයට එය සේවය කිරීම ඉතා අපහසු විය ...
nginx එකතු කරන්න
එක් සම්බන්ධතා ආකෘතියක් සඳහා නූල් සඳහා එවැනි විසඳුමක් nginx වේ. අපි Clickhouse ඉදිරිපිට nginx ස්ථාපනය කර, ඒ සමඟම අනුපිටපත් දෙකක් සඳහා සමතුලිතතාවය සකසා (අපගේ ඇතුළු කිරීමේ වේගය 2 ගුණයකින් වැඩි විය, නමුත් මෙය එසේ විය යුතු කරුණක් නොවේ) සහ Clickhouse වෙත සම්බන්ධතා ගණන සීමා කර ඇත. upstream සහ, ඒ අනුව, වැඩි , සම්බන්ධතා 50 ට වඩා, එය ඇතුල් කිරීමේ තේරුමක් නොමැති බව පෙනේ.
මෙම යෝජනා ක්රමයේ සාමාන්යයෙන් අවාසි ඇති බව අපට වැටහුණි, මන්ද අපට මෙහි ඇත්තේ එක් nginx එකක් පමණි. ඒ අනුව, මෙම nginx කඩා වැටුණහොත්, අනුපිටපත් තිබියදීත්, අපට දත්ත නැති වී යයි හෝ, අවම වශයෙන්, කොතැනකවත් ලියන්න එපා. ඒකයි අපි අපේම බර බැලන්සින් හැදුවේ. “ක්ලික්හවුස්” තවමත් ලඝු-සටහන් සඳහා සුදුසු බව අපට වැටහුණු අතර, “භූතයා” ද ඔහුගේ ලඝු-සටහන් “ක්ලික්හවුස්” හි ලිවීමට පටන් ගත්තේය - ඉතා පහසු, අවංකව කිවහොත්. අපි තවමත් වෙනත් "භූතයන්" සඳහා එය භාවිතා කරමු.
එවිට අපි මෙම සිත්ගන්නා ගැටළුව සොයා ගත්තෙමු: ඔබ SQL මාදිලියට ඇතුළත් කිරීමේ සම්මත නොවන ක්‍රමයක් භාවිතා කරන්නේ නම්, එය සම්පූර්ණ AST මත පදනම් වූ SQL විග්‍රහයකට බල කරයි, එය තරමක් මන්දගාමී වේ. ඒ අනුව, මෙය කිසි විටෙකත් සිදු නොවන බව සහතික කිරීම සඳහා අපි සැකසුම් එකතු කර ඇත්තෙමු. අපි ලෝඩ් බැලන්සින්, සෞඛ්‍ය පරීක්ෂණ කළා, ඒ නිසා කෙනෙක් මැරුණොත් අපි තවමත් දත්ත දාලා යනවා. අපට දැන් විවිධ Clickhouse පොකුරු තිබිය යුතු වගු විශාල ප්‍රමාණයක් ඇත. තවද අපි වෙනත් භාවිතයන් ගැනද සිතීමට පටන් ගත්තෙමු - උදාහරණයක් ලෙස, අපට nginx මොඩියුල වලින් ලඝු-සටහන් ලිවීමට අවශ්ය විය, නමුත් ඔවුන් අපගේ RPC භාවිතයෙන් සන්නිවේදනය කරන්නේ කෙසේදැයි නොදනී. හොඳයි, මම ඔවුන්ට අවම වශයෙන් කෙසේ හෝ යවන්නේ කෙසේදැයි ඉගැන්වීමට කැමතියි - උදාහරණයක් ලෙස, UDP හරහා localhost හි සිදුවීම් ලබාගෙන ඒවා Clickhouse වෙත යොමු කිරීම.
විසඳුමෙන් එක් පියවරක් දුරින්
අවසාන යෝජනා ක්රමය මේ ආකාරයට පෙනෙන්නට පටන් ගත්තේය (මෙම යෝජනා ක්රමයේ සිව්වන අනුවාදය): ක්ලික්හවුස් ඉදිරිපිට ඇති සෑම සේවාදායකයකම nginx (එකම සේවාදායකයේ) ඇති අතර එය හුදෙක් 50 ක සම්බන්ධතා සංඛ්‍යාවේ සීමාවක් සමඟ දේශීය සත්කාරක සමාගම වෙත ඉල්ලීම් ප්‍රොක්සි කරයි. කෑලි. මෙම යෝජනා ක්රමය දැනටමත් තරමක් ක්රියාත්මක විය, ඒ සමඟ සෑම දෙයක්ම ඉතා හොඳ විය.
අපි මේ විදියට මාසයක් විතර ජීවත් වුණා. හැමෝම සතුටු වුණා, ඔවුන් මේස එකතු කළා, ඔවුන් එකතු කළා, එකතු කළා. අපි සෑම වගුවකම කෑලි 16 ක් සහ තත්පර කිහිපයක ෆ්ලෑෂ් පරතරයක් කළා; අපට වගු 20 ක් තිබූ අතර සෑම වගුවකටම තත්පරයට ඇතුළු කිරීම් 8 ක් ලැබුණි - මෙම අවස්ථාවේදී “ක්ලික්හවුස්” ආරම්භ විය ... වාර්තා මන්දගාමී වීමට පටන් ගත්තේය. ඔවුන් හරහා ගියේද නැත ... Nginx හි පෙරනිමියෙන් එතරම් සිත්ගන්නාසුලු දෙයක් තිබුණි, සම්බන්ධතා උඩු ප්‍රවාහයෙන් අවසන් වුවහොත්, එය සියලු නව ඉල්ලීම් සඳහා “502” ආපසු ලබා දුන්නේය.
මෙන්න අපි (මම ක්ලික්හවුස් එකේම ලොග් බැලුවා) ඉල්ලීම් වලින් සියයට භාගයක් පමණ අසාර්ථකයි. ඒ අනුව, තැටි භාවිතය ඉහළයි, ඒකාබද්ධ කිරීම් ගොඩක් තිබුණා. හොඳයි, මම මොකක්ද කළේ? ස්වාභාවිකවම, සම්බන්ධතාවය සහ උඩුගං බලා හරියටම අවසන් වූයේ මන්දැයි සොයා ගැනීමට මම වෙහෙස නොවෙමි.
nginx ප්‍රතිලෝම ප්‍රොක්සියක් සමඟ ප්‍රතිස්ථාපනය කිරීම
මෙය අප විසින්ම කළමනාකරණය කර ගත යුතු බව මම තීරණය කළෙමි, එය nginx වෙත තැබීමට අවශ්ය නැත - Clickhouse හි ඇති වගු මොනවාදැයි nginx නොදනී, මම nginx වෙනුවට ප්‍රතිලෝම ප්‍රොක්සියක් ආදේශ කළෙමි, එය මා විසින්ම ලියා ඇත.
ඔහු මොනවද කරන්නේ? එය fasthttp පුස්තකාලය "goshnoy" මත පදනම්ව ක්‍රියා කරයි, එනම් වේගවත්, nginx තරම් වේගවත්. සමාවන්න, ඊගෝර්, ඔබ මෙහි සිටී නම් (සටහන: Igor Sysoev යනු nginx වෙබ් සේවාදායකය නිර්මාණය කළ රුසියානු ක්‍රමලේඛකයෙකි). එයට මේවා කුමන ආකාරයේ විමසුම් ද යන්න තේරුම් ගත හැක - INSERT හෝ SELECT - ඒ අනුව, එය විවිධ ආකාරයේ විමසුම් සඳහා විවිධ සම්බන්ධතා සංචිත දරයි.
ඒ අනුව, ඇතුළත් කිරීමේ ඉල්ලීම් සම්පූර්ණ කිරීමට අපට කාලය නොමැති වුවද, "තෝරාගැනීම්" සමත් වනු ඇත, සහ අනෙක් අතට. තවද එය දත්ත බෆර වගු වලට කාණ්ඩගත කරයි - කුඩා බෆරයක් සමඟ: කිසියම් දෝෂ, වාක්‍ය ඛණ්ඩ දෝෂ සහ යනාදිය තිබේ නම් - ඒවා ඉතිරි දත්ත වලට විශාල ලෙස බලපාන්නේ නැති නිසා, අපි සරලව බෆර වගුවලට ඇතුළු කළ විට, අපි කුඩා "බාචි" ඇති අතර, සියලුම වාක්‍ය ඛණ්ඩ දෝෂ මෙම කුඩා කොටසට පමණක් බලපෑවේය; සහ මෙහිදී ඔවුන් දැනටමත් විශාල බෆරයකට බලපානු ඇත. කුඩා යනු මෙගාබයිට් 1 කි, එනම් එතරම් කුඩා නොවේ.
සමමුහුර්තකරණයක් ඇතුළත් කිරීම සහ අත්යවශ්යයෙන්ම nginx ප්‍රතිස්ථාපනය කිරීම, අත්යවශ්යයෙන්ම nginx පෙර කළ දේම කරයි - මේ සඳහා ඔබට දේශීය “Kittenhouse” වෙනස් කිරීමට අවශ්ය නොවේ. එය fasthttp භාවිතා කරන බැවින්, එය ඉතා වේගවත් වේ - ඔබට ප්‍රතිලෝම ප්‍රොක්සියක් හරහා තනි ඇතුළු කිරීම් සඳහා තත්පරයකට ඉල්ලීම් 100 කට වඩා කළ හැකිය. න්‍යායාත්මකව, ඔබට කිටන්හවුස් ප්‍රතිලෝම ප්‍රොක්සියට වරකට එක් පේළියක් ඇතුළු කළ හැකිය, නමුත් ඇත්ත වශයෙන්ම අපි එය නොකරමු.
යෝජනා ක්රමය මේ ආකාරයට පෙනෙන්නට පටන් ගත්තේය: “කිටන්හවුස්”, ප්‍රතිලෝම ප්‍රොක්සි බොහෝ ඉල්ලීම් වගු වලට කාණ්ඩ කරන අතර, අනෙක් අතට, බෆර වගු ඒවා ප්‍රධාන ඒවාට ඇතුළත් කරයි.
Killer යනු තාවකාලික විසඳුමකි, Kitten ස්ථිරයි
මෙය සිත් ඇදගන්නාසුළු ගැටළුවකි... ඔබගෙන් කිසිවෙකු fasthttp භාවිතා කර තිබේද? POST ඉල්ලීම් සමඟ fasthttp භාවිතා කළේ කවුද? බොහෝ විට, මෙය ඇත්ත වශයෙන්ම සිදු නොකළ යුතුව තිබුණි, මන්ද එය පෙරනිමියෙන් ඉල්ලීම් බෆරය කරන අතර අපගේ බෆරයේ ප්රමාණය මෙගාබයිට් 16ක් ලෙස සකසා ඇත. ඇතුළත් කිරීම යම් අවස්ථාවක දී නතර වූ අතර, දස දහස් ගණන් සර්වර් වලින් මෙගාබයිට් 16 කුට්ටි පැමිණීමට පටන් ගත් අතර, ක්ලික්හවුස් වෙත යැවීමට පෙර ඒවා සියල්ල මතකයේ බෆර කර ඇත. ඒ අනුව, මතකය අවසන් විය, Out-Of-Memory Killer පැමිණ ප්‍රතිලෝම ප්‍රොක්සිය (හෝ “Clickhouse”, ප්‍රතිලෝම ප්‍රොක්සියට වඩා න්‍යායාත්මකව “කන්න” හැකි) මරා දැමීය. චක්රය නැවත නැවතත් සිදු විය. ඉතා ප්රසන්න ප්රශ්නයක් නොවේ. නමුත් අපි මෙය පැකිළුණේ මාස කිහිපයක මෙහෙයුමෙන් පසුවය.
මම මොනවද කරලා තියෙන්නේ? නැවතත්, හරියටම සිදුවූයේ කුමක්ද යන්න තේරුම් ගැනීමට මා කැමති නැත. මම හිතන්නේ ඔබ මතකයට බෆර් නොකළ යුතු බව පැහැදිලියි. මම උත්සහ කලත් fasthttp patch කරන්න බැරි වුනා. එත් මුකුත් පැච් කරන්න ඕනේ නැති විදියට හදාගන්න ක්‍රමයක් හොයාගෙන මම HTTP එකේ මගේම ක්‍රමයක් හැදුවා - මම ඒකට කිව්වේ KITTEN කියලා. හොඳයි, එය තර්කානුකූලයි - "VK", "පූස් පැටියා"... වෙන මොනවද?..
Kitten ක්රමය සමඟ සේවාදායකයට ඉල්ලීමක් පැමිණියහොත්, සේවාදායකය “meow” ලෙස ප්‍රතිචාර දැක්විය යුතුය - තර්කානුකූලව. ඔහු මෙයට ප්‍රතිචාර දක්වන්නේ නම්, ඔහු මෙම ප්රොටෝකෝලය තේරුම් ගෙන ඇති බව සලකනු ලැබේ, පසුව මම සම්බන්ධතාවයට බාධා කරමි (fasthttp එවැනි ක්‍රමයක් ඇත), සහ සම්බන්ධතාවය “අමු” මාදිලියට යයි. මට එය අවශ්ය වන්නේ ඇයි? TCP සම්බන්ධතා වලින් කියවීම සිදුවන ආකාරය පාලනය කිරීමට මට අවශ්යයි. TCP සතුව අපූරු දේපලක් ඇත: කිසිවෙකු අනෙක් පැත්තෙන් කියවන්නේ නැතිනම්, ලිවීම බලා සිටීමට පටන් ගනී, මතකය මේ සඳහා විශේෂයෙන් වැය නොවේ.
ඉතින් මම එකපාරකට clients 50ක් විතර කියෙව්වා (පනහෙන් මොකද පනහෙන් අනිවා ප්‍රමාණවත් වෙන්න ඕනේ, තව DC එකකින් Rate එක ආවත්)... මේ ප්‍රවේශය එක්ක අඩුම ගානේ 20 පාරක් වත් පාරිභෝජනය අඩුවෙලා තියෙනවා, ඒත් මම ඇත්තම කියනවා. , මට හරියටම වේලාව මැනිය නොහැකි විය, මන්ද එය දැනටමත් නිෂ්ඵල ය (එය දැනටමත් දෝෂයේ මට්ටමට පැමිණ ඇත). ප්රොටෝකෝලය ද්විමය වේ, එනම්, එහි වගුවේ නම සහ දත්ත අඩංගු වේ; http ශීර්ෂ නොමැත, එබැවින් මම වෙබ් සොකට් එකක් භාවිතා නොකළෙමි (මට බ්‍රව්සර් සමඟ සන්නිවේදනය කිරීමට අවශ්ය නැත - මම අපගේ අවශ්‍යතාවලට ගැලපෙන ප්‍රොටෝකෝලයක් සෑදුවෙමි). ඔහු සමඟ සෑම දෙයක්ම හොඳින් සිදු විය.
බෆර් මේසය දුකයි
මෑතකදී අපට බෆර වගු වල තවත් රසවත් අංගයක් හමු විය. තවද මෙම ගැටළුව දැනටමත් අනෙක් ඒවාට වඩා බෙහෙවින් වේදනාකාරී ය. අපි මෙම තත්වය සිතමු: ඔබ දැනටමත් ක්ලික්හවුස් සක්‍රියව භාවිතා කරයි, ඔබට ක්ලික්හවුස් සේවාදායකයන් දුසිම් ගණනක් ඇත, සහ ඔබට කියවීමට ඉතා දිගු කාලයක් ගත වන ඉල්ලීම් කිහිපයක් තිබේ (තත්පර 60 කට වඩා වැඩි යැයි කියමු); සහ ඔබ පැමිණ මේ මොහොතේ Alter කරන්න... ඒ අතරතුර, "Alter" ට පෙර ආරම්භ වූ "තෝරාගැනීම්" මෙම වගුවට ඇතුළත් නොවනු ඇත, "Alter" ආරම්භ නොවනු ඇත - සමහරවිට "Clickhouse" ක්‍රියා කරන ආකාරය පිළිබඳ සමහර විශේෂාංග මෙම ස්ථානය. සමහර විට මෙය නිවැරදි කළ හැකිද? නැත්නම් බැරිද?
පොදුවේ ගත් කල, යථාර්ථයේ දී මෙය එතරම් විශාල ගැටළුවක් නොවන බව පැහැදිලිය, නමුත් බෆර වගු සමඟ එය වඩාත් වේදනාකාරී වේ. මක්නිසාද යත්, අපි කියමු, ඔබේ “වෙනස් කරන්න” කල් ඉකුත් වේ නම් (එය වෙනත් සත්කාරකයක් මත කල් ඉකුත් විය හැකිය - ඔබේ නොව, නමුත් අනුරුවක, උදාහරණයක් ලෙස), එවිට... ඔබ බෆර වගුව මකා ඇත, ඔබේ “වෙනස් කරන්න” ( හෝ වෙනත් සත්කාරක) කල් ඉකුත් විය. පසුව "වෙනස් කිරීම" දෝෂයක් සිදුවී ඇත) - ඔබ තවමත් දත්ත දිගටම ලිවීම සහතික කළ යුතුය: ඔබ බෆර වගු නැවත සාදන්න (මව් වගුවේ ඇති යෝජනා ක්‍රමයට අනුව), ඉන්පසු "Alter" හරහා ගොස්, සියල්ලට පසු අවසන් වන අතර, මේසයේ බෆරය දෙමාපියන්ගෙන් යෝජනා ක්රමයෙන් වෙනස් වීමට පටන් ගනී. “Alter” යනු කුමක්ද යන්න මත පදනම්ව, ඇතුළු කිරීම තවදුරටත් මෙම බෆර වගුව වෙත නොයනු ඇත - මෙය ඉතා කණගාටුදායකය.
එවැනි ලකුණක් ද ඇත (සමහර විට යමෙකු එය දුටුවේය) - එය Clickhouse හි නව අනුවාද වල query_thread_log ලෙස හැඳින්වේ. පෙරනිමියෙන්, සමහර අනුවාදයක එකක් විය. මෙන්න අපි මාස කිහිපයක් (ගිගාබයිට් 840) තුළ වාර්තා මිලියන 100 ක් රැස් කර ඇත. මෙයට හේතුව “ඇතුළු කිරීම්” එහි ලියා තිබීමයි (සමහර විට දැන්, මාර්ගය වන විට, ඒවා ලියා නොමැත). මම ඔබට පැවසූ පරිදි, අපගේ “ඇතුළු කිරීම්” කුඩායි - අපට බෆර වගු තුළට “ඇතුළු කිරීම්” රාශියක් තිබුණි. මෙය අක්රිය කර ඇති බව පැහැදිලිය - මම අපගේ සේවාදායකයේ මා දුටු දේ ඔබට කියමි. ඇයි? මෙය බෆර් වගු භාවිතා කිරීමට එරෙහි තවත් තර්කයකි! Spotty ගොඩක් දුකයි.
මේ මිනිහගේ නම Spotty කියලා කවුද දන්නේ? VK සේවකයින් තම දෑත් එසවූහ. හරි.
"KittenHouse" සඳහා සැලසුම් ගැන
සැලසුම් සාමාන්යයෙන් බෙදා නොගනී, හරිද? හදිසියේම ඔබ ඒවා ඉටු නොකරන අතර අන් අයගේ ඇස් හමුවේ ඉතා හොඳ පෙනුමක් නොලැබේ. නමුත් මම අවදානම ගන්නම්! අපට පහත දේ කිරීමට අවශ්යයි: බෆර වගු, මට පෙනෙන පරිදි, තවමත් කිහිලිකරුවක් වන අතර අප විසින්ම ඇතුළත් කිරීම බෆරය කළ යුතුය. නමුත් අපට තවමත් එය තැටියේ බෆර කිරීමට අවශ්ය නැත, එබැවින් අපි මතකයේ ඇතුළත් කිරීම බෆර් කරන්නෙමු.
ඒ අනුව, “ඇතුළත් කිරීමක්” සෑදූ විට, එය තවදුරටත් සමමුහුර්ත නොවනු ඇත - එය දැනටමත් බෆර වගුවක් ලෙස ක්‍රියා කරනු ඇත, මව් වගුවට ඇතුළු කරනු ඇත (හොඳයි, යම් දවසක පසුව) සහ ඇතුළත් කිරීම් සමත් වූ වෙනම නාලිකාවක් හරහා වාර්තා කරයි. නැත.
මට සමමුහුර්ත ඇතුළත් කිරීම හැර යා නොහැක්කේ ඇයි? එය වඩාත් පහසු වේ. කාරණය නම්, ඔබ සත්කාරක 10 කින් ඇතුළු කළහොත් සියල්ල හොඳයි - ඔබට එක් එක් සත්කාරක සමාගමෙන් ටිකක් ලැබෙනු ඇත, ඔබ තත්පරයකට වරක් එහි ඇතුළු කරන්න, සියල්ල හොඳයි. නමුත් මෙම යෝජනා ක්රමය ක්රියාත්මක වීමට මම කැමතියි, උදාහරණයක් ලෙස, යන්ත්‍ර දෙකකින්, එවිට ඔබට අධික වේගයෙන් බාගත කළ හැකිය - සමහර විට ක්ලික්හවුස් වෙතින් උපරිමය ලබා නොගන්න, නමුත් එක් යන්ත්‍රයකින් තත්පරයට අවම වශයෙන් මෙගාබයිට් 100 ක් ප්‍රතිලෝම ප්‍රොක්සියක් හරහා ලියන්න - මෙම යෝජනා ක්රමය විශාල හා කුඩා ප්රමාණ දෙකටම පරිමාණය කළ යුතුය, එබැවින් අපට එක් එක් ඇතුල් කිරීම සඳහා තත්පරයක් බලා සිටිය නොහැක, එබැවින් එය අසමමිතික විය යුතුය. ඒ ආකාරයෙන්ම, ඇතුළත් කිරීම අවසන් වූ පසු අසමමුහුර්ත තහවුරු කිරීම් පැමිණිය යුතුය. එය සම්මත වූවාද නැද්ද යන්න අපි දනිමු.
වැදගත්ම දෙය නම් මෙම යෝජනා ක්රමය තුළ ඇතුළත් කිරීම සිදු වූවාද නැද්ද යන්න අපි නිසැකවම දනිමු. මෙම තත්වය සිතා බලන්න: ඔබට බෆර වගුවක් තිබේ, ඔබ එයට යමක් ලිවීය, පසුව, මේසය කියවීමට පමණක් ප්‍රකාරයට ගොස් බෆරය සේදීමට උත්සාහ කළ බව කියමු. දත්ත යන්නේ කොතැනටද? ඔවුන් බෆරයේ පවතිනු ඇත. නමුත් අපට මෙය නිසැක විය නොහැක - වෙනත් දෝෂයක් තිබේ නම්, දත්ත බෆරයේ නොපවතින්නේ නම් ... (Alexey Milovidov, Yandex, ClickHouse සංවර්ධක ලිපිනයන්) නැතහොත් එය පවතිනු ඇත්ද? සැමවිටම? සෑම දෙයක්ම හොඳින් සිදුවන බව ඇලෙක්සි අපට ඒත්තු ගන්වයි. ඔහුව විශ්වාස නොකිරීමට අපට හේතුවක් නැත. නමුත් සියල්ලම එක හා සමානයි: අපි බෆර් වගු භාවිතා නොකරන්නේ නම්, ඒවා සමඟ කිසිදු ගැටළුවක් ඇති නොවේ. ප්‍රතිපත්තිමය වශයෙන් විශාල ගැටළු නොමැති වුවද මෙන් දෙගුණයක් වගු සෑදීම ද අපහසුය. සැලැස්ම මෙයයි.
කියවීම ගැන කතා කරමු
දැන් අපි කියවීම ගැන කතා කරමු. අපි අපේම මෙවලමක් ද මෙහි ලියා ඇත. ඔබේම උපකරණයක් මෙහි ලියන්නේ ඇයි?.. සහ Tabix භාවිතා කළේ කවුද? කොහොම හරි අත උස්සපු අය ටිකයි... ඒ වගේම ටැබික්ස් එකේ රඟපෑම ගැන සෑහීමකට පත් වෙන්නේ කවුද? හොඳයි, අපි ඒ ගැන සතුටු නොවන අතර දත්ත බැලීම සඳහා එය ඉතා පහසු නොවේ. එය විශ්ලේෂණ සඳහා හොඳයි, නමුත් බැලීම සඳහා පමණක් එය පැහැදිලිවම ප්‍රශස්ත කර නැත. ඉතින් මම මගේම, මගේම අතුරු මුහුණතක් ලිව්වා.
එය ඉතා සරලයි - එය දත්ත පමණක් කියවිය හැක. ඔහු ග්‍රැෆික් පෙන්වන්න දන්නේ නැහැ, කිසිම දෙයක් කරන්න දන්නේ නැහැ. නමුත් එය අපට අවශ්ය දේ පෙන්විය හැක: නිදසුනක් ලෙස, වගුවේ පේළි කීයක් තිබේද, එය කොපමණ ඉඩ ප්‍රමාණයක් ගනීද (එය තීරු වලට නොකැඩී), එනම් අපට අවශ්ය වන්නේ ඉතා මූලික අතුරු මුහුණතකි.
එය Sequel Pro වලට බෙහෙවින් සමාන බව පෙනේ, නමුත් Twitter හි Bootstrap සහ දෙවන අනුවාදය මත පමණක් සාදන ලදී. ඔබ අසයි: "යූරි, දෙවන අනුවාදයේ ඇයි?" කුමන වසරද? 2018? පොදුවේ ගත් කල, මම මෙය බොහෝ කලකට පෙර “මාංශ පේශි” (MySQL) සඳහා කළ අතර එහි ඇති විමසුම්වල පේළි කිහිපයක් පමණක් වෙනස් කළ අතර එය “ක්ලික්හවුස්” සඳහා වැඩ කිරීමට පටන් ගත්තේය, ඒ සඳහා විශේෂ ස්තූතිය! මක්නිසාද යත් විග්‍රහකය “මාංශ පේශි” එකට බෙහෙවින් සමාන වන අතර විමසුම් ඉතා සමාන ය - ඉතා පහසු, විශේෂයෙන් මුලින්.
හොඳයි, එයට වගු පෙරීමට හැකිය, වගුවේ ව්‍යුහය සහ අන්තර්ගතය පෙන්විය හැකිය, ඔබට වර්ග කිරීමට, තීරු අනුව පෙරීමට, ප්‍රතිඵලයට හේතු වූ විමසුම පෙන්වයි, බලපෑමට ලක් වූ පේළි (ප්‍රතිඵලයක් ලෙස කොපමණද), එනම්, දත්ත බැලීම සඳහා මූලික දේවල්. ලස්සන වේගවත්.
සංස්කාරකවරයෙක් ද සිටී. මම අවංකවම Tabix වෙතින් සම්පූර්ණ සංස්කාරකය සොරකම් කිරීමට උත්සාහ කළ නමුත් මට නොහැකි විය. නමුත් කෙසේ හෝ එය ක්රියාත්මක වේ. ප්‍රතිපත්තිමය වශයෙන්, එපමණයි.
"Clickhouse" ගුහා සඳහා සුදුසු වේ
ක්ලික්හවුස්, විස්තර කර ඇති සියලුම ගැටළු තිබියදීත්, ලඝු-සටහන් සඳහා ඉතා හොඳින් ගැලපෙන බව මට ඔබට පැවසීමට අවශ්යය. වැදගත්ම දෙය නම්, එය අපගේ ගැටළුව විසඳයි - එය ඉතා වේගවත් වන අතර තීරු මගින් ලඝු-සටහන් පෙරීමට ඔබට ඉඩ සලසයි. ප්‍රතිපත්තිමය වශයෙන්, බෆර වගු හොඳින් ක්රියාත්මක වී නැත, නමුත් සාමාන්යයෙන් කිසිවෙක් නොදන්නේ මන්දැයි ... සමහර විට දැන් ඔබට ගැටළු ඇති වන්නේ කොතැනදැයි ඔබ හොඳින් දනී.
TCP? පොදුවේ ගත් කල, VK හි UDP භාවිතා කිරීම සිරිතකි. මම TCP භාවිතා කරන විට ... ඇත්ත වශයෙන්ම, කිසිවෙකු මට කීවේ නැත: "යූරි, ඔබ කුමක් ගැනද කතා කරන්නේ! ඔබට බැහැ, ඔබට UDP අවශ්යයි. TCP එතරම් බියජනක නොවන බව පෙනී ගියේය. එකම දෙය නම්, ඔබ ලියන ක්රියාකාරී සංයෝග දස දහස් ගණනක් තිබේ නම්, ඔබ එය ටිකක් ප්රවේශමෙන් සකස් කළ යුතුය; නමුත් එය කළ හැකි අතර තරමක් පහසුය.
හැමෝම අපේ පොදු “VK backend” එකට subscribe කරනවා නම් HighLoad Siberia එකේ “Kittenhouse” සහ “Lighthouse” පළ කරන්න මම පොරොන්දු වුනා... ඒ වගේම ඔයා දන්නවනේ, හැමෝම subscribe කරලා නෑ... ඇත්ත වශයෙන්ම, මම ඔයාගෙන් අපේ Subscribe කරන්න ඉල්ලන්නේ නැහැ. පොදු. ඔබගෙන් තවමත් බොහෝ දෙනෙක් සිටිති, යමෙකු අමනාප වීමට පවා ඉඩ ඇත, නමුත් තවමත්, කරුණාකර දායක වන්න (මෙහිදී මට බළලෙකුගේ ඇස් සෑදිය යුතුය). ඒ . ඔයාට බොහෝම ස්තූතියි! Github අපේ . Clickhouse සමඟින් ඔබේ හිසකෙස් මෘදු සහ සිනිඳු වනු ඇත.
නායකත්වය: - මිත්රවරුනි, දැන් ප්රශ්න සඳහා. අපි අගය සහතිකය සහ VHS පිළිබඳ ඔබේ වාර්තාව ඉදිරිපත් කළ වහාම.
යූරි නස්රෙට්ඩිනොව් (මෙතැන් සිට YN ලෙස හැඳින්වේ): - VHS පිළිබඳ මගේ වාර්තාව අවසන් වූවා නම් ඔබට වාර්තා කිරීමට හැකි වූයේ කෙසේද?
නායකත්වය: “ක්ලික්හවුස්” ක්‍රියා කරන්නේ කෙසේද යන්න ඔබට සම්පූර්ණයෙන්ම තීරණය කළ නොහැක! මිත්රවරුනි, ප්රශ්න සඳහා විනාඩි 5 ක්!
ඔබගේ ප්රශ්න
ප්‍රේක්ෂකයන්ගෙන් ප්රශ්නය (මෙතැන් සිට Q ලෙස හැඳින්වේ): - සුභ සන්ධ්යාවක්. වාර්තාවට බොහොම ස්තුතියි. මට ප්රශ්න දෙකක් තියෙනවා. මම නිකම්ම පටන් ගන්නම්: රූප සටහන් වල (3, 4, 7...) "Kittenhouse" යන නමේ t අකුරු ගණන බළලුන්ගේ තෘප්තියට බලපාන්නේද?
YN: - ප්රමාණය කුමක්ද?
Z: - ලිපිය ටී. ටී තුනක් ඇත, කොහේ හරි ටී තුනක් පමණ.
YN: - මම එය නිවැරදි කළේ නැද්ද? හොඳයි, ඇත්තෙන්ම එය එසේ කරයි! මේවා විවිධ නිෂ්පාදන - මම මේ කාලය පුරාම ඔබව රැවටුවා. හරි, මම විහිළු කරනවා - ඒක කමක් නැහැ. අහ්, මෙන්න! නැහැ, ඒකම තමයි, මම යතුරු ලියන දෝෂයක් කළා.
Z: - ඔයාට ස්තූතියි. දෙවැනි ප්රශ්නය බරපතළය. මා තේරුම් ගත් පරිදි, ක්ලික්හවුස් හි, බෆර වගු මතකයේ පමණක් ජීවත් වේ, තැටියට බෆර නොකෙරේ, ඒ අනුව ස්ථීර නොවේ.
YN: - ඔව්.
Z: - ඒ සමඟම, ඔබේ සේවාලාභියා තැටියට බෆර කරයි, මෙම ලොගයන් බෙදා හැරීමේ යම් සහතිකයක් ඇඟවුම් කරයි. නමුත් Clickhouse හි මෙය කිසිසේත්ම සහතික නොවේ. ඇපකරය ක්රියාත්මක වන ආකාරය පැහැදිලි කරන්න, කුමක් නිසාද?.. මෙන්න මෙම යාන්ත්‍රණය වඩාත් විස්තරාත්මකව
YN: - ඔව්, න්‍යායාත්මකව මෙහි ප්‍රතිවිරෝධතා නොමැත, මන්ද ක්ලික්හවුස් වැටෙන විට, ඔබට එය සැබවින්ම මිලියන ගණනකින් විවිධ ආකාරවලින් හඳුනාගත හැකිය. Clickhouse බිඳ වැටුණහොත් (එය වැරදි ලෙස අවසන් වුවහොත්), ඔබට දළ වශයෙන් කිවහොත්, ඔබ ලියා ඇති ඔබේ ලොගයෙන් ටිකක් ආපසු ගෙන සියල්ල හොඳින් සිදු වූ මොහොතේ සිට ආරම්භ කළ හැකිය. අපි හිතමු ඔබ විනාඩියක් රිවයින්ඩ් කළා කියලා, එනම් ඔබ විනාඩියකින් සියල්ල ෆ්ලෂ් කර ඇති බව සැලකේ.
Z: - එනම්, "කිටන්හවුස්" කවුළුව දිගු කාලයක් රඳවා තබා ඇති අතර, වැටීමකදී, එය හඳුනාගෙන එය ආපසු හරවා ගත හැකිද?
YN: - නමුත් මෙය න්‍යායික ය. ප්රායෝගිකව, අපි මෙය නොකරන අතර, විශ්වාසනීය බෙදාහැරීම ශුන්යයේ සිට අනන්ත කාලය දක්වා වේ. නමුත් සාමාන්යයෙන් එකක්. කිසියම් හේතුවක් නිසා ක්ලික්හවුස් බිඳවැටීම හෝ සේවාදායකයන් "නැවත පණගැන්වීම" නම්, අපට ටිකක් අහිමි වන බව අපි සෑහීමකට පත්වෙමු. අනෙක් සෑම අවස්ථාවකදීම කිසිවක් සිදු නොවනු ඇත.
Z: - ආයුබෝවන්. ආරම්භයේ සිටම මට පෙනුනේ ඔබ වාර්තාවේ ආරම්භයේ සිටම UDP භාවිතා කරන බවයි. ඔබට http ඇත, ඒ සියල්ල... තවද ඔබ විස්තර කළ බොහෝ ගැටලු, මට වැටහෙන පරිදි, මෙම විශේෂිත විසඳුම නිසා ඇති වූ ඒවා...
YN: - අපි TCP භාවිතා කරන්නේ කුමක්ද?
Z: - අත්යවශ්යයෙන්ම ඔව්.
YN: - නොවේ.
Z: - Fasthttp සමඟ ඔබට ගැටළු ඇති විය, සම්බන්ධතාවය සමඟ ඔබට ගැටළු ඇති විය. ඔබ UDP භාවිතා කළේ නම්, ඔබට යම් කාලයක් ඉතිරි වනු ඇත. හොඳයි, දිගු පණිවිඩ හෝ වෙනත් දෙයක් සමඟ ගැටලු ඇති වනු ඇත ...
YN: - කුමක් සමඟද?
Z: – දිගු පණිවිඩ සහිතව, එය MTU එකට නොගැලපෙන නිසා, වෙනත් දෙයක් ... හොඳයි, ඔවුන්ගේම ගැටළු ඇති විය හැක. ප්රශ්නය වන්නේ: UDP නැත්තේ ඇයි?
YN: - TCP/IP සංවර්ධනය කළ කතුවරුන් මට වඩා බොහෝ දක්ෂ බවත්, පැකට් අනුක්‍රමික කරන්නේ කෙසේදැයි මට වඩා හොඳින් දන්නා බවත් (ඒවා යන පරිදි), ඒ සමඟම යැවීමේ කවුළුව සකසන්න, ජාලය අධික ලෙස පටවන්නේ නැත, කුමක් පිළිබඳව ප්‍රතිපෝෂණ ලබා දෙන්නැයි මම විශ්වාස කරමි. කියවා නැත, අනෙක් පැත්තෙන් ගණන් නොගනී ... මෙම සියලු ගැටළු, මගේ මතය අනුව, UDP හි පවතිනු ඇත, එකම දෙය මා විසින්ම ක්රියාත්මක කිරීම සඳහා සහ බොහෝ දුරට ඉඩ ඇති පරිදි මා දැනටමත් ලියා ඇති ප්‍රමාණයට වඩා වැඩි කේතයක් ලිවීමට මට සිදුවනු ඇත. දුර්වල ලෙස. මම ඇත්තටම C වලින් ලිවීමට කැමති නැත, එහි තබා ...
Z: - පහසුයි! හරි යවන ලද අතර කිසිවක් බලා නොසිටින්න - එය සම්පූර්ණයෙන්ම අසමමිතික වේ. සියල්ල හොඳින් ඇති බවට දැනුම්දීමක් නැවත පැමිණියේය - එයින් අදහස් වන්නේ එය පැමිණි බවයි; එය නොපැමිණියේ නම්, එයින් අදහස් වන්නේ එය නරක බවයි.
YN: - මට දෙකම අවශ්යයි - මට බෙදා හැරීමේ සහතිකයක් සහ බෙදා හැරීමේ සහතිකයක් නොමැතිව දෙකම යැවීමට හැකි විය යුතුය. මේවා වෙනස් අවස්ථා දෙකකි. මට සමහර ලඝු-සටහන් නැති කර නොගැනීමට හෝ හේතුවක් ඇතුව ඒවා නැති කර නොගැනීමට අවශ්යයි.
Z: - මම කාලය නාස්ති නොකරමි. මෙය තවත් සාකච්ඡා කළ යුතුය. ඔයාට ස්තූතියි.
නායකත්වය: - ප්රශ්න ඇත්තේ කාටද - අහසට දෑත්!
Z: - හෙලෝ, මම සාෂා. වාර්තාවේ කොහේ හරි මැද, TCP වලට අමතරව, සූදානම් කළ විසඳුමක් භාවිතා කළ හැකි බවට හැඟීමක් ඇති විය - යම් ආකාරයක කෆ්කා.
YN: - හොඳයි ... මම ඔබට කිව්වා මට අතරමැදි සේවාදායකයන් භාවිතා කිරීමට අවශ්ය නැති බව, මන්ද ... කෆ්කා හි, අපට සත්කාරක දස දහසක් ඇති බව පෙනේ; ඇත්ත වශයෙන්ම, අපට තවත් - සත්කාරක දස දහස් ගණනක් ඇත. කිසිදු ප්‍රොක්සියක් නොමැතිව කෆ්කා සමඟ කිරීම වේදනාකාරී විය හැකිය. ඊට අමතරව, වඩාත්ම වැදගත් දෙය නම්, එය තවමත් "ප්රමාදය" ලබා දෙයි, එය ඔබට තිබිය යුතු අමතර ධාරක ලබා දෙයි. නමුත් මට ඒවා ලබා ගැනීමට අවශ්ය නැත - මට අවශ්යයි ...
Z: "නමුත් අවසානයේ එය එසේ විය."
YN: - නැත, සත්කාරකයින් නොමැත! මේ සියල්ල Clickhouse hosts මත ක්‍රියා කරයි.
Z: - හොඳයි, සහ “කිටන්හවුස්”, එය ප්‍රතිවිරුද්ධයයි - ඔහු ජීවත් වන්නේ කොහේද?
YN: - Clickhouse සත්කාරකයේ, එය තැටියට කිසිවක් ලියන්නේ නැත.
Z: - අපි හිතමු.
නායකත්වය: - ඔබ සෑහීමකට පත්වුනාද? අපි ඔබට වැටුපක් ලබා දිය හැකිද?
Z: - ඔව් ඔබට පුළුවන්. ඇත්ත වශයෙන්ම, එකම දේ ලබා ගැනීම සඳහා අත්වාරු රාශියක් ඇත, සහ දැන් - TCP මාතෘකාව පිළිබඳ පෙර පිළිතුර මගේ මතය අනුව, මෙම තත්වයට පටහැනි වේ. හැම දෙයක්ම මගේ දණින් වැටී අඩු කාලයකින් කළ හැකිව තිබූ බවක් දැනේ.
YN: - තවද මට කෆ්කා භාවිතා කිරීමට අවශ්ය නොවන්නේ ඇයි, මන්ද ක්ලික්හවුස් ටෙලිග්‍රාම් කතාබස් තුළ බොහෝ පැමිණිලි ඇති බැවින්, උදාහරණයක් ලෙස, කෆ්කා වෙතින් පණිවිඩ නැති වූ බව. කෆ්කාගෙන්ම නොව, කෆ්කා සහ ක්ලික්හවුස් අනුකලනය තුළ; හෝ යමක් එහි සම්බන්ධ නොවීය. දළ වශයෙන් කිවහොත්, කෆ්කා සඳහා සේවාදායකයකු ලිවීමට අවශ්ය වනු ඇත. මීට වඩා සරල හෝ විශ්වාසදායක විසඳුමක් තිබිය හැකි යැයි මම නොසිතමි.
Z: - මට කියන්න, ඔබ පෝලිම් හෝ පොදු බස් වර්ගයක් උත්සාහ නොකළේ ඇයි? අසමමුහුර්තතාවයෙන් ඔබට පෝලිම හරහා ලඝු-සටහන් යවා පෝලිම හරහා අසමමුහුර්තව ප්‍රතිචාරය ලබා ගත හැකි බව ඔබ පවසන නිසා?
YN: - කරුණාකර භාවිතා කළ හැකි පෝලිම් මොනවාදැයි යෝජනා කරන්න?
Z: - ඕනෑම, ඒවා පිළිවෙලට ඇති බවට සහතිකයක් නොමැතිව වුවද. යම් ආකාරයක Redis, RMQ ...
YN: - Clickhouse පිටතට ඇද ගන්නා එක් සත්කාරකයක් (සේවාදායක කිහිපයක් යන අර්ථයෙන්) පවා Redis හට එවැනි ඇතුළත් කිරීමේ පරිමාවක් ඇද ගැනීමට නොහැකි වනු ඇතැයි මට හැඟේ. මට මෙය කිසිදු සාක්ෂියක් සමඟ උපස්ථ කළ නොහැක (මම එය මිණුම් සලකුණු කර නැත), නමුත් මට පෙනෙන්නේ රෙඩිස් මෙහි හොඳම විසඳුම නොවන බවයි. ප්‍රතිපත්තිමය වශයෙන්, මෙම පද්ධතිය වැඩිදියුණු කළ පණිවිඩ පෝලිමක් ලෙස සැලකිය හැකිය, නමුත් එය සකස් කර ඇත්තේ "Clickhouse" සඳහා පමණි.
නායකත්වය: - යූරි, බොහොම ස්තුතියි. ප්රශ්න සහ පිළිතුරු මෙතැනින් අවසන් කර ප්රශ්නය ඇසූ අයගෙන් අප පොත දෙන්නේ කාටදැයි කියන්නට මම යෝජනා කරමි.
YN: – ප්රශ්නයක් ඇසූ පළමු පුද්ගලයාට පොතක් දීමට මම කැමතියි.
නායකත්වය: - පුදුමයි! මහා! අපූරුයි! ගොඩාක් ස්තූතියි!
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com