е система за управление на колонна база данни с отворен код за онлайн аналитична обработка на заявки (OLAP), създадена от Yandex. Използва се от Yandex, 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 за вашите нужди. Това обаче не означава, че можете да „покажете таблица за създаване“ в MySQL и да копирате и поставите SQL в Clickhouse.
В сравнение с MySQL има важни разлики в типовете данни в дефинициите на схемата на таблицата в тази СУБД, така че все още ви трябва известно време, за да промените дефинициите на схемата на таблицата и да научите машините за таблица, за да се чувствате удобно.
Clickhouse работи чудесно без допълнителен софтуер, но ако искате да използвате репликация, ще трябва да инсталирате ZooKeeper. Анализът на производителността на заявките показва отлични резултати - системните таблици съдържат цялата информация и всички данни могат да бъдат получени с помощта на стар и скучен SQL.
продуктивност
- Clickhouse срещу Vertica и MySQL сравнения на конфигурационен сървър: два сокета Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 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, но избягва изграждането на междинна таблица с памет и записва данни директно на диск. Това му осигурява отлична пропускателна способност при запис, тъй като всеки вмъкнат пакет се сортира само по първичния ключ на "първичния ключ", компресира се и се записва на диска, за да образува сегмент.
Липсата на таблица с памет или каквато и да е концепция за „свежест“ на данните също означава, че те могат само да се добавят, системата не поддържа промяна или изтриване. От днес единственият начин за изтриване на данни е да ги изтриете по календарен месец, тъй като сегментите никога не преминават границата на месеца. Екипът на ClickHouse работи активно върху това да направи тази функция персонализирана. От друга страна, той прави писането и сливането на сегменти без конкуренция, така че пропускателната способност на получаването се мащабира линейно с броя на паралелните вмъквания, докато I/O или ядрата се наситят.
Това обстоятелство обаче също така означава, че системата не е подходяща за малки пакети, така че за буфериране се използват Kafka услуги и вмъквачи. Освен това ClickHouse във фонов режим продължава непрекъснато да обединява сегментите, така че много малки парчета информация да се комбинират и записват повече пъти, като по този начин се увеличава интензивността на записа. Твърде много несвързани части обаче ще предизвикат агресивно ограничаване на вмъкванията, докато сливането продължава. Установихме, че най-добрият компромис между поглъщането на данни в реално време и производителността на поглъщането е да се приеме ограничен брой вмъквания за секунда в таблицата.
Ключът към ефективността на четене на таблици е индексирането и местоположението на данните на диска. Без значение колко бърза е обработката, когато двигателят трябва да сканира терабайти данни от диска и да използва само част от тях, това ще отнеме време. ClickHouse е хранилище на колони, така че всеки сегмент съдържа файл за всяка колона (колона) със сортирани стойности за всеки ред. По този начин цели колони, които не присъстват в заявката, могат първо да бъдат пропуснати и след това множество клетки могат да бъдат обработени паралелно с векторизирано изпълнение. За да се избегне пълно сканиране, всеки сегмент има малък индекс файл.
Като се има предвид, че всички колони са сортирани по "първичния ключ", индексният файл съдържа само етикетите (захванатите редове) на всеки N-ти ред, за да може да ги запази в паметта дори за много големи таблици. Например, можете да зададете настройките по подразбиране на „маркиране на всеки 8192-ри ред“, след това „оскъдно“ индексиране на таблица с 1 трилион. редовете, които лесно се побират в паметта, биха заели само 122 070 знака.
Развитие на системата
Развитието и усъвършенстването на Clickhouse може да се проследи и се уверете, че процесът на „порастване“ протича с впечатляваща скорост.
Популярност
Изглежда, че популярността на Clickhouse нараства експоненциално, особено в рускоезичната общност. Миналогодишната конференция High load 2018 (Москва, 8-9 ноември 2018 г.) показа, че чудовища като vk.com и Badoo използват Clickhouse, който вмъква данни (например регистрационни файлове) от десетки хиляди сървъри едновременно. В 40 минутно видео . Скоро ще публикуваме преписа на Habr за удобство при работа с материала.
приложения
След като прекарах известно време в проучване, смятам, че има области, в които ClickHouse може да бъде полезен или способен напълно да замени други по-традиционни и популярни решения като MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot и Друид. По-долу са подробностите за използването на ClickHouse за надграждане или пълна замяна на горната СУБД.
Разширяване на MySQL и PostgreSQL
Съвсем наскоро заменихме частично MySQL с ClickHouse за платформата за бюлетини . Проблемът беше, че MySQL поради зле замислен дизайн регистрира всеки изпратен имейл и всяка връзка в този имейл с base64 хеш, създавайки огромна MySQL таблица (email_stats). След като изпрати само 10 милиона имейла до абонатите на услугата, тази таблица заемаше 150 GB файлово пространство и MySQL започна да „оглупява“ при прости заявки. За да коригираме проблема с файловото пространство, ние успешно използвахме компресирането на таблицата InnoDB, което го намали с коефициент 4. Въпреки това, все още няма смисъл да се съхраняват повече от 20-30 милиона имейла в MySQL само заради четенето на хронологията, тъй като всяка проста заявка, която по някаква причина трябва да направи пълно сканиране, води до суап и тежък I/O режийни, за които редовно получавахме предупреждения от Zabbix.
Clickhouse използва два алгоритъма за компресиране, които намаляват количеството данни с около , но в този конкретен случай данните бяха особено „компресируеми“.
ELK Замяна
Въз основа на моя собствен опит стекът ELK (ElasticSearch, Logstash и Kibana, в този конкретен случай ElasticSearch) изисква много повече ресурси за работа, отколкото са необходими за съхраняване на регистрационни файлове. ElasticSearch е страхотна машина, ако искате добро търсене на дневници в пълен текст (и не мисля, че наистина имате нужда от нея), но се чудя защо се превърна в де факто стандартната машина за регистриране. Неговата производителност при поглъщане, комбинирана с Logstash, ни създаде проблеми дори при сравнително леки натоварвания и изискваше добавянето на все повече RAM и дисково пространство. Като база данни Clickhouse е по-добра от ElasticSearch поради следните причини:
- Поддръжка на SQL диалект;
- Най-добра степен на компресия на съхраняваните данни;
- Поддръжка на Regex търсене вместо пълнотекстово търсене;
- Подобрено планиране на заявки и по-добра цялостна производителност.
В момента най-големият проблем, който възниква при сравняване на ClickHouse с ELK, е липсата на решения за качване на регистрационни файлове, както и липсата на документация и уроци по тази тема. В същото време всеки потребител може да настрои ELK с помощта на ръководството за Digital Ocean, което е много важно за бързото внедряване на такива технологии. Тук има двигател за база данни, но все още няма Filebeat за ClickHouse. Да, има и система за работа с логове , има инструмент за въвеждане на данни от лог файл в ClickHouse, но всичко това отнема повече време. Въпреки това, ClickHouse все още е водеща поради своята простота, така че дори и начинаещите могат лесно да го инсталират и да започнат напълно функционална употреба само за 10 минути.
Предпочитайки минималистични решения, опитах да използвам FluentBit, инструмент за качване на регистрационни файлове с много ниска памет, с ClickHouse, докато се опитвах да избегна използването на Kafka. Трябва обаче да се обърне внимание на незначителни несъвместимости, като напр преди да може да се направи без прокси слоя, който преобразува данни от FluentBit в ClickHouse.
Като алтернатива на Kibana, можете да използвате ClickHouse като бекенд . Доколкото разбирам, това може да причини проблеми с производителността при изобразяване на огромен брой точки от данни, особено при по-стари версии на Grafana. В Qwintry все още не сме опитвали това, но оплаквания за това се появяват от време на време в канала за поддръжка на ClickHouse в Telegram.
Замяна на Google Big Query и Amazon RedShift (решение за големи компании)
Идеалният случай за използване на BigQuery е да заредите 1TB JSON данни и да изпълните аналитични заявки върху тях. Big Query е страхотен продукт, чиято мащабируемост е трудно да се надцени. Това е много по-сложен софтуер от ClickHouse, работещ на вътрешен клъстер, но от гледна точка на клиента има много общо с ClickHouse. BigQuery може бързо да „повиши цената“, след като започнете да плащате за всеки SELECT, така че това е истинско SaaS решение с всичките му плюсове и минуси.
ClickHouse е най-добрият избор, когато изпълнявате много изчислително скъпи заявки. Колкото повече SELECT заявки изпълнявате всеки ден, толкова по-смислено е да замените Big Query с ClickHouse, защото такава замяна ще ви спести хиляди долари, когато става въпрос за много терабайти данни, които се обработват. Това не се отнася за съхранените данни, които са доста евтини за обработка в Big Query.
В статия на Александър Зайцев, съосновател на Altinity описва ползите от такава миграция на СУБД.
Замяна на TimescaleDB
TimescaleDB е разширение на PostgreSQL, което оптимизира работата с времеви серии в обикновена база данни (, ).
Въпреки че ClickHouse не е сериозен конкурент в нишата на времевите серии, но по отношение на колонна структура и векторно изпълнение на заявки, той е много по-бърз от TimescaleDB в повечето случаи на обработка на аналитични заявки. В същото време производителността при получаване на пакетни данни от ClickHouse е около 3 пъти по-висока, освен това използва 20 пъти по-малко дисково пространство, което е наистина важно за обработка на големи обеми исторически данни: .
За разлика от ClickHouse, единственият начин да спестите малко дисково пространство в TimescaleDB е да използвате ZFS или подобни файлови системи.
Предстоящите актуализации на ClickHouse вероятно ще въведат делта компресия, което ще го направи още по-подходящ за обработка и съхранение на данни от времеви серии. TimescaleDB може да е по-добър избор от чистия ClickHouse в следните случаи:
- малки инсталации с много малко RAM (<3 GB);
- голям брой малки INSERT, които не искате да буферирате в големи фрагменти;
- по-добра последователност, еднородност и изисквания за КИСЕЛНОСТ;
- PostGIS поддръжка;
- се сливат със съществуващи таблици на PostgreSQL, тъй като Timescale DB по същество е PostgreSQL.
Конкуренция със системите Hadoop и MapReduce
Hadoop и други продукти на MapReduce могат да извършват много сложни изчисления, но са склонни да работят с огромно забавяне. ClickHouse коригира този проблем, като обработва терабайти данни и дава резултати почти мигновено. По този начин ClickHouse е много по-ефективен за извършване на бързи, интерактивни аналитични изследвания, които трябва да представляват интерес за учените по данни.
Конкуренция с Пино и Друид
Най-близките конкуренти на ClickHouse са колонните, линейно мащабируеми продукти с отворен код Pinot и Druid. Отлична работа за сравняване на тези системи е публикувана в статията 1 февруари 2018 г
Тази статия трябва да се актуализира - пише, че ClickHouse не поддържа операциите UPDATE и DELETE, което не е съвсем вярно по отношение на последните версии.
Нямаме много опит с тези СУБД, но не ми харесва сложността на основната инфраструктура, която е необходима за стартиране на Druid и Pinot - това е цял куп "движещи се части", заобиколени от Java от всички страни.
Druid и Pinot са инкубаторни проекти на Apache, които са разгледани подробно от Apache на техните страници за проекти в GitHub. Пино се появи в инкубатора през октомври 2018 г., а Друид се роди 8 месеца по-рано - през февруари.
Липсата на информация за това как работи AFS повдига някои и може би глупави въпроси за мен. Чудя се дали авторите на Pinot са забелязали, че фондация Apache е по-разположена към Druid и дали такова отношение към конкурент предизвика чувство на завист? Ще се забави ли развитието на Druid и ще се ускори ли развитието на Pinot, ако спонсорите, подкрепящи първото, внезапно се заинтересуват от второто?
Недостатъци на ClickHouse
Незрялост: Очевидно това все още е скучна технология, но във всеки случай нищо подобно не се вижда в други колонни СУБД.
Малките вмъквания не се представят добре при висока скорост: вмъкванията трябва да бъдат разделени на големи парчета, тъй като производителността на малките вмъквания се влошава пропорционално на броя на колоните във всеки ред. Ето как ClickHouse съхранява данни на диск - всяка колона означава 1 файл или повече, така че за да вмъкнете 1 ред, съдържащ 100 колони, трябва да отворите и запишете поне 100 файла. Ето защо буферирането на вмъкване изисква посредник (освен ако самият клиент не осигурява буфериране) - обикновено Kafka или някакъв вид система за опашка. Можете също да използвате машината за буферна таблица, за да копирате по-късно големи части от данни в таблици MergeTree.
Обединяването на таблици е ограничено от RAM на сървъра, но поне ги има! Например Druid и Pinot изобщо нямат такива връзки, тъй като те са трудни за директно внедряване в разпределени системи, които не поддържат преместване на големи части от данни между възли.
Данни
През следващите години планираме да използваме широко ClickHouse в Qwintry, тъй като тази СУБД осигурява отличен баланс на производителност, ниски разходи, мащабируемост и простота. Почти съм сигурен, че ще се разпространи бързо, след като общността на ClickHouse измисли повече начини да го използва в малки и средни инсталации.
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с 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! Прочети за
Източник: www.habr.com