Обычно описание того, как начать пользоваться каким-либо новым ПО начинается с пошаговой инструкции по установке, такая инструкция есть и на официальном сайте ClickHouse. При помощи данной инструкции вы легко можете развернуть у себя ClickHouse установив пакеты из репозитория или просто запустить контейнер в Docker.

Действительно, поставить ClickHouse на Ubuntu-based дистрибутив (пакеты ClickHouse универсальны и также подходят для Debian) не составляет никакого труда, вот пример из официальной документации:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E0C56BD4    # optional

sudo apt-add-repository "deb http://repo.yandex.ru/clickhouse/xenial stable main"
sudo apt-get update
sudo apt-get install clickhouse-server-common clickhouse-client -y
sudo service clickhouse-server start
clickhouse-client

Однако, частой ошибкой является то, что ClickHouse пытаются использовать не по назначению. ClickHouse является колоночной СУБД и применить опыт работы с традиционными СУБД не получится.

На самом деле тут всё неоднозначно. Большинство колоночных (или столбцовых, как вам удобнее) СУБД предоставляют обычный синтаксис SQL для работы с данными, более того среди популярных решений есть те, кто работает по стандартному протоколу популярных СУБД. Примером этого может быть Vertica и Greenplum Database работающие по протоколу PostgreSQL и предоставляющие PostgreSQL совместимый (достаточно совместимый) синтаксис SQL.

Поэтому, несмотря на заявление о том, что “ClickHouse не тормозит”, если вы всё же соберётесь использовать его как обычную СУБД для OLTP запросов — “тормозить” он у вас будет, а может и просто упасть и не подавать признаков жизни.

Отличительные особенности колоночных СУБД

Обычные, хранящие данные построчно, СУБД и колоночные базы данных очень сильно отличаются как способом хранения (что уже ясно из названия), так и задачами которые они выполняют, причем именно задачами и обусловлен выбор способа хранения и доступа к данным, подробнее об этом можно почитать в статье Эволюция структур данных в Яндекс.Метрике.

Обычно колоночные СУБД ещё называют “Аналитическими” СУБД, в виду частого применения последних именно для выполнения аналитических запросов. Соответственно и профиль нагрузки у таких СУБД отличается от традиционных, если в традиционные СУБД редко и мало пишем, часто читаем относительно небольшое количество данных то для колоночных всё наоборот — данных поступает и пишется много, запросы не частые и обрабатывают большое количество данных. Из-за того, что объемы данных обрабатываемые колоночными СУБД огромны и они постоянно растут такие СУБД разрабатываются так, чтоб они могли максимально эфективно и быстро обрабатывать огромные объёмы данных, для этого они могут выполнять запрос как на нескольких машинах, так и пытаться распараллелить выполнение внутри одной (обычно выполняются оба условия). Зная это легко понять почему колоночные СУБД не могут быть заменой традиционным СУБД. Если взять PostgreSQL за пример традиционной СУБД, а ClickHouse за пример колоночной, то порядок будет примерно таким: PostgreSQL способен обрабатывать десятки тысяч запросов в секунду, в то время как ClickHouse пару сотен.

Если отличиями всё более менее понятно то можно переходить к ограничениям ClickHouse.

Ограничения ClickHouse.

Целостность данных.

Если вы привыкли к тому что СУБД представляет вам возможности для ограничения целостности и без этого вы никак не можете жить или просто плохо спите то у меня для вас плохие новости — ClickHouse таких возможностей не предоставляет.

Согласованность в конечном счёте.

По умолчанию репликация данных асинхронная и, по понятным причинам, не гарантирует что прочитанные данные актуальны. На самом деле здесь нет никакого отличия от любых других СУБД использующих асинхронную репликацию, однако, если у вас кластер, состоящий из нескольких шардов, вы можете или даже скорее будете получать различный результат на один и тот е запрос. Такая ситуация возможна, когда у вас в шарде (сервер/сервера хранящие определенный, не полный, объем данных) есть несколько реплик и Distributed-таблица отправляет запросы на разные узлы кластера.

SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011.

Нет, у ClickHouse свой диалект SQL, для простых запросов он схож с привычным, но многое отсутствует, однако он также обладает рядом возможностей которых нет в стандартном SQL.

Обновление и удаление данных.

На данный момент операций UPDATE/DELETE в ClickHouse нет. В ближайшем будущем они появятся, но пользоваться ими как в обычных СУБД не получится. Эти операции должны выполнятся редко, т.к. требуют изменения больших объёмов данных, а также отсутствие транзакций делает их необратимыми.

Запись данных.

В отличии от традиционных СУБД в ClickHouse нельзя (можно, но это чревато проблемами) делать частые вставки данных, это обусловлено особенностями реализации. Когда происходит вставка данных через HTTP или нативный протокол данные обрабатываются и в ClickHouse попадает блок данных который, в фоне, сервер должен будет смержить с кусками данных которые уже есть на диске, именно эта операция и является затратной. Как только сервер перестает успевать обработать в фоне все полученные куски данных он отказывается принимать новые данные.

PS

ClickHouse во многом является отличным выбором позволяющим строить системы для обработки любых объемов данных с возможностью делать это в реальном времени. Знание особенностей и понимание ограничений ClickHouse позволяет делать эти системы надежными и удобными в эксплуатации.