— това е колоночна система за управление на бази данни за онлайн обработка на аналитични заявки (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.
Производителност
- сравнения на 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 активно работи, за да направи тази функция конфигурируемa. От една страна, това прави записването и сливането на сегменти без конфликти, така че пропускната способност на приема на линейно се мащабира с увеличаването на паралелните вставки, докато не се стигне до насищане на I/O или ядра.
Въпреки това, това обстоятелство също така означава, че системата не е подходяща за малки пакети, така че за буфериране се използват услуги като Kafka и инсертери. Освен това, ClickHouse постоянно изпълнява сливане на сегменти на заден план, така че много малки части информация ще бъдат комбинирани и записани многократно, увеличавайки интензивността на записа. В същото време, прекалено много несвързани части ще предизвикат агресивно задържане на вставките, докато сливането продължава. Ние установихме, че най-добрият компромис между приема на данни в реално време и производителността на приема е ограничаване на броя на вставките в секунда в таблицата.
Ключът към производителността на четене от таблиците е индексирането и разположението на данните на диска. Няма значение колко бърза е обработката, когато двигателят трябва да сканира терабайти данни от диска и да използва само част от тях, това отнема време. ClickHouse е колонково хранилище, така че всеки сегмент съдържа файл за всяка колона с сортирани стойности за всеки ред. По този начин, цели колони, които не са в заявката, могат да бъдат пропуснати на първо време, а след това няколко клетки могат да бъдат обработени паралелно с векторизирано изпълнение. За да се избегне пълно сканиране, всеки сегмент има малък индексен файл.
Като се има предвид, че всички колони са сортирани по "първичен ключ", индексният файл съдържа само етикетите (зададени редове) на всяка N-та ред, за да може да ги съхранява в паметта дори за много големи таблици. Например, може да се зададе настройка по подразбиране "да се етикират всеки 8192-ри ред", тогава "оскъдното" индексиране на таблица с 1 трлн. реда, която лесно се побира в паметта, ще изисква само 122 070 знака.
Развитие на системата
Развитието и усъвършенстването на 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 TB данни в JSON и да извършвате аналитични заявки върху тях. Big Query е страхотен продукт, чиято мащабируемост е трудно да се надцени. Това е много по-сложен софтуер в сравнение с ClickHouse, работещ на вътрешен клъстер, но от гледна точка на клиента има много общо с ClickHouse. BigQuery може бързо да "поскъпи", веднага щом започнете да плащате за всяко SELECT, така че това е истинско SaaS решение с всичките му предимства и недостатъци.
ClickHouse е най-добрият избор, когато изпълнявате много скъпи от гледна точка на изчисления запитвания. Колкото повече SELECT запитвания изпълнявате всеки ден — толкова повече има смисъл да замените Big Query с ClickHouse, тъй като такава замяна може да ви спести хиляди долари, ако става въпрос за много терабайти обработвани данни. Това не важи за съхраняваните данни, обработката на които в Big Query е сравнително евтина.
В статията на съоснователя на компанията Altinity Александър Зайцев се обсъждат предимствата на такава миграция на СУБД.
Заместване на TimescaleDB
TimescaleDB е разширение на PostgreSQL, което оптимизира работата с времеви редове (timeseries) в обичайната база данни., ).
Въпреки че ClickHouse не е сериозен конкурент в нишата на времевите редове, колонната структура и векторното изпълнение на запитванията му го правят значително по-бърз от TimescaleDB в повечето случаи на обработка на аналитични запитвания. Производителността на входа на пакетни данни в ClickHouse е приблизително три пъти по-висока, а той използва 20 пъти по-малко дисково пространство, което е от съществено значение за обработка на големи обеми исторически данни..
За разлика от ClickHouse, единственият начин да спестите малко дисково пространство в TimescaleDB е да използвате ZFS или подобни файлови системи.
В предстоящите обновления на ClickHouse вероятно ще бъде въведена дълта компресия, която ще го направи още по-подходящ за обработка и съхранение на данни от времеви редове. TimescaleDB може да бъде по-добрият избор от "голия" ClickHouse в следните случаи:
- малки инсталации с много малък обем оперативна памет (<3 ГБ);
- голям брой малки INSERT, които не искате да буферирате в големи фрагменти;
- по-добра последователност, униформеност и изисквания AСID;
- поддръжка на PostGIS;
- съединяване с съществуващи таблици на PostgreSQL, тъй като по същество TimescaleDB е 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 на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това
Източник: habr.com
