- це стовпцева система управління базами даних для онлайн обробки аналітичних запитів (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 активно працює над тим, щоб зробити цю функцію, що налаштовується. З іншого боку, це робить безконфліктним запис та злиття сегментів, тому пропускна спроможність прийому лінійно масштабується з кількістю паралельних вставок, доки не відбудеться насичення 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 мільйонів електронних листів у 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 вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com