: - Значение по умолчанию для подстановки на пустые позиции.
- Длина результирующего массива. Например, если вы хотите получать массисы одинакового размера для всех агрегатных ключей. При использовании этого параметра значение по умолчанию задавать обязательно.
- Значение по умолчанию для подстановки на пустые позиции.
- Длина результирующего массива. Например, если вы хотите получать массисы одинакового размера для всех агрегатных ключей. При использовании этого параметра значение по умолчанию задавать обязательно.
groupUniqArray(x)
-----------------
...
...
@@ -209,8 +209,8 @@ quantileTiming(level)(x)
Иначе:
: - если время меньше 1024 мс., то вычисление точное.
- иначе вычисление идёт с округлением до числа, кратного 16 мс.
- если время меньше 1024 мс., то вычисление точное.
- иначе вычисление идёт с округлением до числа, кратного 16 мс.
При передаче в функцию отрицательных значений, поведение не определено.
@@ -5,10 +5,10 @@ ClickHouse содержит встроенную возможность рабо
Это позволяет:
: - для идентификатора региона получить его имя на нужном языке;
- по идентификатору региона получить идентификатор города, области, федерального округа, страны, континента;
- проверить, что один регион входит в другой;
- получить цепочку родительских регионов.
- для идентификатора региона получить его имя на нужном языке;
- по идентификатору региона получить идентификатор города, области, федерального округа, страны, континента;
- проверить, что один регион входит в другой;
- получить цепочку родительских регионов.
Все функции поддерживают "транслокальность", то есть возможность использовать одновременно разные точки зрения на принадлежность регионов. Подробнее смотрите в разделе "Функции для работы со словарями Яндекс.Метрики".
...
...
@@ -27,15 +27,15 @@ ClickHouse содержит встроенную возможность рабо
: 1. Имя поля (аргумент функции) должно быть константой;
2. Считается, что имя поля в JSON-е закодировано некоторым каноническим образом. Например, `visitParamHas('{"abc":"def"}', 'abc') = 1`, но `visitParamHas('{"\\u0061\\u0062\\u0063":"def"}', 'abc') = 0`
3. Поля ищутся на любом уровне вложенности, без разбора. Если есть несколько подходящих полей - берётся первое.
4. В JSON-е нет пробельных символов вне строковых литералов.
1. Имя поля (аргумент функции) должно быть константой;
2. Считается, что имя поля в JSON-е закодировано некоторым каноническим образом. Например, `visitParamHas('{"abc":"def"}', 'abc') = 1`, но `visitParamHas('{"\\u0061\\u0062\\u0063":"def"}', 'abc') = 0`
3. Поля ищутся на любом уровне вложенности, без разбора. Если есть несколько подходящих полей - берётся первое.
4. В JSON-е нет пробельных символов вне строковых литералов.
@@ -59,10 +59,10 @@ cat file.csv | clickhouse-client --database=test --query="INSERT INTO test FORMA
При выполнении запроса, клиент показывает:
: 1. Прогресс выполнение запроса, который обновляется не чаще, чем 10 раз в секунду (по умолчанию). При быстрых запросах, прогресс может не успеть отобразиться.
2. Отформатированный запрос после его парсинга - для отладки.
3. Результат в заданном формате.
4. Количество строк результата, прошедшее время, а также среднюю скорость выполнения запроса.
1. Прогресс выполнение запроса, который обновляется не чаще, чем 10 раз в секунду (по умолчанию). При быстрых запросах, прогресс может не успеть отобразиться.
2. Отформатированный запрос после его парсинга - для отладки.
3. Результат в заданном формате.
4. Количество строк результата, прошедшее время, а также среднюю скорость выполнения запроса.
Вы можете прервать длинный запрос, нажав Ctrl+C. При этом вам всё равно придётся чуть-чуть подождать, пока сервер остановит запрос. На некоторых стадиях выполнения, запрос невозможно прервать. Если вы не дождётесь и нажмёте Ctrl+C второй раз, то клиент будет завершён.
В по-настоящему столбцовой СУБД рядом со значениями не хранится никакого "мусора". Например, должны поддерживаться значения постоянной длины, чтобы не хранить рядом со значениями типа "число" их длины. Для примера, миллиард значений типа UInt8 должен действительно занимать в несжатом виде около 1GB, иначе это сильно ударит по эффективности использования CPU. Очень важно хранить данные компактно (без "мусора") в том числе в несжатом виде, так как скорость разжатия (использование CPU) зависит, в основном, от объёма несжатых данных.
...
...
@@ -10,29 +8,24 @@
Также стоит заметить, что ClickHouse является СУБД, а не одной базой данных. То есть, ClickHouse позволяет создавать таблицы и базы данных в runtime, загружать данные и выполнять запросы без переконфигурирования и перезапуска сервера.
Сжатие данных
-------------
## Сжатие данных
Некоторые столбцовые СУБД (InfiniDB CE, MonetDB) не используют сжатие данных. Но сжатие данных действительно серьёзно увеличивает производительность.
Хранение данных на диске
------------------------
## Хранение данных на диске
Многие столбцовые СУБД (SAP HANA, Google PowerDrill) могут работать только в оперативке. Но оперативки (даже на тысячах серверах) слишком мало для хранения всех хитов и визитов в Яндекс.Метрике.
Параллельная обработка запроса на многих процессорных ядрах
## Распределённая обработка запроса на многих серверах
Почти все перечисленные ранее столбцовые СУБД не поддерживают распределённую обработку запроса.
В ClickHouse данные могут быть расположены на разных шардах. Каждый шард может представлять собой группу реплик, которые используются для отказоустойчивости. Запрос будет выполнен на всех шардах параллельно. Это делается прозрачно для пользователя.
Поддержка SQL
-------------
## Поддержка SQL
Если вы знаете, что такое стандартный SQL, то говорить о поддержке SQL всё-таки нельзя.
Не поддерживаются NULL-ы. Все функции названы по-другому.
...
...
@@ -40,35 +33,29 @@
Поддерживаются JOIN-ы. Поддерживаются подзапросы в секциях FROM, IN, JOIN, а также скалярные подзапросы.
Зависимые подзапросы не поддерживаются.
Векторный движок
----------------
## Векторный движок
Данные не только хранятся по столбцам, но и обрабатываются по векторам - кусочкам столбцов. За счёт этого достигается высокая эффективность по CPU.
Обновление данных в реальном времени
------------------------------------
## Обновление данных в реальном времени
ClickHouse поддерживает таблицы с первичным ключом. Для того, чтобы можно было быстро выполнять запросы по диапазону первичного ключа, данные инкрементально сортируются с помощью merge дерева. За счёт этого, поддерживается постоянное добавление данных в таблицу. Блокировки при добавлении данных отсутствуют.
Наличие индексов
----------------
## Наличие индексов
Наличие первичного ключа позволяет, например, вынимать данные для конкретных клиентов (счётчиков Метрики), для заданного диапазона времени, с низкими задержками - менее десятков миллисекунд.
Подходит для онлайн запросов
----------------------------
## Подходит для онлайн запросов
Это позволяет использовать систему в качестве бэкенда для веб-интерфейса. Низкие задержки позволяют не откладывать выполнение запроса, а выполнять его в момент загрузки страницы интерфейса Яндекс.Метрики. То есть, в режиме онлайн.
Поддержка приближённых вычислений
---------------------------------
## Поддержка приближённых вычислений
1. Система содержит агрегатные функции для приближённого вычисления количества различных значений, медианы и квантилей.
2. Поддерживается возможность выполнить запрос на основе части (выборки) данных и получить приближённый результат. При этом, с диска будет считано пропорционально меньше данных.
3. Поддерживается возможность выполнить агрегацию не для всех ключей, а для ограниченного количества первых попавшихся ключей. При выполнении некоторых условий на распределение ключей в данных, это позволяет получить достаточно точный результат с использованием меньшего количества ресурсов.
Репликация данных, поддержка целостности данных на репликах
## Репликация данных, поддержка целостности данных на репликах
Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке".
Подробнее смотрите раздел [Репликация данных](../../table_engines/replication.html#table_engines-replication).
@@ -14,11 +14,11 @@ ClickHouse на данный момент обеспечивает рабту [
Также ClickHouse используется:
: - для хранения данных Вебвизора;
- для обработки промежуточных данных;
- для построения глобальных отчётов Аналитиками;
- для выполнения запросов в целях отладки движка Метрики;
- для анализа логов работы API и пользовательского интерфейса.
- для хранения данных Вебвизора;
- для обработки промежуточных данных;
- для построения глобальных отчётов Аналитиками;
- для выполнения запросов в целях отладки движка Метрики;
- для анализа логов работы API и пользовательского интерфейса.
ClickHouse имеет более десятка инсталляций в других отделах Яндекса: в Вертикальных сервисах, Маркете, Директе, БК, Бизнес аналитике, Мобильной разработке, AdFox, Персональных сервисах и т п.
...
...
@@ -29,14 +29,14 @@ ClickHouse имеет более десятка инсталляций в дру
Но агрегированные данные являются очень ограниченным решением, по следующим причинам:
: - вы должны заранее знать перечень отчётов, необходимых пользователю;
- то есть, пользователь не может построить произвольный отчёт;
- при агрегации по большому количеству ключей, объём данных не уменьшается и агрегация бесполезна;
- при большом количестве отчётов, получается слишком много вариантов агрегации (комбинаторный взрыв);
- при агрегации по ключам высокой кардинальности (например, URL) объём данных уменьшается не сильно (менее чем в 2 раза);
- из-за этого, объём данных при агрегации может не уменьшиться, а вырасти;
- пользователи будут смотреть не все отчёты, которые мы для них посчитаем - то есть, большая часть вычислений бесполезна;
- возможно нарушение логической целостности данных для разных агрегаций;
- вы должны заранее знать перечень отчётов, необходимых пользователю;
- то есть, пользователь не может построить произвольный отчёт;
- при агрегации по большому количеству ключей, объём данных не уменьшается и агрегация бесполезна;
- при большом количестве отчётов, получается слишком много вариантов агрегации (комбинаторный взрыв);
- при агрегации по ключам высокой кардинальности (например, URL) объём данных уменьшается не сильно (менее чем в 2 раза);
- из-за этого, объём данных при агрегации может не уменьшиться, а вырасти;
- пользователи будут смотреть не все отчёты, которые мы для них посчитаем - то есть, большая часть вычислений бесполезна;
- возможно нарушение логической целостности данных для разных агрегаций;
Как видно, если ничего не агрегировать, и работать с неагрегированными данными, то это даже может уменьшить объём вычислений.
: - из текущей БД или из БД db, если указано FROM db;
- всех, или имя которых соответствует шаблону pattern, если указано LIKE 'pattern';
- из текущей БД или из БД db, если указано FROM db;
- всех, или имя которых соответствует шаблону pattern, если указано LIKE 'pattern';
Запрос полностью аналогичен запросу: `SELECT name FROM system.tables WHERE database = 'db' [AND name LIKE 'pattern'] [INTO OUTFILE filename] [FORMAT format]`
Существует несколько способов получения полностью "схлопнутых" данных из таблицы типа `CollapsingMergeTree`:
: 1. Написать запрос с GROUP BY и агрегатными функциями, учитывающими знак. Например, чтобы посчитать количество, надо вместо count() написать sum(Sign); чтобы посчитать сумму чего-либо, надо вместо sum(x) написать sum(Sign \* x) и т. п., а также добавить HAVING sum(Sign) `>` 0. Не все величины можно посчитать подобным образом. Например, агрегатные функции min, max не могут быть переписаны.
2. Если необходимо вынимать данные без агрегации (например, проверить наличие строк, самые новые значения которых удовлетворяют некоторым условиям), можно использовать модификатор FINAL для секции FROM. Это вариант существенно менее эффективен.
1. Написать запрос с GROUP BY и агрегатными функциями, учитывающими знак. Например, чтобы посчитать количество, надо вместо count() написать sum(Sign); чтобы посчитать сумму чего-либо, надо вместо sum(x) написать sum(Sign \* x) и т. п., а также добавить HAVING sum(Sign) `>` 0. Не все величины можно посчитать подобным образом. Например, агрегатные функции min, max не могут быть переписаны.
2. Если необходимо вынимать данные без агрегации (например, проверить наличие строк, самые новые значения которых удовлетворяют некоторым условиям), можно использовать модификатор FINAL для секции FROM. Это вариант существенно менее эффективен.
Виртуальные столбцы отличаются от обычных следующими особенностями:
: - они не указываются в определении таблицы;
- в них нельзя вставить данные при INSERT-е;
- при INSERT-е без указания списка столбцов, виртуальные столбцы не учитываются;
- они не выбираются при использовании звёздочки (`SELECT *`);
- виртуальные столбцы не показываются в запросах `SHOW CREATE TABLE` и `DESC TABLE`;
- они не указываются в определении таблицы;
- в них нельзя вставить данные при INSERT-е;
- при INSERT-е без указания списка столбцов, виртуальные столбцы не учитываются;
- они не выбираются при использовании звёздочки (`SELECT *`);
- виртуальные столбцы не показываются в запросах `SHOW CREATE TABLE` и `DESC TABLE`;
Таблица типа Merge содержит виртуальный столбец _table типа String. (Если в таблице уже есть столбец _table, то виртуальный столбец называется _table1; если уже есть _table1, то _table2 и т. п.) Он содержит имя таблицы, из которой были прочитаны данные.
: - совпадение структур таблиц локально и на всех указанных шардах.
- наличие на локальном сервере свободного места в количестве, равном размеру партиции в байтах, с запасом в 10%.
- наличие на всех репликах всех указанных шардов, кроме являющейся локальной, если такая есть, свободного места в количестве равном размеру партиции, домноженном на отношение веса шарда к суммарному весу, с запасом в 10%.
- совпадение структур таблиц локально и на всех указанных шардах.
- наличие на локальном сервере свободного места в количестве, равном размеру партиции в байтах, с запасом в 10%.
- наличие на всех репликах всех указанных шардов, кроме являющейся локальной, если такая есть, свободного места в количестве равном размеру партиции, домноженном на отношение веса шарда к суммарному весу, с запасом в 10%.
Далее, асинхронное выполнение задачи состоит из следующих шагов:
: 1. Нарезка партиции на кусочки на локальном сервере.
1. Нарезка партиции на кусочки на локальном сервере.
Для этого делается слияние всех кусков, входящих в партицию и, одновременно, разбиение их на несколько, согласно ключу шардирования.
Результат складывается в директорию /reshard в директории с данными таблицы.
Исходные куски никак не модифицируются и весь процесс не влияет на рабочие данные таблицы.
2. Копирование всех кусков на удалённые серверы (на каждую реплику соответствующих шардов).
3. Выполнение запроса ALTER TABLE t DROP PARTITION на локальном сервере, выполнение запросов ALTER TABLE t ATTACH PARTITION на всех шардах.
2. Копирование всех кусков на удалённые серверы (на каждую реплику соответствующих шардов).
3. Выполнение запроса ALTER TABLE t DROP PARTITION на локальном сервере, выполнение запросов ALTER TABLE t ATTACH PARTITION на всех шардах.
Замечание: это делается неатомарно. Есть момент времени, в течение которого пользователь может увидеть отсутствие данных партиции.
В случае указания в запросе слова COPY, исходные данные не удаляются. Это подходит для копирования данных с одного кластера на другой с одновременным изменением схемы шардирования.
4. Удаление временных данных с локального сервера.
4. Удаление временных данных с локального сервера.
При наличии нескольких запросов на перешардирование, соответствующие задачи будут делаться последовательно.
