අපි බහු කාල ශ්‍රේණි දත්ත සමුදායන් පරීක්‍ෂා කළ ආකාරය

පසුගිය වසර කිහිපය තුළ, කාල-ශ්‍රේණි දත්ත සමුදායන් පිටස්තර දෙයකින් (විවෘත අධීක්ෂණ පද්ධතිවල (සහ විශේෂිත විසඳුම්වලට බැඳී) හෝ විශාල දත්ත ව්‍යාපෘතිවල භාවිතා වන අතිශයින් විශේෂිත වූ) “පාරිභෝගික නිෂ්පාදනයක්” බවට පත් වී ඇත. රුසියානු සමූහාණ්ඩුවේ භූමිය තුළ, මේ සඳහා Yandex සහ ClickHouse වෙත විශේෂ ස්තුතිය ලබා දිය යුතුය. මෙම අවස්ථාව දක්වා, ඔබට විශාල කාල ශ්‍රේණි දත්ත ප්‍රමාණයක් ගබඩා කිරීමට අවශ්‍ය නම්, ඔබට බිහිසුණු Hadoop තොගයක් ගොඩනඟා එය නඩත්තු කිරීමේ අවශ්‍යතාවය සමඟ එකඟ වීමට හෝ එක් එක් පද්ධතිය සඳහා තනි තනිව ප්‍රොටෝකෝල සමඟ සන්නිවේදනය කිරීමට සිදු විය.

2019 දී TSDB භාවිතා කිරීම වටී යන ලිපියක් එක වාක්‍යයකින් පමණක් සමන්විත වන බව පෙනේ: "ClickHouse භාවිතා කරන්න." නමුත් ... සූක්ෂ්මතා ඇත.

ඇත්ත වශයෙන්ම, ClickHouse සක්‍රීයව සංවර්ධනය වෙමින් පවතී, පරිශීලක පදනම වර්ධනය වෙමින් පවතී, සහ සහයෝගය ඉතා ක්‍රියාකාරී වේ, නමුත් වෙනත්, සමහර විට වඩාත් ඵලදායී/විශ්වසනීය විසඳුම් යටපත් කර ඇති ClickHouse හි මහජන සාර්ථකත්වයේ ප්‍රාණ ඇපකරුවන් බවට අප පත්ව තිබේද?

පසුගිය වසර ආරම්භයේදී, අපි අපේම අධීක්ෂණ පද්ධතිය නැවත සකස් කිරීම ආරම්භ කළ අතර, දත්ත ගබඩා කිරීම සඳහා සුදුසු දත්ත සමුදායක් තෝරාගැනීමේ ප්රශ්නය මතු විය. මෙම තේරීමේ ඉතිහාසය ගැන මට මෙහිදී කතා කිරීමට අවශ්‍යයි.

ගැටලුව ප්රකාශ කිරීම

පළමුවෙන්ම, අවශ්ය පෙරවදනක්. අපට අපගේම අධීක්ෂණ පද්ධතියක් අවශ්‍ය වන්නේ ඇයි සහ එය නිර්මාණය කර ඇත්තේ කෙසේද?

අපි 2008 දී ආධාරක සේවා සැපයීම ආරම්භ කළ අතර, 2010 වන විට පාරිභෝගික යටිතල ව්‍යුහයේ සිදුවන ක්‍රියාවලීන් පිළිබඳ දත්ත එකල පැවති විසඳුම් සමඟ එකතු කිරීම දුෂ්කර වූ බව පැහැදිලි විය (අපි කතා කරන්නේ, දෙවියන් වහන්සේ මට සමාව දෙන්න, පතොක්, සැබික්ස් සහ නැගී එන මිනිරන්).

අපගේ ප්‍රධාන අවශ්‍යතා වූයේ:

• එක් පද්ධතියක් තුළ සේවාදායකයින්ට සහ ඒ සමඟම මධ්‍යගත අනතුරු ඇඟවීමේ කළමනාකරණ පද්ධතියක් තිබීම සඳහා (එකල - දුසිම්, සහ අනාගතයේදී - සිය ගණනක්);
• අනතුරු ඇඟවීමේ පද්ධතිය කළමනාකරණය කිරීමේ නම්යශීලීභාවය (රාජකාරී නිලධාරීන් අතර අනතුරු ඇඟවීම් උත්සන්න කිරීම, උපලේඛනගත කිරීම, දැනුම පදනම);
• ප්‍රස්ථාර ගැඹුරින් විස්තර කිරීමේ හැකියාව (එකල Zabbix විසින් ප්‍රස්ථාර රූප ආකාරයෙන් ඉදිරිපත් කර ඇත);
• දත්ත විශාල ප්‍රමාණයක් (වසරක් හෝ ඊට වැඩි) දිගුකාලීන ගබඩා කිරීම සහ එය ඉක්මනින් ලබා ගැනීමේ හැකියාව.

මෙම ලිපියෙන් අපි අවසාන කරුණ ගැන උනන්දු වෙමු.

ගබඩා කිරීම ගැන කතා කිරීම, අවශ්යතා පහත පරිදි විය:

• පද්ධතිය ඉක්මනින් වැඩ කළ යුතුය;
• පද්ධතියට SQL අතුරු මුහුණතක් තිබීම යෝග්‍ය වේ;
• පද්ධතිය ස්ථායී විය යුතු අතර ක්‍රියාකාරී පරිශීලක පදනමක් සහ සහායක් තිබිය යුතුය (තවදුරටත් සංවර්ධනය කර නොමැති MemcacheDB හෝ MooseFS බෙදාහැරීමේ ගබඩාව වැනි පද්ධති සඳහා සහය දැක්වීමේ අවශ්‍යතාවයට අප මුහුණ දුන් පසු, එහි දෝෂ ලුහුබැඳීම චීන භාෂාවෙන් තබා ඇත: අපගේ ව්‍යාපෘතියට අවශ්‍ය නොවීම සඳහා අපි මෙම කතාව නැවත නැවතත් කරමු);
• CAP ප්‍රමේයයට අනුකූල වීම: Consitency (අවශ්‍ය) - දත්ත යාවත්කාලීන විය යුතුය, අනතුරු ඇඟවීමේ කළමනාකරණ පද්ධතියට නව දත්ත නොලැබීමට සහ සියලු ව්‍යාපෘති සඳහා දත්ත නොපැමිණීම පිළිබඳ ඇඟවීම් නිකුත් කිරීමට අපට අවශ්‍ය නැත; කොටස් ඉවසීම (අවශ්‍යයි) - අපට Split Brain පද්ධතියක් ලබා ගැනීමට අවශ්‍ය නැත; ලබා ගැනීමේ හැකියාව (විවේචනාත්මක නොවේ, සක්‍රීය අනුරුවක් තිබේ නම්) - හදිසි අනතුරකදී කේතය භාවිතයෙන් අපටම උපස්ථ පද්ධතියට මාරු විය හැකිය.

පුදුමයට කරුණක් නම්, එකල MySQL අපට කදිම විසඳුම විය. අපගේ දත්ත ව්‍යුහය අතිශය සරල විය: සේවාදායක හැඳුනුම්පත, කවුන්ටර හැඳුනුම්පත, කාල මුද්‍රාව සහ අගය; උණුසුම් දත්තවල වේගවත් නියැදීම විශාල බෆර සංචිතයක් මගින් සහතික කරන ලද අතර ඓතිහාසික දත්ත නියැදීම SSD මගින් සහතික කරන ලදී.

මේ අනුව, දත්ත සම්පුර්ණයෙන් විදැහුම් කිරීමට පෙර තත්පර 200 ms දක්වා විස්තර සහිතව, අපි නැවුම් සති දෙකක දත්ත නියැදියක් ලබා ගත් අතර, මෙම පද්ධතිය තුළ සෑහෙන කාලයක් ජීවත් විය.

මේ අතර කාලය ගෙවී ගොස් දත්ත ප්‍රමාණය වැඩි විය. 2016 වන විට, දත්ත පරිමාව ටෙරාබයිට් දස ගනනක් කරා ළඟා විය, එය කුලියට ගත් SSD ගබඩා සන්දර්භය තුළ සැලකිය යුතු වියදමක් විය.

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

කෙසේ වෙතත්, සමාගමේ ප්රධාන පද්ධතිය ස්ථාවර ලෙස දිගටම වැඩ කළ අතර, වෙනත් දෙයකට මාරු කිරීම සමඟ අත්හදා බැලීමට මට අවශ්ය නොවීය.

2017 දී, සැන් ජෝස් හි පැවති පර්කෝනා සජීවී සම්මන්ත්‍රණයේදී, ක්ලික්හවුස් සංවර්ධකයින් ප්‍රථම වරට තමන්ව ප්‍රකාශ කළහ. මුලින්ම බැලූ බැල්මට, පද්ධතිය නිෂ්පාදනයට සූදානම් විය (හොඳයි, Yandex.Metrica යනු දැඩි නිෂ්පාදන පද්ධතියකි), සහය වේගවත් හා සරල වූ අතර, වඩාත්ම වැදගත් ලෙස, මෙහෙයුම සරල විය. 2018 සිට අපි සංක්‍රාන්ති ක්‍රියාවලිය ආරම්භ කර ඇත්තෙමු. නමුත් ඒ වන විට, “වැඩිහිටි” සහ කාලය පරීක්ෂා කරන ලද TSDB පද්ධති රාශියක් තිබූ අතර, අපගේ අවශ්‍යතා අනුව Clickhouse සඳහා විකල්ප විසඳුම් නොමැති බව සහතික කර ගැනීම සඳහා සැලකිය යුතු කාලයක් කැප කිරීමට සහ විකල්ප සංසන්දනය කිරීමට අපි තීරණය කළෙමු.

දැනටමත් නිශ්චිතව දක්වා ඇති ගබඩා අවශ්යතා වලට අමතරව, නව ඒවා දර්ශනය වී ඇත:

• නව පද්ධතිය අවම වශයෙන් MySQL හා සමාන දෘඪාංග ප්‍රමාණයකට සමාන කාර්ය සාධනයක් සැපයිය යුතුය;
• නව පද්ධතියේ ගබඩා කිරීම සැලකිය යුතු ලෙස අඩු ඉඩක් ගත යුතුය;
• DBMS තවමත් කළමනාකරණය කිරීමට පහසු විය යුතුය;
• DBMS වෙනස් කිරීමේදී යෙදුම අවම වශයෙන් වෙනස් කිරීමට මට අවශ්‍ය විය.

අපි සලකා බැලීමට පටන් ගත් පද්ධති මොනවාද?

Apache Hive/Apache Impala
පැරණි, යුධ-පරීක්ෂිත Hadoop තොගයක්. අත්යවශ්යයෙන්ම, එය HDFS මත ස්වදේශීය ආකෘතිවල දත්ත ගබඩා කිරීම මත ගොඩනගා ඇති SQL අතුරුමුහුණතකි.

වාසි.

• ස්ථාවර ක්‍රියාකාරිත්වය සමඟ, දත්ත පරිමාණය කිරීම ඉතා පහසුය.
• දත්ත ගබඩා කිරීම සඳහා තීරු විසඳුම් ඇත (අඩු ඉඩක්).
• සම්පත් පවතින විට සමාන්තර කාර්යයන් ඉතා වේගයෙන් ක්‍රියාත්මක කිරීම.

අවාසි

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

කෙසේ වුවද:

පරිගණක සේවාදායක සංඛ්‍යාව පරිමාණය කිරීමෙන් වේගය ලබා ගනී. සරලව කිවහොත්, අපි විශාල සමාගමක් නම්, විශ්ලේෂණ කටයුතුවල නියැලී සිටින අතර, ව්‍යාපාරයට හැකි ඉක්මනින් තොරතුරු එක්රැස් කිරීම (විශාල පරිගණක සම්පත් භාවිතා කිරීමේ වියදමින් වුවද) ඉතා වැදගත් වේ නම්, මෙය අපගේ තේරීම විය හැකිය. නමුත් කාර්යයන් වේගවත් කිරීම සඳහා දෘඩාංග සමූහය ගුණ කිරීමට අපි සූදානම් නොවෙමු.

Druid/Pinot

විශේෂයෙන් TSDB ගැන තවත් බොහෝ දේ ඇත, නමුත් නැවතත්, Hadoop තොගය.

ඇත ClickHouse එදිරිව Druid සහ Pinot හි වාසි සහ අවාසි සංසන්දනය කරන විශිෂ්ට ලිපියක් .

වචන කිහිපයකින්: Druid/Pinot පෙනෙන අවස්ථා වලදී Clickhouse වලට වඩා හොඳයි:

• ඔබට දත්තවල විෂමජාතීය ස්වභාවයක් ඇත (අපගේ නඩුවේදී, අපි වාර්තා කරන්නේ සේවාදායක ප්‍රමිතික වල වේලා මාලා පමණක් වන අතර, ඇත්ත වශයෙන්ම මෙය එක් වගුවකි. නමුත් වෙනත් අවස්ථා තිබිය හැක: උපකරණ කාල ශ්‍රේණිය, ආර්ථික කාල ශ්‍රේණි, ආදිය. එහිම ව්යුහය, එය එකතු කර සකස් කළ යුතුය).
• එපමණක්ද නොව, මෙම දත්ත බොහොමයක් තිබේ.
• කාල ශ්‍රේණි සහිත වගු සහ දත්ත දිස්වී අතුරුදහන් වේ (එනම්, යම් දත්ත කට්ටලයක් පැමිණ, විශ්ලේෂණය කර මකා දමන ලදී).
• දත්ත කොටස් කළ හැකි පැහැදිලි නිර්ණායකයක් නොමැත.

ප්‍රතිවිරුද්ධ අවස්ථා වලදී, ClickHouse වඩා හොඳින් ක්‍රියා කරයි, මෙය අපගේ නඩුවයි.

නිවස ක්ලික් කරන්න

• SQL වැනි
• කළමනාකරණය කිරීමට පහසුය.
• මිනිස්සු කියනවා වැඩ කරනවා කියලා.

පරීක්ෂණ සඳහා කෙටි ලැයිස්තු ගත වේ.

InfluxDB

ClickHouse සඳහා විදේශීය විකල්පයක්. අවාසි අතුරින්: ඉහළ උපයෝගිතා ඇත්තේ වාණිජ අනුවාදයේ පමණි, නමුත් එය සැසඳිය යුතුය.

පරීක්ෂණ සඳහා කෙටි ලැයිස්තු ගත වේ.

කැසන්ඩ්රා

එක් අතකින්, එය එවැනි අධීක්ෂණ පද්ධති මගින් මෙට්‍රික් කාල සටහන් ගබඩා කිරීමට භාවිතා කරන බව අපි දනිමු, උදාහරණයක් ලෙස, සිග්නල්එෆ්එක්ස් හෝ OkMeter. කෙසේ වෙතත්, විශේෂතා තිබේ.

කැසැන්ඩ්‍රා යනු සම්ප්‍රදායික අර්ථයෙන් තීරු දත්ත ගබඩාවක් නොවේ. එය පේළි දසුනක් මෙන් පෙනේ, නමුත් සෑම පේළියකටම වෙනස් තීරු සංඛ්‍යාවක් තිබිය හැකි අතර, තීරු දසුනක් සංවිධානය කිරීම පහසු කරයි. මෙම අර්ථයෙන් ගත් කල, තීරු බිලියන 2 ක සීමාවක් සමඟින්, සමහර දත්ත තීරු (සහ එකම කාල පරාසය) තුළ ගබඩා කළ හැකි බව පැහැදිලිය. උදාහරණයක් ලෙස, MySQL හි තීරු 4096 ක සීමාවක් ඇති අතර ඔබ එය කිරීමට උත්සාහ කළහොත් 1117 කේතය සමඟ දෝෂයක් ඇතිවීම පහසුය.

Cassandra එන්ජිම මාස්ටර් නොමැතිව බෙදා හරින ලද පද්ධතියක විශාල දත්ත ප්‍රමාණයක් ගබඩා කිරීම කෙරෙහි අවධානය යොමු කර ඇති අතර, ඉහත සඳහන් කරන ලද Cassandra CAP ප්‍රමේයය AP ගැන, එනම් දත්ත ලබා ගැනීමේ හැකියාව සහ කොටස් කිරීමට ඇති ප්‍රතිරෝධය පිළිබඳව වැඩි අවධානයක් යොමු කරයි. මේ අනුව, ඔබට මෙම දත්ත සමුදායට ලිවීමට සහ කලාතුරකින් කියවීමට අවශ්‍ය නම් මෙම මෙවලම විශිෂ්ට විය හැකිය. තවද මෙහි "සීතල" ගබඩාවක් ලෙස Cassandra භාවිතා කිරීම තාර්කික ය. එනම්, කලාතුරකින් අවශ්‍ය වන, නමුත් අවශ්‍ය නම් නැවත ලබාගත හැකි ඓතිහාසික දත්ත විශාල ප්‍රමාණයක් ගබඩා කිරීමට දිගුකාලීන, විශ්වාසදායක ස්ථානයක් ලෙසය. එසේ වුවද, සම්පූර්ණත්වය සඳහා, අපි එය ද පරීක්ෂා කරන්නෙමු. නමුත්, මා කලින් කී පරිදි, තෝරාගත් දත්ත සමුදා විසඳුම සඳහා කේතය සක්රියව නැවත ලිවීමට ආශාවක් නැත, එබැවින් අපි එය තරමක් සීමිත ලෙස පරීක්ෂා කරන්නෙමු - දත්ත සමුදා ව්යුහය Cassandra හි විශේෂතා වලට අනුවර්තනය නොකර.

Prometheus

හොඳයි, කුතුහලයෙන්, අපි Prometheus ගබඩාවේ කාර්ය සාධනය පරීක්ෂා කිරීමට තීරණය කළෙමු - අපි වත්මන් විසඳුම්වලට වඩා වේගවත්ද මන්දගාමීද යන්න සහ කොපමණ ප්‍රමාණයකින්ද යන්න තේරුම් ගැනීමට.

පරීක්ෂණ ක්‍රමවේදය සහ ප්‍රතිඵල

එබැවින්, අපි පහත වින්‍යාසයන් 5 තුළ දත්ත සමුදායන් 6 ක් පරීක්‍ෂා කළෙමු: ClickHouse (1 node), ClickHouse (3 නෝඩ් සඳහා බෙදා හරින ලද වගුව), InfluxDB, Mysql 8, Cassandra (3 nodes) සහ Prometheus. පරීක්ෂණ සැලැස්ම පහත පරිදි වේ:

1. සතියක් සඳහා ඓතිහාසික දත්ත උඩුගත කරන්න (දිනකට වටිනාකම් මිලියන 840; මෙට්රික් 208 දහසක්);
2. අපි පටිගත කිරීමේ බරක් උත්පාදනය කරමු (භාර මාදිලි 6 ක් සලකා බලන ලදී, පහත බලන්න);
3. පටිගත කිරීමට සමාන්තරව, අපි ප්‍රස්ථාර සමඟ වැඩ කරන පරිශීලකයෙකුගේ ඉල්ලීම් අනුකරණය කරමින් වරින් වර තේරීම් කරන්නෙමු. දේවල් ඕනෑවට වඩා සංකීර්ණ නොකිරීමට, අපි සතියක් සඳහා ප්‍රමිතික 10 ක් සඳහා දත්ත තෝරා ගත්තෙමු (එය හරියටම CPU ප්‍රස්ථාරයේ කොපමණ තිබේද යන්නයි).

සෑම තත්පර 15 කට වරක් එක් එක් මෙට්‍රික් වෙත අගයන් යවන අපගේ අධීක්ෂණ නියෝජිතයාගේ හැසිරීම අනුකරණය කිරීමෙන් අපි පූරණය කරමු. ඒ අතරම, අපි වෙනස් කිරීමට උනන්දු වෙමු:

• දත්ත ලියා ඇති මුළු මිනුම් සංඛ්‍යාව;
• එක් මෙට්රික් එකකට අගයන් යැවීම සඳහා පරතරය;
• කණ්ඩායම් ප්රමාණය.

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

එසේම, ලැබුණු දත්ත අර්ථකථනය කරන්නේ කෙසේදැයි වඩා හොඳින් අවබෝධ කර ගැනීම සඳහා, අපි මෙට්‍රික් පොකුරක් යැවීම පමණක් නොව, ප්‍රමිතික සේවාදායක ලෙස සංවිධානය කර ඇත - එක් සේවාදායකයකට මෙට්‍රික් 125 ක් යැයි සිතමු. මෙහිදී සේවාදායකය යනු හුදෙක් අතථ්‍ය වස්තුවකි - උදාහරණයක් ලෙස, මෙට්‍රික් 10000 ක් සේවාදායක 80 කට පමණ අනුරූප වන බව තේරුම් ගැනීමට පමණි.

මෙන්න, මේ සියල්ල සැලකිල්ලට ගනිමින්, අපගේ දත්ත සමුදාය ලිවීමේ පැටවුම් මාතයන් 6 වේ:

මෙහි කරුණු දෙකක් තිබේ. පළමුව, කැසැන්ඩ්‍රා සඳහා මෙම කාණ්ඩ ප්‍රමාණය ඉතා විශාල විය, එහිදී අපි 50 හෝ 100 අගයන් භාවිතා කළෙමු. දෙවනුව, ප්‍රොමිතියස් දැඩි ලෙස අදින්න ප්‍රකාරයේදී ක්‍රියා කරන බැවින්, එනම්. එයම ගොස් ප්‍රමිතික ප්‍රභවයන්ගෙන් දත්ත රැස් කරයි (සහ pushgateway, නම තිබියදීත්, මූලික වශයෙන් තත්වය වෙනස් නොකරයි), අනුරූප බර ක්‍රියාත්මක කළේ ස්ථිතික වින්‍යාස සංයෝජනයක් භාවිතා කරමිනි.

පරීක්ෂණ ප්රතිඵල පහත පරිදි වේ:

සඳහන් කළ යුතු දේ: Prometheus වෙතින් අතිශය වේගවත් සාම්පල, Cassandra වෙතින් දරුණු මන්දගාමී සාම්පල, InfluxDB වෙතින් පිළිගත නොහැකි මන්දගාමී සාම්පල; පටිගත කිරීමේ වේගය අනුව, ClickHouse සෑම කෙනෙකුම දිනා ගත් අතර, Prometheus තරඟයට සහභාගී නොවේ, මන්ද එය ඇතුල් කිරීම් සිදු කරන අතර අපි කිසිවක් මනින්නේ නැත.

එහි ප්රතිඵලයක් ලෙස,: ClickHouse සහ InfluxDB තමන් හොඳම ඒවා බව පෙන්වූ නමුත් Influx වෙතින් පොකුරක් ගොඩනගා ගත හැක්කේ මුදල් වැය වන ව්‍යවසාය අනුවාදයේ පදනම මත පමණක් වන අතර ClickHouse කිසිවක් වැය නොවන අතර රුසියාවේ නිෂ්පාදනය කර ඇත. ඇමරිකා එක්සත් ජනපදයේ තේරීම බොහෝ විට inInfluxDB සඳහා වන අතර අපේ රටේ එය ClickHouse සඳහා පක්ෂව වීම තර්කානුකූල ය.

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