Yandex විසින් නිර්මාණය කරන ලද සබැඳි විශ්ලේෂණ විමසුම් සැකසුම් (OLAP) සඳහා විවෘත මූලාශ්‍ර තීරු දත්ත සමුදා කළමනාකරණ පද්ධතියකි. එය සැබවින්ම විශාල දත්ත ප්‍රමාණයක් ගබඩා කිරීම සඳහා Yandex, CloudFlare, VK.com, Badoo සහ ලොව පුරා අනෙකුත් සේවාවන් විසින් භාවිතා කරනු ලැබේ (තත්පරයට පේළි දහස් ගණනක් හෝ තැටියේ ගබඩා කර ඇති දත්ත පෙටාබයිට් ඇතුළු කිරීම).
MySQL, Postgres, MS SQL Server වැනි සාමාන්‍ය, “string” DBMS තුළ, දත්ත ගබඩා කර ඇත්තේ පහත අනුපිළිවෙලට ය:
මෙම අවස්ථාවේදී, එක් පේළියකට අදාළ අගයන් භෞතිකව අසල ගබඩා කර ඇත. තීරු DBMS වල, විවිධ තීරු වල අගයන් වෙන වෙනම ගබඩා කර ඇති අතර, එක් තීරුවක දත්ත එකට ගබඩා කර ඇත:
තීරු DBMS සඳහා උදාහරණ වන්නේ Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+, kd.
තැපැල් යොමු කරන්නා සමාගම වාර්තා කිරීම සඳහා Clickhouse භාවිතා කිරීම 2018 දී ආරම්භ කළ අතර එහි සරල බව, පරිමාණය, SQL සහය සහ වේගය පිළිබඳව මහත් සේ පැහැදී සිටියේය. මෙම DBMS හි වේගය මැජික් මත මායිම් විය.
පහසුවෙන්
ක්ලික්හවුස් එක තනි විධානයකින් උබුන්ටු මත ස්ථාපනය කර ඇත. ඔබ SQL දන්නේ නම්, ඔබට වහාම ඔබගේ අවශ්‍යතා සඳහා Clickhouse භාවිතා කිරීම ආරම්භ කළ හැක. කෙසේ වෙතත්, මෙයින් අදහස් කරන්නේ ඔබට MySQL හි “show create table” කළ හැකි බවත්, Clickhouse හි SQL පිටපත් කර ඇලවිය හැකි බවත් නොවේ.
MySQL හා සසඳන විට, වගු ක්‍රම නිර්වචනවල වැදගත් දත්ත ආකාරයේ වෙනස්කම් ඇත, එබැවින් ඔබට තවමත් වගු යෝජනා ක්‍රම නිර්වචන වෙනස් කිරීමට සහ සුවපහසු වීමට වගු එන්ජින් ඉගෙන ගැනීමට යම් කාලයක් අවශ්‍ය වනු ඇත.
කිසිදු අමතර මෘදුකාංගයක් නොමැතිව Clickhouse ඉතා හොඳින් ක්‍රියා කරයි, නමුත් ඔබට අනුකරණය භාවිතා කිරීමට අවශ්‍ය නම්, ඔබට ZooKeeper ස්ථාපනය කිරීමට අවශ්‍ය වනු ඇත. විමසුම් කාර්ය සාධන විශ්ලේෂණය විශිෂ්ට ප්රතිඵල පෙන්වයි - පද්ධති වගු සියලු තොරතුරු අඩංගු වන අතර, පැරණි සහ නීරස SQL භාවිතයෙන් සියලු දත්ත ලබා ගත හැක.
ඵලදායිතාව
- සර්වර් වින්‍යාසය මත Clickhouse සහ Vertica සහ MySQL සමඟ සැසඳීම්: Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz සොකට් දෙකක්; 128 GiB RAM; md RAID-5 8 6TB SATA HDD මත, ext4.
- Clickhouse සහ Amazon RedShift වලාකුළු ආචයනය සංසන්දනය කිරීම.
- බ්ලොග් උපුටා ගැනීම් :
ClickHouse දත්ත සමුදාය ඉතා සරල සැලසුමක් ඇත - පොකුරේ ඇති සියලුම නෝඩ් එකම ක්‍රියාකාරීත්වයක් ඇති අතර සම්බන්ධීකරණය සඳහා ZooKeeper පමණක් භාවිතා කරයි. අපි නෝඩ් කිහිපයක කුඩා පොකුරක් ගොඩනඟා පරීක්ෂණ සිදු කළ අතර, එම කාලය තුළ පද්ධතියට තරමක් ආකර්ෂණීය කාර්ය සාධනයක් ඇති බව අපට පෙනී ගියේය, එය විශ්ලේෂණාත්මක DBMS මිණුම් සලකුණු වල ප්‍රකාශිත වාසි වලට අනුරූප වේ. ClickHouse පිටුපස ඇති සංකල්පය දෙස සමීපව බැලීමට අපි තීරණය කළෙමු. පර්යේෂණ සඳහා පළමු බාධාව වූයේ මෙවලම් නොමැතිකම සහ කුඩා ClickHouse ප්‍රජාවයි, එබැවින් අපි එය ක්‍රියා කරන ආකාරය තේරුම් ගැනීමට මෙම DBMS හි සැලසුම පිළිබඳව සොයා බැලුවෙමු.
ClickHouse එය හුදෙක් දත්ත සමුදායක් වන බැවින් Kafka වෙතින් සෘජුවම දත්ත ලබා ගැනීමට සහාය නොදක්වයි, එබැවින් අපි Go හි අපගේම ඇඩැප්ටර සේවාව ලිව්වෙමු. එය Kafka වෙතින් Cap'n Proto කේතනය කළ පණිවිඩ කියවා, ඒවා TSV බවට පරිවර්තනය කර HTTP අතුරුමුහුණත හරහා කාණ්ඩ වශයෙන් ClickHouse වෙත ඇතුල් කරන ලදී. කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා ක්ලික්හවුස්ගේම අතුරු මුහුණත සමඟ එක්ව Go පුස්තකාලය භාවිතා කිරීමට අපි පසුව මෙම සේවාව නැවත ලිව්වෙමු. පැකට් ලැබීමේ ක්‍රියාකාරිත්වය තක්සේරු කිරීමේදී, අපි වැදගත් දෙයක් සොයා ගත්තෙමු - ක්ලික්හවුස් සඳහා මෙම කාර්ය සාධනය පැකට්ටුවේ ප්‍රමාණය මත, එනම් එකවර ඇතුළත් කළ පේළි ගණන මත දැඩි ලෙස රඳා පවතින බව පෙනී ගියේය. මෙය සිදුවන්නේ මන්දැයි තේරුම් ගැනීමට, අපි ClickHouse දත්ත ගබඩා කරන්නේ කෙසේදැයි සොයා බැලුවා.
ClickHouse විසින් දත්ත ගබඩා කිරීම සඳහා භාවිතා කරන ප්‍රධාන එන්ජිම, නැතහොත් වගු එන්ජින් පවුල, MergeTree වේ. මෙම එන්ජිම Google BigTable හෝ Apache Cassandra හි භාවිතා වන LSM ඇල්ගොරිතමයට සංකල්පමය වශයෙන් සමාන වේ, නමුත් අතරමැදි මතක වගුවක් තැනීමෙන් වළකින අතර දත්ත කෙලින්ම තැටියට ලියයි. ඇතුළු කරන ලද සෑම පැකේජයක්ම ප්‍රාථමික යතුරෙන් පමණක් වර්ග කර, සම්පීඩනය කර, තැටියට ලියා ඛණ්ඩයක් සාදන බැවින්, මෙය එයට විශිෂ්ට ලිවීමේ ප්‍රතිදානයක් ලබා දෙයි.
මතක වගුවක් හෝ දත්තවල “නැවුම් බව” පිළිබඳ කිසියම් සංකල්පයක් නොමැති වීමෙන් අදහස් වන්නේ ඒවා එක් කළ හැක්කේ ඒවා පමණක් බවයි; පද්ධතිය වෙනස් කිරීමට හෝ මකා දැමීමට සහාය නොදක්වයි. දැනට, දත්ත මැකීමට ඇති එකම ක්‍රමය වන්නේ එය කැලැන්ඩර මාසය වන විට මකා දැමීමයි, මන්ද ඛණ්ඩ කිසි විටෙකත් මාසයක සීමාව ඉක්මවා නොයන බැවිනි. ClickHouse කණ්ඩායම මෙම විශේෂාංගය අභිරුචිකරණය කිරීමට සක්‍රියව ක්‍රියා කරයි. අනෙක් අතට, එය කොටස් ලිවීම සහ ඒකාබද්ධ කිරීම මතභේදයකින් තොරව සිදු කරයි, එබැවින් I/O හෝ හර සන්තෘප්තිය සිදුවන තෙක් සමගාමී ඇතුළු කිරීම් ගණන සමඟ රේඛීයව ප්‍රතිදාන පරිමාණයන් ලබා ගන්න.
කෙසේ වෙතත්, මෙම පද්ධතිය කුඩා පැකට් සඳහා සුදුසු නොවන බව ද අදහස් වේ, එබැවින් බෆරින් සඳහා Kafka සේවා සහ ඇතුල් කිරීම් භාවිතා වේ. මීළඟට, පසුබිමේ ඇති ClickHouse අඛණ්ඩව කොටස් ඒකාබද්ධ කිරීම සිදු කරයි, එවිට බොහෝ කුඩා තොරතුරු ඒකාබද්ධ වී වැඩි වාර ගණනක් වාර්තා කරනු ඇත, එමඟින් පටිගත කිරීමේ තීව්‍රතාවය වැඩි වේ. කෙසේ වෙතත්, බොහෝ නොබැඳි කොටස් ඒකාබද්ධ කිරීම දිගටම පවතින තාක් කල් ඇතුළු කිරීම් ආක්‍රමණශීලී තෙරපීමකට තුඩු දෙනු ඇත. තත්‍ය කාලීන ආග්‍රහණය සහ ශරීරගත කිරීමේ ක්‍රියාකාරීත්වය අතර ඇති හොඳම සම්මුතිය නම් තත්පරයකට සීමිත ඇතුළු කිරීම් සංඛ්‍යාවක් මේසයට ඇතුළු කිරීම බව අපි සොයාගෙන ඇත.
වගු කියවීමේ කාර්ය සාධනය සඳහා යතුර වන්නේ සුචිගත කිරීම සහ තැටියේ දත්ත පිහිටීමයි. සැකසීම කෙතරම් වේගවත් වුවත්, එන්ජිමට තැටියෙන් ටෙරාබයිට් දත්ත ස්කෑන් කිරීමට අවශ්‍ය වූ විට සහ එයින් කොටසක් පමණක් භාවිතා කිරීමට අවශ්‍ය වූ විට, එය කාලය ගතවනු ඇත. ClickHouse යනු තීරු ගබඩාවකි, එබැවින් සෑම කොටසකම එක් එක් පේළිය සඳහා වර්ග කළ අගයන් සහිත එක් එක් තීරු (තීරු) සඳහා ගොනුවක් අඩංගු වේ. මේ ආකාරයෙන්, විමසුමෙන් අතුරුදහන් වූ සම්පූර්ණ තීරු පළමුව මඟ හැරිය හැක, පසුව දෛශික ක්‍රියාත්මක කිරීම සමඟ සමාන්තරව බහු සෛල සැකසිය හැක. සම්පූර්ණ ස්කෑන් කිරීම වැළැක්වීම සඳහා, සෑම කොටසකටම කුඩා දර්ශක ගොනුවක් ඇත.
සියලුම තීරු "ප්‍රාථමික යතුර" මගින් වර්ග කර ඇති බැවින්, ඉතා විශාල වගු සඳහා පවා මතකයේ තබා ගැනීමට හැකි වන පරිදි දර්ශක ගොනුවේ සෑම Nවන පේළියේම ලේබල (අල්ලාගත් පේළි) පමණක් අඩංගු වේ. උදාහරණයක් ලෙස, ඔබට පෙරනිමි සැකසුම් "සෑම 8192 වැනි පේළියක්ම සලකුණු කරන්න", ඉන්පසු ට්‍රිලියන 1ක් සහිත වගුවක "සුළු" සුචිගත කිරීම සඳහා සැකසිය හැක. මතකයට පහසුවෙන් ගැළපෙන රේඛා සඳහා ගත වන්නේ අක්ෂර 122ක් පමණි.
පද්ධති සංවර්ධනය
Clickhouse හි සංවර්ධනය සහ වැඩිදියුණු කිරීම සොයා ගත හැක සහ "වැඩෙන" ක්රියාවලිය ආකර්ෂණීය වේගයකින් සිදුවන බවට වග බලා ගන්න.
ජනප්‍රියත්වය
Clickhouse හි ජනප්‍රියත්වය ඝාතීය ලෙස වර්ධනය වන බව පෙනේ, විශේෂයෙන්ම රුසියානු භාෂාව කතා කරන ප්‍රජාව තුළ. පසුගිය වසරේ ඉහළ බර 2018 සමුළුව (මොස්කව්, නොවැම්බර් 8-9, 2018) පෙන්නුම් කළේ vk.com සහ Badoo වැනි රාක්ෂයන් ක්ලික්හවුස් භාවිතා කරන බවත්, ඔවුන් දස දහස් ගණනක සේවාදායකයන්ගෙන් එකවර දත්ත (උදාහරණයක් ලෙස ලොග්) ඇතුළත් කරන බවත්ය. විනාඩි 40ක වීඩියෝ එකකින් . ද්‍රව්‍ය සමඟ වැඩ කිරීමේ පහසුව සඳහා අපි ඉක්මනින් පිටපත Habr මත පළ කරන්නෙමු.
අයදුම්පත්
යම් කාලයක් පර්යේෂණ කිරීමෙන් පසු, MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot සහ වැනි අනෙකුත් වඩාත් සාම්ප්‍රදායික සහ ජනප්‍රිය විසඳුම් ප්‍රයෝජනවත් විය හැකි හෝ සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය කළ හැකි ක්ෂේත්‍ර ඇති බව මම සිතමි. ඩ්රූඩ්. ඉහත DBMS නවීකරණය කිරීමට හෝ සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය කිරීමට ClickHouse භාවිතා කිරීම පිළිබඳ විස්තර පහත විස්තර කරයි.
MySQL සහ PostgreSQL හි හැකියාවන් පුළුල් කිරීම
මෑතකදී අපි MySQL අපගේ පුවත් පත්‍රිකා වේදිකාව සඳහා ClickHouse සමඟ අර්ධ වශයෙන් ප්‍රතිස්ථාපනය කළෙමු . ගැටලුව වූයේ MySQL, දුර්වල සැලසුමක් හේතුවෙන්, එවන ලද සෑම විද්‍යුත් තැපෑලක් සහ එම විද්‍යුත් තැපෑලේ ඇති සෑම සබැඳියක්ම base64 hash එකකින් ලොග් කරමින් විශාල MySQL වගුවක් (email_stats) නිර්මාණය කිරීමයි. සේවා ග්‍රාහකයින්ට ඊමේල් මිලියන 10 ක් පමණක් යැවීමෙන් පසු, මෙම වගුව 150 GB ගොනු ඉඩක් ලබා ගත් අතර MySQL සරල විමසුම් මත “මෝඩ” වීමට පටන් ගත්තේය. ගොනු අවකාශයේ ගැටලුව විසඳීම සඳහා, අපි InnoDB වගු සම්පීඩනය සාර්ථකව භාවිතා කළ අතර එය 4 ගුණයකින් අඩු කළෙමු. කෙසේ වෙතත්, ඉතිහාසය කියවීම සඳහා MySQL හි මිලියන 20-30 කට වඩා වැඩි විද්‍යුත් තැපැල් ගබඩා කිරීම තවමත් තේරුමක් නැත, මන්ද කිසියම් හේතුවක් නිසා සම්පූර්ණ ස්කෑන් ප්‍රතිඵලයක් swap හි සිදු කිරීමට අවශ්‍ය ඕනෑම සරල විමසුමකට සහ I ගොඩක් /O පැටවීම, ඒ අනුව අපට නිතරම Zabbix වෙතින් අනතුරු ඇඟවීම් ලැබුණි.
Clickhouse දත්ත පරිමාව දළ වශයෙන් අඩු කරන සම්පීඩන ඇල්ගොරිතම දෙකක් භාවිතා කරයි , නමුත් මෙම විශේෂිත අවස්ථාවෙහිදී දත්ත විශේෂයෙන් "සම්පීඩනය" විය.
ELK ප්‍රතිස්ථාපනය කිරීම
මගේම අත්දැකීම් මත පදනම්ව, ELK තොගයට (ElasticSearch, Logstash සහ Kibana, මෙම විශේෂිත අවස්ථාවෙහි ElasticSearch) ලොග් ගබඩා කිරීමට අවශ්‍ය ප්‍රමාණයට වඩා බොහෝ සම්පත් ක්‍රියාත්මක කිරීමට අවශ්‍ය වේ. ඔබට හොඳ සම්පූර්ණ පෙළ ලොග් සෙවීමක් අවශ්‍ය නම් ElasticSearch යනු විශිෂ්ට එන්ජිමකි (එය ඔබට සැබවින්ම අවශ්‍ය යැයි මම නොසිතමි), නමුත් එය සත්‍ය සම්මත ලොග් එන්ජිම බවට පත්ව ඇත්තේ මන්දැයි මම කල්පනා කරමි. Logstash සමඟ ඒකාබද්ධ වූ එහි ingest කාර්ය සාධනය තරමක් සැහැල්ලු බරක් යටතේ පවා අපට ගැටළු ඇති කළ අතර වැඩි වැඩියෙන් RAM සහ තැටි ඉඩ එකතු කිරීමට අපට අවශ්‍ය විය. දත්ත සමුදායක් ලෙස, Clickhouse පහත හේතූන් මත ElasticSearch වලට වඩා හොඳය:
- SQL උපභාෂා සහාය;
- ගබඩා කළ දත්ත සම්පීඩනය කිරීමේ හොඳම මට්ටම;
- සම්පූර්ණ පෙළ සෙවීම් වෙනුවට Regex නිත්‍ය ප්‍රකාශන සෙවීම් සඳහා සහාය;
- වැඩි දියුණු කළ විමසුම් කාලසටහන් සහ ඉහළ සමස්ත කාර්ය සාධනය.
දැනට, ClickHouse ELK සමඟ සංසන්දනය කිරීමේදී පැන නගින විශාලතම ගැටළුව වන්නේ ලොග් උඩුගත කිරීම සඳහා විසඳුම් නොමැතිකම මෙන්ම මාතෘකාව පිළිබඳ ලියකියවිලි සහ නිබන්ධන නොමැතිකමයි. එපමණක් නොව, සෑම පරිශීලකයෙකුටම ඩිජිටල් සාගර අත්පොත භාවිතයෙන් ELK වින්‍යාසගත කළ හැකිය, එය එවැනි තාක්ෂණයන් වේගයෙන් ක්‍රියාත්මක කිරීම සඳහා ඉතා වැදගත් වේ. දත්ත සමුදා එන්ජිමක් ඇත, නමුත් ClickHouse සඳහා තවමත් Filebeat නොමැත. ඔව්, ඒක තියෙනවා සහ ලොග් සමඟ වැඩ කිරීම සඳහා පද්ධතියක් , මෙවලමක් තිබේ ClickHouse වෙත ලොග් ගොනු දත්ත ඇතුලත් කිරීමට, නමුත් මේ සියල්ලට වැඩි කාලයක් ගතවේ. කෙසේ වෙතත්, ClickHouse තවමත් එහි සරල බව නිසා ප්‍රමුඛයා වේ, එබැවින් ආරම්භකයින්ට පවා එය පහසුවෙන් ස්ථාපනය කර විනාඩි 10 කින් එය සම්පූර්ණයෙන්ම ක්‍රියාකාරීව භාවිතා කිරීමට පටන් ගත හැකිය.
අවම විසඳුම් වලට ප්‍රිය කරමින්, මම Kafka භාවිතා කිරීමෙන් වැළකී සිටීමට උත්සාහ කරන අතරතුර ClickHouse සමඟින් ඉතා අඩු මතකයක් සහිත ලොග නැව්ගත කිරීමේ මෙවලමක් වන FluentBit භාවිතා කිරීමට උත්සාහ කළෙමි. කෙසේ වෙතත්, වැනි සුළු නොගැලපීම් ආමන්ත්‍රණය කළ යුතුය මෙයට පෙර FluentBit සිට ClickHouse වෙත දත්ත පරිවර්තනය කරන ප්‍රොක්සි ස්තරය නොමැතිව කළ හැක.
විකල්පයක් ලෙස, Kibana ClickHouse පසුබිමක් ලෙස භාවිතා කළ හැක . මට වැටහෙන ආකාරයට, මෙය විශාල දත්ත ලක්ෂ්‍ය සංඛ්‍යාවක් ලබා දීමේදී, විශේෂයෙන්ම Grafana හි පැරණි අනුවාද සමඟ කාර්ය සාධන ගැටළු ඇති කළ හැක. අපි තවම Qwintry හි මෙය උත්සාහ කර නැත, නමුත් මේ පිළිබඳ පැමිණිලි Telegram හි ClickHouse සහාය නාලිකාවේ විටින් විට දිස්වේ.
Google Big Query සහ Amazon RedShift ආදේශ කිරීම (විශාල සමාගම් සඳහා විසඳුම)
BigQuery සඳහා සුදුසුම භාවිත අවස්ථාව වන්නේ JSON දත්ත 1 TB පූරණය කර එය මත විශ්ලේෂණාත්මක විමසුම් ධාවනය කිරීමයි. Big Query යනු විශාලනය අධිතක්සේරු කළ නොහැකි විශිෂ්ට නිෂ්පාදනයකි. මෙය ClickHouse වලට වඩා සංකීර්ණ මෘදුකාංගයක් වන අතර එය අභ්‍යන්තර පොකුරක් මත ක්‍රියා කරයි, නමුත් සේවාලාභියාගේ දෘෂ්ටි කෝණයෙන් එය ClickHouse සමඟ බොහෝ පොදු වේ. ඔබ SELECT එකකට ගෙවීම ආරම්භ කළ පසු BigQuery ඉක්මනින් මිල අධික විය හැක, එබැවින් එය එහි සියලු වාසි සහ අවාසි සහිත සැබෑ SaaS විසඳුමකි.
ඔබ පරිගණකමය වශයෙන් මිල අධික විමසුම් රාශියක් ක්‍රියාත්මක කරන විට ClickHouse හොඳම තේරීම වේ. ඔබ දිනපතා ක්‍රියාත්මක වන SELECT විමසුම් වැඩි වන තරමට, Big Query වෙනුවට ClickHouse සමඟ ප්‍රතිස්ථාපනය කිරීම අර්ථවත් කරයි, මන්ද එවැනි ප්‍රතිස්ථාපනයක් මඟින් ටෙරාබයිට් ගණනක දත්ත සැකසෙන විට ඔබට ඩොලර් දහස් ගණනක් ඉතිරි කර ගත හැක. ගබඩා කළ දත්ත සඳහා මෙය අදාළ නොවේ, එය Big Query හි සැකසීමට බෙහෙවින් ලාභදායී වේ.
Altinity සම-නිර්මාතෘ ඇලෙක්සැන්ඩර් සයිට්සෙව්ගේ ලිපියක එවැනි DBMS සංක්‍රමණයක ප්‍රතිලාභ ගැන කතා කරයි.
TimescaleDB ආදේශනය
TimescaleDB යනු PostgreSQL දිගුවක් වන අතර එය සාමාන්‍ය දත්ත ගබඩාවක කාල ශ්‍රේණි සමඟ වැඩ කිරීම ප්‍රශස්ත කරයි (, ).
ClickHouse කාල ශ්‍රේණියේ බරපතල තරඟකරුවෙකු නොව, තීරු ව්‍යුහය සහ දෛශික විමසුම් ක්‍රියාත්මක කිරීම වුවද, විශ්ලේෂණාත්මක විමසුම් සැකසීමේ බොහෝ අවස්ථාවන්හිදී එය TimescaleDB ට වඩා වේගවත් වේ. ඒ අතරම, ClickHouse වෙතින් කණ්ඩායම් දත්ත ලබා ගැනීමේ කාර්ය සාධනය ආසන්න වශයෙන් 3 ගුණයකින් වැඩි වන අතර, එය 20 ගුණයක අඩු තැටි ඉඩක් භාවිතා කරයි, එය ඓතිහාසික දත්ත විශාල ප්‍රමාණයක් සැකසීම සඳහා සැබවින්ම වැදගත් වේ: .
ClickHouse මෙන් නොව, TimescaleDB හි යම් තැටි ඉඩක් ඉතිරි කර ගැනීමට ඇති එකම මාර්ගය වන්නේ ZFS හෝ සමාන ගොනු පද්ධති භාවිතා කිරීමයි.
ClickHouse වෙත ඉදිරි යාවත්කාලීනයන් ඩෙල්ටා සම්පීඩනය හඳුන්වා දෙනු ඇත, එය කාල ශ්‍රේණි දත්ත සැකසීමට සහ ගබඩා කිරීමට එය වඩාත් සුදුසු කරයි. පහත සඳහන් අවස්ථා වලදී හිස් ClickHouse වලට වඩා TimescaleDB හොඳ තේරීමක් විය හැක:
- ඉතා කුඩා RAM සහිත කුඩා ස්ථාපනයන් (<3 GB);
- ඔබට විශාල කොටස් වලට බෆර් කිරීමට අවශ්‍ය නොවන කුඩා ඇතුළු කිරීම් විශාල සංඛ්‍යාවක්;
- වඩා හොඳ අනුකූලතාව, ඒකාකාරිත්වය සහ ACID අවශ්‍යතා;
- PostGIS සහාය;
- Timescale DB යනු අත්‍යවශ්‍යයෙන්ම PostgreSQL වන බැවින්, පවතින PostgreSQL වගු සමඟ සම්බන්ධ වීම.
Hadoop සහ MapReduce පද්ධති සමඟ තරඟය
Hadoop සහ අනෙකුත් MapReduce නිෂ්පාදන සංකීර්ණ ගණනය කිරීම් රාශියක් සිදු කළ හැකි නමුත් ඒවා විශාල ප්‍රමාදයන් සමඟ ක්‍රියාත්මක වීමට නැඹුරු වේ.ClickHouse ටෙරාබයිට් දත්ත සැකසීමෙන් සහ ක්ෂණිකව ප්රතිඵල ලබා දීමෙන් මෙම ගැටලුව විසඳයි. මේ අනුව, දත්ත විද්‍යාඥයින්ට උනන්දුවක් දැක්විය යුතු වේගවත්, අන්තර්ක්‍රියාකාරී විශ්ලේෂණ පර්යේෂණ සිදුකිරීමේදී ClickHouse වඩාත් ඵලදායී වේ.
Pinot සහ Druid සමඟ තරඟය
ClickHouse හි සමීපතම තරඟකරුවන් වන්නේ තීරු, රේඛීයව පරිමාණය කළ හැකි විවෘත කේත නිෂ්පාදන Pinot සහ Druid වේ. මෙම පද්ධති සංසන්දනය කරන විශිෂ්ට කෘතියක් ලිපියේ පළ කර ඇත 1 පෙබරවාරි 2018 දිනැති
මෙම ලිපිය යාවත්කාලීන කිරීම අවශ්‍ය වේ - එය පවසන්නේ ClickHouse යාවත්කාලීන සහ DELETE මෙහෙයුම් සඳහා සහය නොදක්වන බවයි, එය නවතම අනුවාද සඳහා සම්පූර්ණයෙන්ම සත්‍ය නොවේ.
මෙම දත්ත සමුදායන් සම්බන්ධයෙන් අපට එතරම් අත්දැකීම් නොමැත, නමුත් Druid සහ Pinot ධාවනය කිරීමට අවශ්‍ය යටිතල පහසුකම්වල සංකීර්ණත්වයට මම ඇත්තෙන්ම කැමති නැත - එය සෑම පැත්තකින්ම ජාවා වලින් වට වූ චලනය වන කොටස් සමූහයකි.
Druid සහ Pinot යනු Apache incubator ව්‍යාපෘති වන අතර, එහි ප්‍රගතිය Apache විසින් එහි GitHub ව්‍යාපෘති පිටුවල විස්තරාත්මකව ආවරණය කර ඇත. Pinot 2018 ඔක්තෝම්බර් මාසයේදී ඉන්කියුබේටරයේ පෙනී සිටි අතර Druid උපත ලැබුවේ මාස 8 කට පෙර - පෙබරවාරි මාසයේදීය.
AFS ක්‍රියා කරන ආකාරය පිළිබඳ තොරතුරු නොමැතිකම මට සමහර, සමහර විට මෝඩ ප්‍රශ්න මතු කරයි. Apache පදනම Druid වෙත වඩාත් හිතකර බව Pinot කතුවරුන් දුටුවාදැයි මම කල්පනා කරමි, සහ තරඟකරු කෙරෙහි මෙම ආකල්පය ඊර්ෂ්‍යාවේ හැඟීමක් ඇති කළේද? හිටපු අයගේ ආධාරකරුවන් හදිසියේ දෙවැන්න ගැන උනන්දු වුවහොත් Druid ගේ සංවර්ධනය මන්දගාමී වී පිනොට්ගේ සංවර්ධනය වේගවත් වේවිද?
ClickHouse හි අවාසි
නොමේරූ බව: පැහැදිලිවම, මෙය තවමත් නීරස තාක්ෂණයක් නොවේ, නමුත් ඕනෑම අවස්ථාවක, වෙනත් තීරු DBMS වල මෙවැනි කිසිවක් නිරීක්ෂණය නොකෙරේ.
කුඩා ඇතුළු කිරීම් ඉහළ වේගයකින් හොඳින් ක්‍රියා නොකරයි: එක් එක් පේළියේ ඇති තීරු ගණනට සමානුපාතිකව කුඩා ඇතුළු කිරීම් වල ක්‍රියාකාරිත්වය පිරිහෙන බැවින් ඇතුළු කිරීම් විශාල කැබලිවලට බෙදිය යුතුය. ClickHouse තැටියේ දත්ත ගබඩා කරන්නේ මෙලෙසයි - සෑම තීරුවක්ම ගොනු 1ක් හෝ වැඩි ගණනක් නියෝජනය කරයි, එබැවින් තීරු 1ක් අඩංගු පේළි 100ක් ඇතුළු කිරීමට, ඔබ අවම වශයෙන් ගොනු 100ක් විවෘත කර ලිවිය යුතුය. බෆරින් ඇතුළු කිරීම් සඳහා අතරමැදියෙකු අවශ්‍ය වන්නේ එබැවිනි (සේවාදායකයා විසින්ම බෆරින් සපයන්නේ නම් මිස) - සාමාන්‍යයෙන් කෆ්කා හෝ යම් ආකාරයක පෝලිම් කළමනාකරණ පද්ධතියක්. පසුව MergeTree වගු වෙත විශාල දත්ත කොටස් පිටපත් කිරීමට ඔබට බෆර් මේස එන්ජිම භාවිතා කළ හැක.
මේස සම්බන්ධ කිරීම් සේවාදායකයේ RAM මගින් සීමා කර ඇත, නමුත් අවම වශයෙන් ඒවා තිබේ! උදාහරණයක් ලෙස, Druid සහ Pinot නෝඩ් අතර විශාල දත්ත කොටස් ගෙනයාමට සහය නොදක්වන බෙදාහැරීමේ පද්ධතිවල සෘජුවම ක්‍රියාත්මක කිරීමට අපහසු බැවින්, Druid සහ Pinot හට කිසිසේත් එවැනි සම්බන්ධතා නොමැත.
සොයා ගැනීම්
මෙම DBMS කාර්ය සාධනය, අඩු පොදු කාර්ය, පරිමාණය සහ සරල බවෙහි විශිෂ්ට ශේෂයක් සපයන බැවින්, ඉදිරි වසරවලදී Qwintry හි ClickHouse බහුලව භාවිතා කිරීමට අපි සැලසුම් කරමු. ClickHouse ප්‍රජාව එය කුඩා හා මධ්‍යම ප්‍රමාණයේ ස්ථාපනයන්හි භාවිතා කිරීමට තවත් ක්‍රම ඉදිරිපත් කළ පසු එය ඉක්මනින් ව්‍යාප්ත වීමට පටන් ගන්නා බව මට හොඳටම විශ්වාසයි.
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (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