Переїжджаємо на ClickHouse: через 3 роки

Три роки тому Віктор Тарнавський та Олексій Міловидов із Яндекса на сцені HighLoad ++ розповідалиякий ClickHouse хороший, і як він не гальмує. А на сусідній сцені був Олександр Зайцев с доповіддю про переїзд на Натисніть Будинок з іншої аналітичної СУБД та з висновком, що Натисніть БудинокЗвичайно, хороший, але не дуже зручний. Коли у 2016 році компанія LifeStreet, у якій тоді працював Олександр, перекладала мультипетабайтову аналітичну систему на Натисніть Будинок, це була захоплююча «дорога з жовтої цеглини», сповнена невідомих небезпек. Натисніть Будинок тоді нагадував мінне поле.

Три роки по тому Натисніть Будинок став набагато краще - за цей час Олександр заснував компанію Altinity, яка не лише допомагає переїжджати на Натисніть Будинок десяткам проектів, але й удосконалює сам продукт разом із колегами з Яндекса. Зараз Натисніть Будинок все ще не безтурботна прогулянка, але вже й не мінне поле.

Олександр займається розподіленими системами з 2003 року, розробляв великі проекти на MySQL, Oracle и Vertica. На минулій HighLoad ++ 2019 Олександр, один із піонерів використання Натисніть Будинок, Розповів, що зараз із себе представляє ця СУБД. Ми дізнаємося про основні особливості Натисніть Будинок: чим він відрізняється від інших систем і в яких випадках його ефективніше використовувати. На прикладах розглянемо свіжі та перевірені проектами практики по побудові систем Натисніть Будинок.

Ретроспектива: що було 3 роки тому

Три роки тому ми перекладали компанію LifeStreet на Натисніть Будинок з іншого аналітичної бази даних, і міграція аналітики рекламної мережі виглядала так:

• Червень 2016. OpenSource з'явився Натисніть Будинок та стартував наш проект;
• Серпень. Доказ концепції: велика рекламна мережа, інфраструктура та 200-300 терабайт даних;
• Жовтень. Перші продакшн-дані;
• Грудень. Повне продуктове навантаження - 10-50 мільярдів подій на день.
• Червень 2017. Успішний переїзд користувачів на Натисніть Будинок, 2,5 петабайт даних на кластері з 60 серверів.

У процесі міграції зростало розуміння, що Натисніть Будинок - Це хороша система, з якою приємно працювати, але це внутрішній проект компанії Яндекс. Тому є нюанси: Яндекс спочатку займатиметься власними внутрішніми замовниками і лише потім — спільнотою та потребами зовнішніх користувачів, а ClickHouse не дотягував тоді рівня ентерпрайзу по багатьох функціональних областях. Тому в березні 2017 року ми започаткували компанію Altinity, щоб зробити Натисніть Будинок ще швидше та зручніше не тільки для Яндекса, але й для інших користувачів. І тепер ми:

• Навчаємо та допомагаємо будувати рішення на Натисніть Будинок так, щоб замовники не набивали гулі, і щоб рішення у результаті працювало;
• Забезпечуємо 24/7 підтримку Натисніть Будинок-інсталяцій;
• Розробляємо власні екосистемні проекти;
• Активно комитим в сам Натисніть Будинок, відповідаючи на запити користувачів, які бажають бачити ті чи інші фічі.

І звичайно, ми допомагаємо з переїздом на Натисніть Будинок с MySQL, Vertica, оракул, Зелена слива, Червоне зміщення та інших систем. Ми брали участь у різних переїздах, і вони всі були успішними.

Навіщо взагалі переїжджати на Натисніть Будинок

Чи не гальмує! Це головна причина. Натисніть Будинок - дуже швидка база даних для різних сценаріїв:

Випадкові цитати людей, які довго працюють з Натисніть Будинок.

Масштабованість. На якійсь іншій БД можна досягти непоганої продуктивності на одній залізці, але Натисніть Будинок можна масштабувати як вертикально, а й горизонтально, просто додаючи сервера. Все працює не так гладко, як хотілося б, але працює. Можна нарощувати систему разом із зростанням бізнесу. Це важливо, що ми не обмежені рішення зараз і завжди є потенціал для розвитку.

Портованість. Немає прив'язки до чогось одного. Наприклад, з Амазонська червона зміна важко кудись переїхати. А Натисніть Будинок можна поставити собі на ноутбук, сервер, задеплоїти в хмару, піти в Кубернетес - Немає обмежень на експлуатацію інфраструктури. Це зручно для всіх, і це велика перевага, якою не можуть похвалитися багато інших схожих БД.

Гнучкість. Натисніть Будинок не зупиняється на чомусь одному, наприклад, на Яндекс.Метриці, а розвивається і використовується в дедалі більшій кількості різних проектів та індустрій. Його можна розширювати, додаючи нові можливості для вирішення нових завдань. Наприклад, вважається, що зберігати логи в БД моветон, тому для цього вигадали. Elasticsearch. Але, завдяки гнучкості Натисніть Будинок, в ньому теж можна зберігати логи, і часто це навіть краще, ніж у Elasticsearch - У Натисніть Будинок для цього потрібно в 10 разів менше заліза.

Безкоштовний Open Source. Не треба платити ні за що. Не слід домовлятися про дозвіл поставити систему собі на ноутбук чи сервер. Нема прихованих платежів. При цьому жодна інша Open Source технологія баз даних не може конкурувати за швидкістю Натисніть Будинок. MySQL, MariaDB, Greenplum — усі вони набагато повільніші.

Спільнота, драйв та веселощі. У Натисніть Будинок відмінна спільнота: мітапи, чати та Олексій Міловидов, який нас усіх заряджає своєю енергією та оптимізмом.

Переїзд на ClickHouse

Щоб переходити на Натисніть Будинок з чогось, потрібні лише три речі:

• Розуміти обмеження Натисніть Будинок і навіщо він підходить.
• Використовувати переваги технології та її найсильніші сторони.
• Експериментувати. Навіть розуміючи як працює Натисніть Будинок, Не завжди можна передбачити, коли він буде швидше, коли повільніше, коли краще, а коли гірше. Тож спробуйте.

Проблема переїзду

Є тільки одне «але»: якщо переїжджаєте на Натисніть Будинок з чогось іншого, зазвичай щось йде не так. Ми звикли до якихось практик та речей, які працюють у улюбленій БД. Наприклад, будь-яка людина, яка працює з SQL-базами даних вважає обов'язковими такий набір функцій:

• транзакції;
• констрейнт;
• консистенція;
• індекси;
• UPDATE/DELETE;
• NULLs;
• мілісекунди;
• автоматичне приведення типів;
• множинні джойни;
• довільні партиції;
• засоби управління кластером.

Набір обов'язковий, але три роки тому в Натисніть Будинок не було жодної з цих функцій! Зараз із нереалізованого залишилося менше половини: транзакції, констрейнти, Consistency, мілісекунди та приведення типів.

І головне — те, що в Натисніть Будинок деякі стандартні практики та підходи не працюють або працюють не так, як ми звикли. Все, що з'являється в Натисніть Будинок, відповідає "ClickHouse way», тобто. функції від інших БД. Наприклад:

• Індекси не вибирають, а пропускають.
• UPDATE/DELETE не синхронні, а асинхронні.
• Численні джойни є, але планувальника запитів немає. Як вони тоді виконуються, взагалі не дуже зрозуміло людям зі світу БД.

Сценарії ClickHouse

1960 року американський математик угорського походження Wigner EP написав статтю «unreasonable effectiveness of mathematics в the natural sciences»(«Незбагненна ефективність математики в природничих науках») про те, що навколишній світ чомусь добре описується математичними законами. Математика - абстрактна наука, а фізичні закони, виражені в математичній формі не тривіальні, і Wigner EP наголосив, що це дуже дивно.

З моєї точки зору, Натисніть Будинок - Така ж дивина. Переформулюючи Вігнера, можна сказати так: вражаюча незбагненна ефективність Натисніть Будинок у найрізноманітніших аналітичних додатках!

Наприклад, візьмемо Real-Time Data Warehouse, в який дані вантажаться практично безперервно. Ми хочемо отримувати від нього запити із секундною затримкою. Будь ласка – використовуємо Натисніть Будиноктому що для цього сценарію він і був розроблений. Натисніть Будинок саме так і використовується не тільки в Інтернет, але і в маркетинговій та фінансовій аналітиці, AdTech, а також у Fraud detection. У Real-time Data Warehouse використовується складна структурована схема типу «зірка» або «сніжинка», багато таблиць РЕЄСТРАЦІЯ (іноді множинними), а дані зазвичай зберігаються та змінюються в якихось системах.

Візьмемо інший сценарій Часовий ряд: моніторинг пристроїв, мереж, статистика використання, інтернет речей Тут ми зустрічаємося із впорядкованими за часом досить простими подіями. Натисніть Будинок для цього не був спочатку розроблений, але добре себе показав, тому великі компанії використовують Натисніть Будинок як сховище для моніторингової інформації Щоб вивчити, чи підходить Натисніть Будинок для time-series, ми зробили бенчмарк на основі підходу та результатах InfluxDB и Часовий шкалаDB - Спеціалізованих часовий ряд баз даних. виявилося, що Натисніть Будинокнавіть без оптимізації під такі завдання, виграє і на чужому полі:

В часовий ряд зазвичай використовується вузька таблиця – кілька маленьких колонок. З моніторингу може надходити дуже багато даних, - мільйони записів на секунду, - і зазвичай вони надходять маленькими вставками (реального часу стрімінгом). Тому потрібен інший сценарій вставки, а самі запити зі своєю деякою специфікою.

Управління Вхід. Збір логів у БД - це зазвичай погано, але в Натисніть Будинок це можна робити з деякими коментарями, як описано вище. Багато компаній використовують Натисніть Будинок саме для цього. У цьому випадку використовується широка плоска таблиця, де ми зберігаємо логи цілком (наприклад, у вигляді JSON), або нарізаємо на частини. Дані завантажуються зазвичай великими батчами (файлами), а шукаємо яким-небудь полем.

Для кожної з цих функцій зазвичай використовують спеціалізовані БД. Натисніть Будинок один може робити це все і настільки добре, що обганяє їх за продуктивністю. Давайте тепер докладно розглянемо часовий ряд сценарій і як правильно «готувати» Натисніть Будинок під цей сценарій.

Часовий ряд

На даний момент це основний сценарій, для якого Натисніть Будинок вважається стандартним рішенням. Часовий ряд — це набір упорядкованих у часі подій, які становлять зміни якогось процесу у часі. Наприклад, це може бути частота серцебиття за день або кількість процесів у системі. Все, що дає тимчасові тики з якимись вимірами – це часовий ряд:

Найбільше таких подій приходить з моніторингу. Це може бути не тільки моніторинг Інтернету, а й реальних пристроїв: автомобілів, промислових систем, IoT, виробництв або безпілотних таксі, в багажник яких Яндекс уже зараз кладе Натисніть Будинок-Сервер.

Наприклад, є компанії, які збирають дані із судів. Кожні кілька секунд датчики з контейнеровозу відправляють сотні різних вимірів. Інженери їх вивчають, будують моделі та намагаються зрозуміти, наскільки ефективно використовується судно, бо контейнеровоз не повинен простоювати жодної секунди. Будь-який простий - це втрата грошей, тому важливо спрогнозувати маршрут так, щоб стоянки були мінімальними.

Наразі спостерігається зростання спеціалізованих БД, які вимірюють часовий ряд. На сайті БД-двигуни якимось чином ранжуються різні бази даних, і їх можна подивитися за типами:

Найшвидше зростаючий тип time-series. Також ростуть графові БД, але time-series ростуть швидше за останні кілька років. Типові представники БД цієї родини - це InfluxDB, Прометей, КДБ, Часовий шкалаDB (побудована на PostgreSQL), рішення від Amazon. Натисніть Будинок тут також може бути використаний і він використовується. Наведу кілька громадських прикладів.

Один із піонерів — компанія CloudFlare (CDN-провайдер). Вони моніторять свій CDN через Натисніть Будинок (DNS-запити, HTTP-Запити) з величезним навантаженням - 6 мільйонів подій в секунду. Все йде через Кафка, вирушає в Натисніть Будинок, який надає можливість у реальному часі бачити дашборди подій у системі.

Comcast — один із лідерів телекомунікацій у США: інтернет, цифрове телебачення, телефонія. Вони створили аналогічну систему управління CDN у рамках Open Source проекту Apache Traffic Control до роботи зі своїми величезними даними. Натисніть Будинок використовується як бекенд для аналітики.

Перкона вбудували Натисніть Будинок всередину свого ПММ, щоб зберігати моніторинг різних MySQL.

Специфічні вимоги

До time-series баз даних є свої специфічні вимоги.

• Швидка вставка з багатьох агентів. Ми повинні дуже швидко вставити дані з багатьох потоків. Натисніть Будинок добре це робить, тому що у нього всі вставки, що не блокують. Будь-який вставити - це новий файл на диску, а маленькі вставки можна буферизувати тим чи іншим способом. У Натисніть Будинок краще вставляти дані великими пакетами, а не по одному рядку.
• Гнучка схема. У часовий ряд зазвичай ми не знаємо структуру даних до кінця. Можна побудувати систему моніторингу для конкретної програми, але тоді її важко використовувати для іншої програми. Для цього потрібна гнучкіша схема. Натисніть Будинокдозволяє це зробити, навіть незважаючи на те, що це строго типізована база.
• Ефективне зберігання та «забуття» даних. Зазвичай у часовий ряд гігантський обсяг даних, тому їх слід зберігати максимально ефективно. Наприклад, у InfluxDB Хороша компресія - це його головна фішка. Але крім зберігання, потрібно ще вміти та «забувати» старі дані та робити якийсь пониження тиску - Автоматичний підрахунок агрегатів.
• Швидкі запити агрегованих даних. Іноді цікаво подивитися останні 5 хвилин з точністю до мілісекунд, але на місячних даних хвилинна чи секундна гранулярність може бути не потрібна – достатньо загальної статистики. Підтримка такого роду необхідна, інакше запит за 3 місяці виконуватиметься дуже довго навіть у Натисніть Будинок.
• Запити типу «останній пункт, як of». Це типові для часовий ряд запити: дивимося останній вимір або стан системи в момент часу t. Для БД це не дуже приємні запити, але їх також треба вміти виконувати.
• «Склеювання» часових рядів. Часовий ряд - Це тимчасовий ряд. Якщо є два часових ряди, їх часто потрібно з'єднувати і корелювати. Не на всіх БД це зручно робити, особливо з невирівняними тимчасовими рядами: тут одні тимчасові засічки, там інші. Можна вважати середні, але раптом там все одно буде дірка, тож незрозуміло.

Давайте подивимося, як ці вимоги виконуються в Натисніть Будинок.

Схема

В Натисніть Будинок схему для часовий ряд можна зробити різними способами, залежно від рівня регулярності даних. Можна побудувати систему на регулярних даних, коли ми знаємо всі метрики заздалегідь. Наприклад, так зробив CloudFlare з моніторингом CDN - Це добре оптимізована система. Можна побудувати загальнішу систему, яка моніторить всю інфраструктуру, різні послуги. У разі нерегулярних даних, ми не знаємо заздалегідь, що моніторимо — і, мабуть, це загальний випадок.

Регулярні дані Колонки. Схема проста - колонки з потрібними типами:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Це звичайна таблиця, яка моніторить якусь активність із завантаження системи (користувач, система, холостому ходу, приємно). Просто та зручно, але не гнучко. Якщо хочемо більш гнучку схему, можна використовувати масиви.

Нерегулярні дані. Масиви:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Структура Вкладений - Це два масиви: metrics.name и metrics.value. Тут можна зберігати такі довільні моніторингові дані, як масив назв та масив вимірювань при кожній події. Для подальшої оптимізації замість такої структури можна зробити кілька. Наприклад, одну - для плавати-значення, іншу - для Int-значення, тому що Int хочеться зберігати ефективніше.

Але до такої структури важче звертатися. Прийде використовувати спеціальну конструкцію, через спеціальні функції витягувати значення спочатку індексу, а потім масиву:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Але це все одно працює досить швидко. Інший спосіб зберігання нерегулярних даних – рядками.

Нерегулярні дані. Рядки. У цьому традиційному способі без масивів зберігаються одразу назви та значення. Якщо з одного пристрою приходить одразу 5 000 вимірювань – генерується 5 000 рядків у БД:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

Натисніть Будинок з цим справляється — має спеціальні розширення Натисніть Будинок SQL. наприклад, maxIf - Спеціальна функція, яка вважає максимум за метрикою при виконанні якоїсь умови. Можна в одному запиті написати кілька таких виразів і відразу порахувати значення кількох метрик.

Порівняємо три підходи:

Деталі

Тут я додав «Розмір даних на диску» для тестового набору даних. У випадку з колонками у нас найменший розмір даних: максимальне стискування, максимальна швидкість запитів, але ми платимо тим, що повинні все відразу зафіксувати.

У випадку з масивами все трохи гірше. Дані однаково добре стискаються, і можна зберігати нерегулярну схему. Але Натисніть Будинок — колонкова база даних, а коли ми починаємо зберігати все у масиві, то вона перетворюється на рядкову, і ми платимо за гнучкість ефективністю. На будь-яку операцію доведеться прочитати весь масив на згадку, після цього знайти в ньому потрібний елемент — а якщо масив зростає, то швидкість деградує.

В одній із компаній, яка використовує такий підхід (наприклад, Убер), масиви нарізаються на шматочки зі 128 елементів. Дані кількох тисяч метрик обсягом в 200 ТБ даних/на день зберігаються не в одному масиві, а в 10 або 30 масивах зі спеціальною логікою для зберігання.

Максимально простий підхід – з рядками. Але дані погано стискаються, розмір таблиці виходить великий, та ще й коли запити йдуть за кількома метриками, то ClickHouse працює неоптимально.

Гібридна схема

Припустимо, що ми вибрали схему із масивом. Але якщо ми знаємо, що більшість наших дашбордів показують лише метрики user та system, ми можемо додатково з масиву на рівні таблиці матеріалізувати ці метрики в колонки таким чином:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

При вставці Натисніть Будинок автоматично їх порахує. Так можна поєднати приємне з корисним: схема гнучка і загальна, але найчастіше використовувані колонки ми витягли. Зауважу, що це не вимагало змінювати вставку та ETL, який продовжує вставляти таблицю масиви. Ми просто зробили ALTER TABLE, додали пару колонок і вийшла гібридна і швидша схема, якою можна відразу починати користуватися.

Кодеки та компресія

Для часовий ряд важливо, наскільки добре ви пакувати дані, тому що масив інформації може бути дуже великий. У Натисніть Будинок є набір засобів досягнення ефекту компресії 1:10, 1:20, котрий іноді більше. Це означає, що невпаковані дані обсягом 1 ТБ на диску займають 50-100 ГБ. Менший розмір – це добре, дані швидше можна прочитати та обробити.

Для досягнення високого рівня компресії, Натисніть Будинок підтримує такі кодеки:

Приклад таблиці:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Тут ми визначаємо кодек DoubleDelta в одному випадку, в другому - горила, і обов'язково додаємо ще LZ4 компресію. В результаті розмір даних на диску значно зменшується:

Тут показано, скільки місця займають ті самі дані, але при використанні різних кодеків і компресій:

• у GZIP'ованому файлі на диску;
• у ClickHouse без кодеків, але з ZSTD-компресією;
• в ClickHouse з кодеками та компресією LZ4 та ZSTD.

Видно, що таблиці з кодеками займають набагато менше місця.

Розмір має значення

Не менш важливо вибрати правильний тип даних:

У всіх прикладах вище я використав Поплавок64. Але якби ми обрали Поплавок32, то це було б навіть краще. Це добре продемонстрували хлопці з Перкони у статті на посилання вище. Важливо використовувати максимально компактний тип, що підходить під завдання: навіть меншою мірою для розміру на диску, ніж для швидкості запитів. Натисніть Будинок дуже до цього чутливий.

Якщо ви можете використовувати int32 замість int64Очікуйте майже дворазове збільшення продуктивності. Дані займають менше пам'яті, і вся «арифметика» працює набагато швидше. Натисніть Будинок у собі дуже суворо типізована система, він максимально використовує всі можливості, які надають сучасні системи.

Агрегація та Матеріалізовані погляди

Агрегація та матеріалізовані уявлення дозволяють зробити агрегати на різні випадки життя:

Наприклад, у вас можуть бути не агреговані вихідні дані, і на них можна навісити різні матеріалізовані уявлення з автоматичним підсумовуванням через спеціальний двигун SummingMergeTree (SMT). SMT — це спеціальна структура даних, що агрегує, яка вважає агрегати автоматично. У базу даних вставляються сирі дані, вони автоматично агрегуються, і відразу можна використовувати дашборди.

TTL — «забуваємо» старі дані

Як "забувати" дані, які більше не потрібні? Натисніть Будинок вміє це. Під час створення таблиць можна вказати TTL вирази: наприклад, що хвилинні дані зберігаємо один день, денні - 30 днів, а тижневі або місячні не чіпаємо ніколи:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Багаторівневий - розділяємо дані по дисках

Розвиваючи цю ідею, дані можна зберігати в Натисніть Будинок в різних місцях. Припустимо, гарячі дані за останній тиждень хочемо зберігати на дуже швидкому локальному SSD, А більш історичні дані складаємо в інше місце. У Натисніть Будинок зараз це можливо:

Можна змінити політику зберігання (політика зберігання) так що Натисніть Будинок автоматично перекладатиме дані щодо досягнення деяких умов в інше сховище.

Але це ще не все. На рівні конкретної таблиці можна визначити правила, коли саме час дані переходять на холодне зберігання. Наприклад, 7 днів дані лежать дуже швидкому диску, проте, що старше, переноситься на повільний. Це добре тим, що дозволяє систему тримати на максимальній продуктивності, при цьому контролюючи витрати та не витрачаючи кошти на холодні дані:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Унікальні можливості Натисніть Будинок

Майже у всьому Натисніть Будинок є такі «родзинки», але вони нівелюються ексклюзивом — тим, чого немає в інших БД. Наприклад, ось деякі з унікальних функцій Натисніть Будинок:

• Масиви. У Натисніть Будинок дуже хороша підтримка для масивів, і навіть можливість виконувати ними складні обчислення.
• Агрегуючі структури даних. Це одна з «кілер-фіч» Натисніть Будинок. Незважаючи на те, що хлопці з Яндекса кажуть, що ми не хочемо агрегувати дані, всі агрегують у Натисніть Будиноктому що це швидко і зручно.
• Матеріалізовані уявлення. Разом з структурами даних, що агрегують, матеріалізовані уявлення дозволяють робити зручну. реального часу агрегацію.
• ClickHouse SQL. Це розширення мови SQL з деякими додатковими та ексклюзивними фічами, які є тільки в Натисніть Будинок. Раніше це було ніби з одного боку розширення, а з іншого — недолік. Зараз майже всі недоліки в порівнянні з SQL 92 ми прибрали, тепер це лише розширення.
• Лямбда-Вирази. Чи є вони ще в якійсь базі даних?
• ML-підтримка. Це є в різних БД, у якихось кращих, у якихось гірших.
• Відкритий код. Ми можемо розширювати Натисніть Будинок разом. Зараз в Натисніть Будинок близько 500 контриб'ютерів, і це число постійно зростає.

Хитрі запити

В Натисніть Будинок є багато різних способів зробити те саме. Наприклад, можна трьома різними способами повернути останнє значення з таблиці центральний процесор (є ще й четвертий, але він ще екзотичніший).

Перший показує, як зручно робити в Натисніть Будинок запити, коли ви хочете перевіряти, що кортеж міститься у підзапиті. Це те, чого мені особисто не вистачало в інших БД. Якщо я хочу щось порівняти із підзапитом, то в інших БД з ним можна порівнювати лише скаляр, а для кількох колонок треба писати РЕЄСТРАЦІЯ. У Натисніть Будинок можна використовувати tuple:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Другий спосіб робить те саме, але використовує агрегатну функцію argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В Натисніть Будинок є кілька десятків агрегатних функцій, а якщо використовувати комбінатори, то за законами комбінаторики вийде близько тисячі. ArgMax - Одна з функцій, яка вважає максимальне значення: запит повертає значення usage_user, на якому досягається максимальне значення створено_у:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF JOIN — «склеювання» рядів з різним часом. Це унікальна функція для баз даних, яка є тільки в kdb+. Якщо є два тимчасові ряди з різним часом, ASOF JOIN дозволяє їх змістити та склеїти в одному запиті. Для кожного значення в одному часовому ряду знаходиться найближче значення в іншому, і вони повертаються на одному рядку:

Аналітичні функції

У стандарті SQL-2003 можна писати так:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В Натисніть Будинок так не можна - він не підтримує стандарт SQL-2003 і, мабуть, ніколи не робитиме це. Натомість у Натисніть Будинок прийнято писати так:

Я обіцяв лямбди – ось вони!

Це аналог аналітичного запиту у стандарті SQL-2003: він вважає різницю між двома timestamp, durationпорядковий номер - все, що зазвичай ми вважаємо аналітичними функціями. У Натисніть Будинок ми їх рахуємо через масиви: спочатку згортаємо дані до масиву, після цього на масиві робимо все, що хочемо, а потім розвертаємо назад. Це не дуже зручно, вимагає любові до функціонального програмування як мінімум, але це дуже гнучко.

спеціальні функції

Крім того, Натисніть Будинок багато спеціалізованих функцій. Наприклад, як визначити, скільки сесій відбувається одночасно? Типове завдання моніторингу – визначити максимальне завантаження одним запитом. У Натисніть Будинок є спеціальна функція для цієї мети:

Взагалі, для багатьох цілей у ClickHouse є спеціальні функції:

• runningDifference, runningAccumulate, neighbor;
• sumMap(key, value);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

Це не повний перелік функцій, всього їх 500-600. Хінт: всі функції в Натисніть Будинок є в системній таблиці (не всі документовані, але всі цікаві):

select * from system.functions order by name

Натисніть Будинок сам у собі зберігає багато інформації про себе, у тому числі log tables, журнал_запитів, лог трасування, лог операції з блоками даних (part_log), лог метрик, та системний лог, який він зазвичай пише на диск. Лог метрик – це часовий ряд в Натисніть Будинок на самому Натисніть Будинок: БД сама для себе може грати роль часовий ряд баз даних, в такий спосіб «пожираючи» себе.

Це теж унікальна річ — якщо ми добре робимо роботу для часовий ряд, Чому не можемо самі в собі зберігати все, що потрібно? Нам не потрібний ПрометейМи зберігаємо все в собі. Підключили Grafana і самі себе моніторимо. Однак, якщо Натисніть Будинок впаде, то ми не побачимо, чому, тому зазвичай так не роблять.

Великий кластер чи багато маленьких Натисніть Будинок

Що краще – один великий кластер чи багато маленьких ClickHouse? Традиційний підхід до DWH — це великий кластер, у якому виділяються схеми під кожну програму. Ми прийшли до адміністратора БД – дайте нам схему, і нам її видали:

В Натисніть Будинок можна зробити це інакше. Можна кожному додатку зробити свій власний Натисніть Будинок:

Нам більше не потрібний великий монструозний DWH і незговірливі адміни. Ми можемо кожному додатку видати свій власний Натисніть Будинок, і розробник може це зробити сам, оскільки Натисніть Будинок дуже просто встановлюється і не вимагає складного адміністрування:

Але якщо у нас багато Натисніть Будинокі треба часто його ставити, то хочеться цей процес автоматизувати. Для цього можна, наприклад, використовуємо Кубернетес и clickhouse-оператор. У Kubernetes ClickHouse можна поставити "по клацанню": я можу натиснути кнопку, запустити маніфест і база готова. Можна відразу ж створити схему, почати туди вантажити метрики, і за 5 хвилин у мене вже готовий дашборд Grafana. Так все просто!

Що в підсумку?

Отже, Натисніть Будинок - це:

• швидко. Це всім відомо.
• просто. Трохи спірно, але я вважаю, що важко у навчанні, легко у бою. Якщо зрозуміти, як Натисніть Будинок працює, далі все дуже просто.
• універсально. Він підходить для різних сценаріїв: DWH, Time Series, Log Storage. Але це не OLTP база даних, тому не намагайтеся зробити там короткі вставки та читання.
• Цікаво. Напевно, той, хто працює з Натисніть Будинок, пережив багато цікавих хвилин у хорошому та поганому сенсі. Наприклад, вийшов новий реліз, перестало працювати. Або коли ви билися над завданням два дні, але після питання у Телеграм-чаті завдання вирішилося за дві хвилини. Або як на конференції на доповіді Леші Міловідова скріншот з Натисніть Будинок зламав трансляцію HighLoad ++. Такі речі відбуваються постійно і роблять наше життя з Натисніть Будинок яскравою та цікавою!

Презетацію можна переглянути тут.

Довгоочікувана зустріч розробників високонавантажених систем HighLoad ++ відбудеться 9 та 10 листопада у Сколковому. Нарешті це буде офлайн-конференція (хоч і з дотриманням усіх запобіжних заходів), оскільки енергію HighLoad++ неможливо упаковати в онлайн.

Для конференції ми знаходимо та показуємо вам кейси про максимальні можливості технологій: HighLoad++ був, є і буде єдиним місцем, де можна за два дні дізнатися, як влаштовані Facebook, Яндекс, ВКонтакті, Google та Amazon.

Проводячи наші зустрічі без перерви з 2007 року, цього року ми зустрінемося в 14-те. За цей час конференція зросла у 10 разів, торік ключову подію галузі зібрало 3339 учасників, 165 спікерів доповідей та мітапів, а одночасно йшло 16 треків.
Минулого року для вас було 20 автобусів, 5280 літрів чаю та кави, 1650 літрів морсів та 10200 пляшечок води. А ще 2640 кілограмів їжі, 16 000 тарілок та 25 000 стаканчиків. До речі, на гроші, отримані від переробленого паперу, ми посадили 100 саджанців дуба 🙂

Квитки можна купити тут, отримати новини про конференцію тут, а поговорити - у всіх соцмережах: Telegram, Facebook, Vkontakte и Twitter.

Джерело: habr.com