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: Зачем: 4 комментария

  1. Это очень узкоспециализированная база данных. Именно поэтому она и показывает такие крутые результаты в тестах. Если вы хотите работать с базой через ORM, то это совсем не про ClickHouse 🙂

    • Да как-то одно другому не мешает. Текущая проблема лишь в том, что ORM для ClickHouse надо писать индивидуально, ну и полноценного CRUD пока нет.

      • Сомневаюсь, что ClickHouse когда-нибудь станет универсальным продуктом. В таком случае он рискует потерять то, ради чего разрабатывался: мгновенную агрегацию огромного пласта информации.
        Кстати, у них есть движок CollapsingMergeTree, которым мы и пользуемся в тех случаях, когда нужно перезаписать часть логов. Для других движков разработали оператор, изменяющий конкретные записи через перезаливание партиции. Не очень удобно в разработке, зато очень быстро в использовании.

      • Ему и не требуется быть универсальным продуктом. Достаточно, чтобы хоть в каком удобоваримом виде появились операции, которые очень часто встречаются в разработке.
        Ну и отмечу, что ORM относится не к универсальности, а то мы как-то стартовый контекст теряем. 😉

Добавить комментарий