ClickHouse: Зачем

Два англичанина ловят рыбу в Темзе. У одного дергается поплавок, он подсекает и вытаскивает прелестную русалку. Полюбовавшись ею, снимает русалку с крючка и бросает обратно в воду. Второй удивляется:
Но почему?
Но как?

ClickHouse — штука коварная. В первый час мануалов и докладов думаешь «ого… ого! дайте две! нет, три! десять!» Потом узнаёшь про ограничения и глубоко задумываешься и впадаешь в уныние.
Самое важное, что следует запомнить и понять — эта база данных делалась не для вас и не для ваших задач. Заказчик и потребитель, как понимаю, — Яндекс.Метрика. Потому на все вопросы категории «а почему нет такой-то фичи?» ответ один: потому, что это не требуется Яндекс.Метрике. Весь список ограничений ниже упирается в этот ответ. А вот если ваша задача схожа с их задачей (наливать жополиард логов и натравливать аналитиков), всё будет хорошо.
Потому не получится взять свою базу, лежащую в каком-нибудь MySQL / PostgreSQL / OracleSQL, и плавно перелить в ClickHouse. Хоть убейтесь. И логику вашего приложения не получится так перенести. Вообще ничего не получится сделать плавно. Схемы данных надо будет заново спроектировать, приложения заново написать.

Во-первых, в ClickHouse используется свой диалект SQL. Можете выкинуть все свои ORM, например. А если возникнет светлая идея пропатчить и подпилить, эту идею тоже выкидывайте, т.к. не просто диалект SQL, но очень обрезанный диалект.
Во-вторых, судя по замерам тех, кто уже попробовал, и в самом деле заливать данные надо пачками (от тысячи строк за операцию), иначе всё работает очччень медленно. Соответственно, перед базой требуется костылить буферизацию. Если игнорировать это правило, можно получить здорово просевшую и не отвечающую на запросы базу. А, ну и да, рекомендуют не более одного такого INSERT в секунду.
В-третьих, нет UPDATE и DELETE. Единственный прямой способ удалять записи заключается в удалении целых разделов записей помесячно (через DROP PARTITION). Соответственно, все варианты запросов, в которых могло фигурировать изменение данных, тоже не работают. Жалею, что не был на встречах, на которых будущие авторы ClickHouse говорят друг другу что-то типа «неее, ну нам не надо изменять данные, фича явно не первой нужды». Правда, вроде как хоть какая поддержка заявлена на реализацию в 2018 году. Но вообще жесть, конечно. В базу можно заливать только стабилизированные данные, например, логи. А если вы собираетесь лить статистику от того же Яндекс.Директа (которая может уточняться в любой момент, особенно последние три дня), привет костылям.
В-четвёртых, нет NULL. Вернее, их нет в привычном виде. Будут в конце 2017 года. И снова вызывает некоторое недоумение эта лакуна. Словно сознательно выпиливали из ТЗ ровно то, что помогло бы мигрировать на ClickHouse. Хотите большего веселья? Ахаха, у нас нет NULL!
В-пятых, нет коррелированных подзапросов. Учтите, если у вас работа с базой сложнее среднего. С другой стороны, over dofiga приложений с базой работают на уровне «сохрани яблочко, верни яблочко», потому недостаток для тех, кто.
В-шестых, репликация есть, но (если не углубляться в детали) на уровне данных, а не схемы. Иными словами и привычными терминами, если на master дропнут таблицу, slave и не почешется (на деле в ClickHouse репликация multi-master, потому slave тут для упрощения). Также занятный нюанс: репликация через ZooKeeper. Если он вдруг ляжет, ваши таблицы превратятся в read-only тыкву.
В-седьмых, множество других ограничений. Если вы используете движок таблиц, отличный от *MergeTree, внимательно читайте мануал, часть фич (от индексов до ALTER) может отсутствовать. Если используете USING, внимательно читайте мануал, многое обрезано. UNION DISTINCT не поддерживается. В общем, хождение по минному полю.

Такие вот дела. Как обычно, полного счастья не бывает.
Хочется надеяться, что быстрым ClickHouse получился не потому, что авторы отказались от того, что есть в других базах и вместо «мы сделали самую быструю базу» надо читать «мы сделали самое быстрое чтение неизменяемых данных». Хочется поиграть в ван Винкля и проснуться эдак в 2019 году, когда Яндекс и сообщество превратят ClickHouse в более универсальный продукт. Но нет. Надо сейчас, потому посты о вкусе кактуса не за горами.

ClickHouse: Начало

Предположим, у вас есть данные. Большие данные. Ну или не очень большие — сто миллионов документов с парой сотен свойств уже норма. Норма также и то, что вы немножко утомитесь делать какую-либо быструю аналитику / агрегацию этих данных в «обычных базах данных». В необычных тоже утомитесь, если речь идёт о миллиардах документов / записей. И тут на сцену выходит ClickHouse.
Большая часть ссылок есть на сайте ClickHouse, часть я выловил гуглением. Выловил больше, но отфильтровал бесполезные (слишком мало информации или слишком маркетинговая или слишком клон другого текста).

Пока с мануалами не очень, есть только один официальный.
Статей особо нет, книг нет, ничего альтернативного толком нет.
Мануал — очевидно, must read. Кто мануалы не читает, сам себе буратинка.
Репозиторий — стоит посматривать, чтобы понимать, какие баги, куда идёт прогресс, ну и упороться в плюсовый исходник, если спать не хочется.
Google Groups — в среднем несколько сообщений в день, есть интересное. Хороший запасной вариант поиска решения проблем и ответов на первые вопросы.
wiki/ClickHouse — можно сказать, заметно более развёрнутый вариант этого поста, попутно пересказ части документации. Больше ссылок.
stackoverflow.com/clickhouse — очень вялое место без заметного движняка. Десятка три вопросов, большинство с одним ответом.

Каких-либо особо полезных для разработчика видео тоже в открытом доступе пока не существует. Вот ваще ничего, прямо скажем. С трудом наскрёб четыре ролика.
ClickHouse — как сделать самую быструю распределённую аналитическую СУБД — ноябрь 2016 года, часовой доклад от одного из авторов о том, почему и зачем придуман и сделан ClickHouse. Посмотреть стоит для того, чтобы не видеть в ClickHouse ещё одну RDBMS или Cassandra или Hadoop. Также немного истории, архитектуры, бенчмарков и т.п.
ClickHouse — прошлое, настоящее, будущее — март 2017 года, 40 минут основной коммитер ClickHouse докладывает об успехах разработки за прошедший квартал. Можно не смотреть, видео с практической точки бесполезно, но можно и посмотреть, зарядиться позитивом.
ClickHouse визуально: Быстрый и наглядный анализ данных в Tabix — апрель 2017 года. 33 минуты смеси из 1) описания проблемы, 2) истории успеха, 3) беглый обзор фронтов к ClickHouse, 4) описание своего решения. Хороший, годный доклад.
ClickHouse Yandex — Анализируем данные — январь 2017 года, Сигач(е|ё)в А. в Орле делится опытом перехода с MySQL на ClickHouse, всего 25 минут. Больше подходит в истории успеха, обычный для многих кейс — привычные базы не справляются даже с объёмами средней руки (пусть даже они смешные на фоне big data от больших игроков), а надо гонять миллионы строк, при этом не раскатывать мегатонну серверов. Скучновато, лаконично, но на безрыбье.

Истории успеха — специальный жанр «документации». В нём можно найти как мотивацию с аргументацией (вот! вот! вот у чуваков такой же кейс, у них всё получилось, а мы живём на гуано!), так и описание граблей, по которым прошлись первограблепроходцы. И если вам мало того, что на базе ClickHouse живёт Яндекс.Метрика, то вот ещё истории.
Переезжаем на Yandex ClickHouse — декабрь 2016 года, доклад на HighLoad++. Если сподручнее читать, на Хабре есть расшифровка.
О ClickHouse — 140 миллионов записей. Сравнение с InfluxDB и с PostgreSQL. В финале три полезные ремарки о граблях.
Как запустить ClickHouse своими силами и выиграть джекпот — десятки миллиардов записей. Сравнение с InfluxDB, Cassandra и Druid. Примеры работы, упоминание своего софта и т.д.

PS. Позабавила статья. Хороший пример того, как из обычной практики обычных разработчиков / девопсов (ну и текст обычный — развернуть софт) может появиться вот прям СТАТЬЯ за тройным авторством — [Феофантов К.В., Терских М.Г., Афанасьев Г.И. Развертывание кластера для хранения и обработки статистики с помощью Yandex Clickhouse // Современные научные исследования и инновации. 2016. № 12]. Может, кому полезным будет зачем-то.