ClickHouse: не сегодня

После месяцев экспериментов с ClickHouse отставляем в сторону. Не срослось, подождём ещё.
Прежде всего следует объяснить.
Во-первых, до этих экспериментов была изучена документация, был прочёсан интернет, были сделаны первые пробы. Про ограничения базы мы знали [ещё год назад], но решили проверить на практике, насколько нам (софту, процессам, людям) терпима та или иная особенность.
Во-вторых, интересно было поработать не только с аналитикой и бигдатой, но также и пощупать привычные сценарии. Что-то пощупали сами, что-то вычитали в чате и решили грабли обойти. На некоторые понаступали сознательно, измеряя толщину шишки.
В общем, если у вас при чтении возникнет желание сказать мне, что ClickHouse нидляэтава, не надо. Я знаю. ClickHouse сознательно прикручивался не только по прямому назначению. Получили в какой-то мере ожидаемый результат, зато теперь объективно знаем, с чем можем жить, а с чем не хотим.

Информации не хватает со старта. Вы ставите базу, заливаете первые десятки миллионов записей, выполняете простой SELECT и… он медленнее текущего решения в несколько раз. Т.к. «ClickHouse не тормозит», пытаетесь избавиться от тормоза в руках. Но как? Документация всё ещё декларативна. Она неплохо описывает то, что есть в базе, но не отвечает на вопросы «как?», «зачем?» и «почему?»
Учебников нет. Курсов нет. Доклады на конфах на такие вопросы обычно ответов не содержат. Community ещё крайне мало и не успело нагенерировать фигалиарды ответов на все вопросы. Исходник у ClickHouse в целом понятный и местами даже красивый, но вы точно хотите проводить обеды в листании тысяч строк на C++? Остаётся только чат: t.me. Он хороший и интересный, особенно когда народ новые билды пробует, но основным источником быть не может, да и не должен.
Потому сидишь и часами бьёшься бабочком об лампочку, перебирая варианты и в сотый раз перечитывая документацию вслух с выражением. А ежедневное чтение чата приводит к диалогам вроде «давай эту штуку не юзать, я чёт такое нехорошее про неё неделю назад читал от того бойца, что… блин, забыл, кароч, что там у него было, но у него не получилось».

Чтобы построить минимальный кластер ClickHouse, требуется пять машин: 2xClickHouse, 3xZooKeeper.
Этот показатель (количество машин) тоже важен, когда вы сравниваете траты и профиты на решение задач. Если база X при 10 машинах отдаёт данные по запросу S за 50ms, а база Y на 5 машинах по тому же S за 60ms, задумаешься. Это очень примитивный пример, но демонстрирует.
Другой показатель: количество разного софта. В одной схеме у вас на 10 машинах стоят 10 инстансов софта X, в другой схеме на 10 машинах 5 инстансов A, 3 инстанса B и 2 инстанса C. Разница в первую очередь заметна эксплуатации (админам, девопсам), но и разработчики не всегда рады, прямо скажем.

У ClickHouse было и осталось некоторое эмпирическое правило: вставлять по одной строке плохо, брать одну строку плохо. Ну т.е. медленно. В идеале бомбить пачками от тысячи строк.
Если вы не можете обеспечить без бубна эту пачечность, приходится ставить оный. Обычным уже решением Kafka. Источники в неё льют так, как получается, а на выходе стоит скрипт, который с некоторой периодичностью (раз в секунду, например) выгребает накопленное и льёт в ClickHouse. Казалось бы, ну ладно. Но помните про кластер 2xCH + 3xZK? Добавляем к нему минимальный 3xKafka, используя в целях уплотнения имеющий ZK. Уже восемь машин.
Можно бы пойти прямым путём: есть Buffer engine, вроде ровно то, что надо? Ну… Прочтите текст по ссылке внимательнее. С такими особенностями работы более прямым путём всё-таки кажется вариант с Kafka.
Особым местом оказывается и то, что переливает из Kafka в ClickHouse. В нашем варианте это простейший Python-скрипт, но у меня хватает фантазии, чтобы в будущем из этого скрипта вырос микросервис, сам по себе являющийся потенциальной точкой отказа. Не воодушевило.

Почти отсутствуют UPDATE и DELETE. Ещё недавно я бы не добавлял слово «почти», но дело сдвинулось с мёртвой точки и теперь есть ALTER TABLE DELETE, пусть и «in beta stage» — уже ништяк! Но чёт как-то… Да, у нас есть данные, которые иногда приходится менять, пусть эти данные в теории и не должны меняться. Мир живой, люди живые, сплошь мутации и т.п. Реальность лупит теорию по голове и после пяти шаманств по изменению (фактически переналивались) захотелось больше так не жить.
С вариантом извращения в ситуации, когда UPDATE отсутствует, но очень хочется, можно познакомиться здесь. Вот тоже не воодушевило.

Нет транзакций и в целом не очень понятно, какие гарантии и чего есть. Мы смелые и сердцем молодые, потому последний месяц наблюдали за ClickHouse, в который лились важные (те, что вот должны сохраняться, а если что, так откатить сохранение в случае ошибки) данные с production’а. И знаете… мне не очень понравился этот месяц.
MongoDB вам даёт «транзакцию» на уровне документа (про 4.0 пока не будем). Elastic тоже на уровне документа, если не ошибаюсь. Про всякие MygrescleSQL с их ACID и так все знают. Если база в ответ на INSERT мне ответила 200 OK, я спокойно переворачиваюсь на другой бок и сплю дальше. Если ClickHouse ответил мне 200 OK, хоть убейте, а сна нет. В общем случае я понятия не имею, сохранятся ли мои данные. Обычно сохраняются, но могут же и не.
Да, это привычно бойцам из мира аналитических баз и вообще бигдаты, ну а мне тревожно.

Тут россыпью всякое.
Внезапным камнем в ботинке оказался insert_quorum. Сначала мы хотели при INSERT в инстанс-A тут же убеждаться, что отреплицировалось в инстанс-B, но всё сломалось уже на этапе миграции данных в ClickHouse. Если слишком быстро писать в несколько потоков, начинаются (как я понял) конфликты вида «я тут ещё не отреплицировал, а ты уже новое сбоку подкидываешь». В итоге insert_quorum выключили, что плохо. В чате потом ещё был народ с такой же проблемой, решения пока нет, окромя как лить в один поток.
Нет EXPLAIN. Хороший инструмент для анализа узких место в запросах, а нема. Есть со стороны совет включить trace и читать логи, но я пока не созрел для того, чтобы на production’е трейсы оставлять. Смотреть на test / dev некоторые запросы смысла нет, современные планировщики учитывают и развёрнутые кэши, и статистику запросов и остальное, что вне боевой нагрузки в состоянии бутончика.
Всё так же пока нет окружения из удобных, наглядных и стабильных инструментов. Ткнёшься в угол, а там либо пусто, либо снова переписывают. Мне бы хотелось из DataGrip, но нет (впроечем, уже делают, если не ошибаюсь). Вроде мелочь, да и суровым постсоветским разработчикам хоть топором запросы делай, но таки хочется больше цивилизации с мещанскими окошками, кнопочками и графиками.
Индексы побаливают. Я привык к тому, что в MysgrecleSQL или в MongoDB накинул на десяток полей индексов и всё, живи, радуйся. В ClickHouse сложнее. У вас не получится использовать индексы произвольно. Технически говоря, отсутствуют secondary indexes, потому шаг влево-вправо вполне приводит к деградации скорости ответа.

Что в итоге? ClickHouse для big data, где big начинается с миллиардов строк и сотен гигабайтов. С этой планки вас начинают интересовать уже другие запросы (и они в ClickHouse отлично работают). До этой планки ClickHouse совершенно не нужен и даже вреден. Ничем иным, кроме как прям вот большими данными с только лишь аналитикой в ClickHouse ехать не следует. Транзакции, индексы, изменение данных, точечные запросы — все эти штуки из другого мира. Вернее, ClickHouse из другого мира.
Раньше я это понимал головой, ну а теперь и руками. Ну ок, будем ждать, вдруг база станет ближе повседневности. Появился же DELETE.

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]. Может, кому полезным будет зачем-то.