— гэта слупковая сістэма кіравання базамі даных для анлайн апрацоўкі аналітычных запытаў (OLAP) з адкрытым зыходным кодам, створаная Яндэксам. Яе выкарыстоўваюць Яндэкс, CloudFlare, VK.com, Badoo і іншыя сэрвісы па ўсім свеце для захоўвання сапраўды вялікіх аб'ёмаў дадзеных (устаўка тысяч радкоў у секунду або петабайты дадзеных, якія захоўваюцца на дыску).
У звычайнай, "радковы" СКБД, прыкладамі якіх служаць MySQL, Postgres, MS SQL Server, дадзеныя захоўваюцца ў такім парадку:
Пры гэтым значэнні, якія адносяцца да аднаго радка, фізічна захоўваюцца побач. У слупковых СКБД значэння з розных слупкоў захоўваюцца асобна, а дадзеныя аднаго слупка - разам:
Прыкладамі слупковых СКБД служаць Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb +.
Кампанія - мэйлфорвардэр стала выкарыстоўваць Clickhouse у 2018 годзе для складання справаздач і вельмі ўразілася яе прастатой, маштабаванасцю, падтрымкай SQL і хуткасцю. Хуткасць працы гэтай СКБД межавала з чараўніцтвам.
Прастата
Clickhouse усталёўваецца ў Ubuntu адной адзінай камандай. Калі вы ведаеце SQL, то можаце неадкладна пачаць выкарыстоўваць Clickhouse для сваіх патрэб. Аднак гэта не азначае, што вы можаце выканаць "show create table" у MySQL і зрабіць капіпаст SQL у Clickhouse.
У параўнанні з MySQL, у гэтай СКБД існуюць важныя адрозненні тыпаў дадзеных у азначэннях схемы табліц, таму для камфортнай працы вам усё ж запатрабуецца некаторы час, каб змяніць азначэнні схемы табліц і вывучыць рухавічкі табліц.
Clickhouse выдатна працуе без якога-небудзь дадатковага праграмнага забеспячэння, але калі вы захочаце выкарыстоўваць рэплікацыю, вам спатрэбіцца ўсталяваць ZooKeeper. Аналіз прадукцыйнасці запытаў паказвае выдатныя вынікі - сістэмныя табліцы ўтрымліваюць усю інфармацыю, а ўсе дадзеныя могуць быць атрыманы з дапамогай старога і сумнага SQL.
Proizvoditelnost
- параўнання 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. Мы пабудавалі невялікі кластар з некалькіх вузлоў і выканалі тэсціраванне, у ходзе якога выявілі, што сістэма валодае даволі ўражлівай прадукцыйнасцю, якая адпавядае заяўленым перавагам у бенчмарках аналітычных СКБД. Мы вырашылі больш дэталёва разгледзець канцэпцыю, якая ляжыць у аснове ClickHouse. Першай перашкодай для даследаванняў была адсутнасць інструментаў і нешматлікасць супольнасці ClickHouse, таму мы паглыбіліся ў дызайн гэтай СКБД, каб зразумець, як яна працуе.
ClickHouse не падтрымлівае прыём дадзеных непасрэдна ад Kafka, бо гэта ўсяго толькі база дадзеных, таму мы напісалі ўласны сэрвіс адаптараў на мове Go. Ён счытваў кадаваныя паведамленні Cap'n Proto у Kafka, пераўтвараў іх у TSV і ўстаўляў у ClickHouse пакетамі праз HTTP-інтэрфейс. Пазней мы перапісалі гэты сэрвіс, каб выкарыстоўваць бібліятэку Go сумесна з уласным інтэрфейсам ClickHouse для павышэння прадукцыйнасці. Пры адзнацы прадукцыйнасці прыёму пакетаў мы выявілі важную рэч – аказалася, што ў ClickHouse гэтая прадукцыйнасць моцна залежыць ад памеру пакета, гэта значыць колькасці адначасова ўстаўляных радкоў. Каб зразумець, чаму гэта адбываецца, мы вывучылі, як ClickHouse захоўвае дадзеныя.
Асноўным рухавіком, дакладней, сямействам рухавікоў для табліц, выкарыстоўваным ClickHouse для захоўвання дадзеных, з'яўляецца MergeTree. Гэты рухавічок канцэптуальна падобны на алгарытм LSM, які ўжываецца ў Google BigTable або Apache Cassandra, аднак пазбягае пабудовы прамежкавай табліцы памяці і запісвае дадзеныя непасрэдна на дыск. Гэта дае яму выдатную прапускную здольнасць запісу, бо кожны ўстаўлены пакет сартуецца толькі па "першасным ключы" primary key, сціскаецца і запісваецца на дыск, каб сфармаваць сегмент.
Адсутнасць табліцы памяці ці якога-небудзь паняцця "свежасці" дадзеных таксама азначае, што іх можна толькі дадаваць, змена ці выдаленне сістэма не падтрымлівае. На сёння адзіны спосаб выдаліць дадзеныя - гэта выдаліць іх па каляндарных месяцах, так як сегменты ніколі не перасякаюць мяжу месяца. Каманда ClickHouse актыўна працуе над тым, каб зрабіць гэтую функцыю наладжвальнай. З іншага боку, гэта робіць бесканфліктным запіс і зліццё сегментаў, таму прапускная здольнасць прыёму лінейна маштабуецца з колькасцю раўналежных уставак датуль, пакуль не адбудзецца насычэнне I/O ці ядраў.
Аднак гэтая акалічнасць таксама азначае, што сістэма не падыходзіць для невялікіх пакетаў, таму для буферызацыі выкарыстоўваюцца сэрвісы Kafka і інсертары. Далей, ClickHouse ў фонавым рэжыме працягвае пастаянна выконваць зліццё сегментаў, так што многія дробныя часткі інфармацыі будуць аб'яднаны і запісаны большую колькасць разоў, такім чынам, нарошчваючы інтэнсіўнасць запісу. Пры гэтым занадта шмат нязвязаных частак выкліча агрэсіўны тротлінг уставак да таго часу, пакуль працягваецца зліццё. Мы выявілі, што найлепшым кампрамісам паміж прыёмам дадзеных у рэжыме рэальнага часу і прадукцыйнасцю прыёму з'яўляецца прыём у табліцу абмежаванай колькасці ўставак у секунду.
Ключом да прадукцыйнасці чытання табліц з'яўляецца індэксацыя і размяшчэнне дадзеных на дыску. Незалежна ад таго, наколькі хуткая апрацоўка, калі рухавічку трэба прасканаваць тэрабайты дадзеных з дыска і выкарыстоўваць толькі частка з іх, гэта зойме час. ClickHouse з'яўляецца калоначным сховішчам, таму кожны сегмент утрымоўвае файл для кожнага слупка (калонкі) з адсартаванымі значэннямі для кожнага радка. Такім чынам, цэлыя слупкі, адсутныя ў запыце, спачатку могуць быць прапушчаныя, а затым некалькі вочак могуць быць апрацаваны раўналежна з вектарызаваным выкананнем. Каб пазбегнуць поўнага сканавання, кожны сегмент мае невялікі індэксны файл.
Улічваючы, што ўсе слупкі адсартаваныя па "першасным ключы", індэксны файл утрымоўвае толькі пазнакі (захопленыя радкі) кожнага N-га радка, каб мець магчымасць захоўваць іх у памяці нават для вельмі вялікіх табліц. Напрыклад, можна ўсталяваць налады па змаўчанні «пазначаць кожны 8192-ы радок», тады «беднае» індэксаванне табліцы з 1 трлн. радкоў, якая лёгка змяшчаецца ў памяць, зойме ўсяго 122 знакаў.
развіццё сістэмы
Развіццё і ўдасканаленне Clickhouse можна прасачыць на і пераканацца, што працэс "сталення" адбываецца ўражлівымі тэмпамі.
Папулярнасць
Падобна, папулярнасць Clickhouse расце экспанентна, асабліва ў рускамоўнай супольнасці. Мінулагодняя канферэнцыя High load 2018 (Масква, 8-9 лістапада 2018 г.) паказала, што такія монстры, як vk.com і Badoo, выкарыстоўваюць Clickhouse, з дапамогай якой устаўляюць дадзеныя (напрыклад, часопісы) з дзясяткаў тысяч сервераў адначасова. У 40-хвілінным відэа . Неўзабаве мы выкладзем стэнаграму на Хабр для зручнасці працы з матэрыялам.
вобласці прымянення
Пасля таго, як я выдаткаваў некаторы час на даследаванні, думаю, што існуюць вобласці, у якіх ClickHouse можа быць карысны або здольны поўнасцю замяніць іншыя, больш традыцыйныя і папулярныя рашэнні, такія як MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot і Druid. Далей выкладзены падрабязнасці выкарыстання ClickHouse для мадэрнізацыі ці поўнай замены вышэйпералічаных СКБД.
Пашырэнне магчымасцяў MySQL і PostgreSQL
Зусім нядаўна мы часткова замянілі MySQL на ClickHouse для платформы інфармацыйных бюлетэняў . Праблема складалася ў тым, што MySQL з-за непрадуманага дызайну рэгістраваў кожны адпраўлены ліст і кожную спасылку ў гэтым лісце з хэшам base64, ствараючы велізарную табліцу MySQL (email_stats). Пасля адпраўкі падпісантам сэрвісу ўсяго толькі 10 мільёнаў лістоў гэтая табліца займала 150 ГБ файлавай прасторы, і MySQL пачынаў "тупіць" на простых запытах. Каб выправіць праблему файлавай прасторы, мы паспяхова выкарыстоўвалі сціск табліцы InnoDB, якое паменшыла яе ў 4 разы. Аднак усё роўна не мае сэнсу захоўваць больш за 20-30 мільёнаў электронных лістоў у MySQL толькі дзеля чытанні гісторыі, бо любы просты запыт, які па нейкім чынніку павінен выканаць поўнае сканаванне, прыводзіць да свопу і вялікай нагрузцы на I/O, з нагоды чаго мы рэгулярна атрымлівалі папярэджанні Zabbix.
Clickhouse выкарыстоўвае два алгарытму сціску, якія скарачаюць аб'ём дадзеных прыкладна ў , але ў дадзеным канкрэтным выпадку дадзеныя былі асабліва "сціскаемымі".
Замена ELK
Зыходзячы з уласнага досведу, стэк ELK (ElasticSearch, Logstash і Kibana, у дадзеным пэўным выпадку ElasticSearch) патрабуе значна больш рэсурсаў для запуску, чым гэта неабходна для захоўвання логаў. ElasticSearch выдатны рухавічок, калі вам патрэбен добры паўнатэкставы пошук у логах (а я не думаю, што ён вам рэальна патрэбен), але мне цікава, чаму дэ-факта ён стаў стандартным рухавічком для вядзення часопіса. Яго прадукцыйнасць прыёму ў спалучэнні з Logstash стварала нам праблемы нават пры даволі невялікіх нагрузках і патрабавала даданні ўсё большага аб'ёму аператыўнай памяці і дыскавай прасторы. Як БД, Clickhouse лепш ElasticSearch па наступных прычынах:
- Падтрымка дыялекту SQL;
- Лепшая ступень сціску захоўваемых дадзеных;
- Падтрымка пошуку рэгулярных выразаў Regex замест пошуку поўнага тэксту;
- Палепшанае планаванне запытаў і больш высокая агульная прадукцыйнасць.
У цяперашні час самая вялікая праблема, якая ўзнікае пры параўнанні ClickHouse з ELK, гэта адсутнасць рашэнняў для адгрузкі логаў, а таксама недахоп дакументацыі і навучальных дапаможнікаў па дадзенай тэме. Пры гэтым кожны карыстач можа наладзіць ELK з дапамогай кіраўніцтва Digital Ocean, што вельмі важна для хуткага ўкаранення падобных тэхналогій. Тут ёсць рухавічок БД, але пакуль яшчэ няма Filebeat для ClickHouse. Так, там прысутнічае і сістэма для працы з логамі , існуе інструмент для ўводу ў ClickHouse дадзеных лог-файлаў, але ўсё гэта патрабуе больш часу. Аднак ClickHouse усё роўна лідзіруе ў сілу сваёй прастаты, таму нават навічкі элементарна яе ўсталёўваюць і прыступаюць да поўнафункцыянальнага выкарыстання літаральна праз 10 хвілін.
Аддаючы перавагу мінімалісцкім рашэнням, я паспрабаваў выкарыстоўваць FluentBit, інструмент для адгрузкі часопісаў з вельмі невялікім аб'ёмам памяці, разам з ClickHouse, пры гэтым імкнучыся пазбегнуць ужыванні Kafka. Аднак неабходна ўхіліць невялікія несумяшчальнасці, такія як , перш чым гэта можна будзе зрабіць без proxy-пласта, які пераўтворыць дадзеныя з FluentBit у ClickHouse.
У якасці альтэрнатывы Kibana можна ў ролі бэкенда ClickHouse выкарыстоўваць . Наколькі я зразумеў, пры гэтым могуць узнікаць праблемы з прадукцыйнасцю пры рэндэрынгу велізарнай колькасці пунктаў дадзеных, асабліва з больш старымі версіямі Grafana. У Qwintry мы пакуль што гэта не спрабавалі, але скаргі на такое час ад часу з'яўляюцца на канале падтрымкі ClickHouse у Telegram.
Замена Google Big Query і Amazon RedShift (рашэнне для буйных кампаній)
Ідэальны варыянт выкарыстання BigQuery - гэта загрузіць 1 ТБ дадзеных JSON і выканайце па іх аналітычныя запыты. Big Query - гэта выдатны прадукт, маштабаванасць якога цяжка пераацаніць. Гэта значна больш складанае ПЗ, чым ClickHouse, якое працуе на ўнутраным кластары, але з пункту гледжання кліента яно мае шмат агульнага з ClickHouse. BigQuery можа хутка падаражэць, як толькі вы станеце плаціць за кожны SELECT, так што гэта сапраўднае рашэнне SaaS з усімі яго плюсамі і мінусамі.
ClickHouse з'яўляецца найлепшым выбарам у выпадку, калі вы выконваеце шмат дарагіх з пункту гледжання вылічэнняў запытаў. Чым больш запытаў SELECT вы выконваеце кожны дзень - тым больш сэнсу ў замене Big Query на ClickHouse, таму што такая замена дапаможа вам зэканоміць тысячы даляраў, калі гаворка ідзе пра шматлікія тэрабайты апрацоўваных дадзеных. Гэта не адносіцца да захоўваемых дадзеных, апрацоўка якіх у Big Query абыходзіцца даволі танна.
У артыкуле сузаснавальніка кампаніі Altinity Аляксандра Зайцава распавядаецца аб перавагах такой міграцыі СКБД.
Замена TimescaleDB
TimescaleDB з'яўляецца пашырэннем PostgreSQL, якое аптымізуе працу з часавымі шэрагамі timeseries у звычайнай базе дадзеных (, ).
Хоць ClickHouse не з'яўляецца сур'ёзным канкурэнтам у нішы часовых шэрагаў, але слупковай структуры і вектарнага выканання запытаў, у большасці выпадкаў апрацоўкі аналітычных запытаў ён нашмат хутчэй TimescaleDB. Пры гэтым прадукцыйнасць прыёму пакетных дадзеных ClickHouse прыкладна ў 3 разы вышэй, да таго ж ён выкарыстоўвае ў 20 разоў менш дыскавай прасторы, што сапраўды важна для апрацоўкі вялікіх аб'ёмаў гістарычных дадзеных. .
У адрозненне ад ClickHouse, адзіным спосабам зэканоміць крыху дыскавай прасторы ў TimescaleDB з'яўляецца выкарыстанне ZFS або аналагічных файлавых сістэм.
Будучыя абнаўленні ClickHouse, хутчэй за ўсё, увядуць дэльта-кампрэсію, якая зробіць яго яшчэ больш прыдатным для апрацоўкі і захоўвання дадзеных часовых шэрагаў. TimescaleDB можа стаць лепшым выбарам, чым "голы" ClickHouse, у наступных выпадках:
- невялікія інсталяцыі з вельмі малым аб'ёмам аператыўнай памяці (<3 ГБ);
- вялікая колькасць дробных INSERT, якія вы не жадаеце буферызаваць у вялікія фрагменты;
- лепшая ўзгодненасць, аднастайнасць і патрабаванні AСID;
- падтрымка PostGIS;
- аб'яднанне з існуючымі табліцамі PostgreSQL, бо па істоце Timescale DB з'яўляецца PostgreSQL.
Канкурэнцыя з сістэмамі Hadoop і MapReduce
Hadoop і іншыя прадукты MapReduce могуць выконваць мноства складаных вылічэнняў, але яны, як правіла, працуюць з вялізнымі затрымкамі ClickHouse выпраўляе гэтую праблему, апрацоўваючы тэрабайты дадзеных і амаль імгненна выдаючы вынік. Такім чынам, ClickHouse нашмат больш эфектыўна для выканання хуткага, інтэрактыўнага аналітычнага даследавання, што павінна зацікавіць спецыялістаў у галіне апрацоўкі дадзеных.
Канкурэнцыя з Pinot і Druid
Бліжэйшымі канкурэнтамі ClickHouse з'яўляюцца слупковыя лінейна-маштабаваныя open source прадукты Pinot і Druid. Выдатная праца ў параўнанні гэтых сістэм апублікавана ў артыкуле ад 1 лютага 2018 г.
Дадзены артыкул патрабуе абнаўлення - у ёй гаворыцца, што ClickHouse не падтрымлівае аперацыі UPDATE і DELETE, што не зусім дакладна ў стаўленні апошніх версій.
У нас няма дастатковага досведу працы з гэтымі СКБД, але мне зусім не падабаецца складанасць выкарыстоўванай інфраструктуры, якая патрабуецца для запуску Druid і Pinot – гэта цэлая куча "рухомых частак", акружаных Java з усіх бакоў.
Druid і Pinot з'яўляюцца інкубатарскімі праектамі Apache, ход развіцця якіх падрабязна асвятляецца Apache на старонках сваіх праектаў GitHub. Pinot з'явіўся ў інкубатары ў кастрычніку 2018, а Druid нарадзіўся на 8 месяцаў раней - у лютым.
Адсутнасць інфармацыі аб тым, як працуе AFS, выклікае ў мяне некаторыя, і магчыма, дурныя пытанні. Цікава, ці заўважылі аўтары Pinot, што Apache Foundation больш размешчаны да Druid, і не выклікала ці такое стаўленне да канкурэнта пачуццё зайздрасці? Ці запаволіцца развіццё Druid і паскорыцца развіццё Pinot, калі фундатары, якія падтрымліваюць першы, раптам зацікавяцца другім?
Недахопы ClickHouse
Няспеласць: відавочна, што гэта ўсё яшчэ нянудная тэхналогія, але ў любым выпадку, нічога падобнага ў іншых столбчатых СКБД не назіраецца.
Маленькія ўстаўкі дрэнна працуюць з высокай хуткасцю: устаўкі павінны быць падзелены на вялікія кавалкі, таму што прадукцыйнасць невялікіх уставак зніжаецца прапарцыйна колькасці слупкоў у кожным радку. Менавіта так у ClickHouse захоўваюцца дадзеныя на дыску - кожны слупок азначае 1 файл або больш, таму для ўстаўкі 1 радкі, якая змяшчае 100 слупкоў, неабходна адкрыць і запісаць не менш за 100 файлаў. Вось чаму для буферызацыі ўставак патрабуецца пасярэднік (калі толькі сам кліент не забяспечвае буферызацыю) звычайна гэта Kafka або нейкая сістэма кіравання чэргамі. Можна таксама выкарыстоўваць рухавік Buffer table, каб пазней капіяваць вялікія фрагменты дадзеных у табліцы MergeTree.
Злучэнні табліц абмежаваныя аператыўнай памяццю сервера, затое, прынамсі, яны тамака ёсць! Напрыклад, у Druid і Pinot наогул няма такіх злучэнняў, паколькі іх цяжка рэалізаваць прама ў размеркаваных сістэмах, якія не падтрымліваюць перасоўванне вялікіх кавалкаў дадзеных паміж вузламі.
Высновы
У бліжэйшыя гады мы плануем шырока выкарыстоўваць ClickHouse ў Qwintry, паколькі гэтая СКБД забяспечвае выдатны баланс прадукцыйнасці, нізкіх накладных выдаткаў, маштабаванасці і прастаты. Я амаль упэўнены, што яна пачне хутка распаўсюджвацца, як толькі супольнасць ClickHouse прыдумае больш спосабаў яе выкарыстання на малых і сярэдніх усталёўках.
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com