mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-04 13:32:13 +00:00
67c2e50331
* update presentations * CLICKHOUSE-2936: redirect from clickhouse.yandex.ru and clickhouse.yandex.com * update submodule * lost files * CLICKHOUSE-2981: prefer sphinx docs over original reference * CLICKHOUSE-2981: docs styles more similar to main website + add flags to switch language links * update presentations * Less confusing directory structure (docs -> doc/reference/) * Minify sphinx docs too * Website release script: fail fast + pass docker hash on deploy * Do not underline links in docs * shorter * cleanup docker images * tune nginx config * CLICKHOUSE-3043: get rid of habrastorage links * Lost translation * CLICKHOUSE-2936: temporary client-side redirect * behaves weird in test * put redirect back * CLICKHOUSE-3047: copy docs txts to public too * move to proper file * remove old pages to avoid confusion * Remove reference redirect warning for now * Refresh README.md * Yellow buttons in docs * Use svg flags instead of unicode ones in docs * fix test website instance * Put flags to separate files * wrong flag * Copy Yandex.Metrica introduction from main page to docs * Yet another home page structure change, couple new blocks (CLICKHOUSE-3045) * Update Contacts section * CLICKHOUSE-2849: more detailed legal information * CLICKHOUSE-2978 preparation - split by files * More changes in Contacts block * Tune texts on index page * update presentations * One more benchmark * Add usage sections to index page, adapted from slides * Get the roadmap started, based on slides from last ClickHouse Meetup * CLICKHOUSE-2977: some rendering tuning * Get rid of excessive section in the end of getting started * Make headers linkable * CLICKHOUSE-2981: links to editing reference - https://github.com/yandex/ClickHouse/issues/849 * CLICKHOUSE-2981: fix mobile styles in docs * Ban crawling of duplicating docs * Open some external links in new tab * Ban old docs too * Lots of trivial fixes in english docs * Lots of trivial fixes in russian docs * Remove getting started copies in markdown * Add Yandex.Webmaster * Fix some sphinx warnings * More warnings fixed in english docs * More sphinx warnings fixed * Add code-block:: text * More code-block:: text * These headers look not that well * Better switch between documentation languages * merge use_case.rst into ya_metrika_task.rst * Edit the agg_functions.rst texts * Add lost empty lines * Lost blank lines * Add new logo sizes * update presentations * Next step in migrating to new documentation * Fix all warnings in en reference * Fix all warnings in ru reference * Re-arrange existing reference * Move operation tips to main reference * Fix typos noticed by milovidov@ * Get rid of zookeeper.md * Looks like duplicate of tutorial.html * Fix some mess with html tags in tutorial * No idea why nobody noticed this before, but it was completely not clear whet to get the data * Match code block styling between main and tutorial pages (in favor of the latter) * Get rid of some copypaste in tutorial * Normalize header styles * Move example_datasets to sphinx * Move presentations submodule to website * Move and update README.md * No point in duplicating articles from habrahabr here * Move development-related docs as is for now * doc/reference/ -> docs/ (to match the URL on website) * Adapt links to match the previous commit * Adapt development docs to rst (still lacks translation and strikethrough support) * clean on release * blacklist presentations in gulp * strikethrough support in sphinx * just copy development folder for now * fix weird introduction in style article * Style guide translation (WIP) * Finish style guide translation to English * gulp clean separately * Update year in LICENSE * Initial CONTRIBUTING.md * Fix remaining links to old docs in tutorial * Some tutorial fixes * Typo * Another typo * Update list of authors from yandex-team accoding to git log
83 lines
5.9 KiB
ReStructuredText
83 lines
5.9 KiB
ReStructuredText
AggregatingMergeTree
|
||
--------------------
|
||
|
||
Отличается от MergeTree тем, что при слиянии, выполняет объединение состояний агрегатных функций, хранимых в таблице, для строчек с одинаковым значением первичного ключа.
|
||
|
||
Чтобы это работало, используются: тип данных AggregateFunction, а также модификаторы -State и -Merge для агрегатных функций. Рассмотрим подробнее.
|
||
|
||
Существует тип данных AggregateFunction. Это параметрический тип данных. В качестве параметров передаются: имя агрегатной функции, затем типы её аргументов.
|
||
Примеры:
|
||
|
||
.. code-block:: sql
|
||
|
||
CREATE TABLE t
|
||
(
|
||
column1 AggregateFunction(uniq, UInt64),
|
||
column2 AggregateFunction(anyIf, String, UInt8),
|
||
column3 AggregateFunction(quantiles(0.5, 0.9), UInt64)
|
||
) ENGINE = ...
|
||
|
||
Столбец такого типа хранит состояние агрегатной функции.
|
||
|
||
Чтобы получить значение такого типа, следует использовать агрегатные функции с суффиксом ``State``.
|
||
Пример: ``uniqState(UserID), quantilesState(0.5, 0.9)(SendTiming)`` - в отличие от соответствующих функций uniq, quantiles, такие функции возвращают не готовое значение, а состояние. То есть, значение типа AggregateFunction.
|
||
|
||
Значение типа AggregateFunction нельзя вывести в Pretty-форматах. В других форматах, значения такого типа выводятся в виде implementation-specific бинарных данных. То есть, значения типа AggregateFunction не предназначены для вывода, сохранения в дамп.
|
||
|
||
Единственную полезную вещь, которую можно сделать со значениями типа AggregateFunction - это объединить состояния и получить результат, по сути - доагрегировать до конца. Для этого используются агрегатные функции с суффиксом Merge.
|
||
Пример: ``uniqMerge(UserIDState), где UserIDState имеет тип AggregateFunction``.
|
||
|
||
То есть, агрегатная функция с суффиксом Merge берёт множество состояний, объединяет их, и возвращает готовый результат.
|
||
Для примера, эти два запроса возвращают один и тот же результат:
|
||
|
||
.. code-block:: sql
|
||
|
||
SELECT uniq(UserID) FROM table
|
||
|
||
SELECT uniqMerge(state) FROM (SELECT uniqState(UserID) AS state FROM table GROUP BY RegionID)
|
||
|
||
Существует движок ``AggregatingMergeTree``. Он занимается тем, что при слияниях, выполняет объединение состояний агрегатных функций из разных строчек таблицы с одним значением первичного ключа.
|
||
|
||
В таблицу, содержащую столбцы типа AggregateFunction невозможно вставить строчку обычным запросом INSERT, так как невозможно явно указать значение типа AggregateFunction. Вместо этого, для вставки данных, следует использовать INSERT SELECT с агрегатными функциями -State.
|
||
|
||
При SELECT-е из таблицы AggregatingMergeTree, используйте GROUP BY и агрегатные функции с модификатором -Merge, чтобы доагрегировать данные.
|
||
|
||
Таблицы типа AggregatingMergeTree могут использоваться для инкрементальной агрегации данных, в том числе, для агрегирующих материализованных представлений.
|
||
|
||
Пример:
|
||
Создаём материализованное представление типа AggregatingMergeTree, следящее за таблицей test.visits:
|
||
|
||
.. code-block:: sql
|
||
|
||
CREATE MATERIALIZED VIEW test.basic
|
||
ENGINE = AggregatingMergeTree(StartDate, (CounterID, StartDate), 8192)
|
||
AS SELECT
|
||
CounterID,
|
||
StartDate,
|
||
sumState(Sign) AS Visits,
|
||
uniqState(UserID) AS Users
|
||
FROM test.visits
|
||
GROUP BY CounterID, StartDate;
|
||
|
||
Вставляем данные в таблицу test.visits. Данные будут также вставлены в представление, где они будут агрегированы:
|
||
|
||
.. code-block:: sql
|
||
|
||
INSERT INTO test.visits ...
|
||
|
||
Делаем SELECT из представления, используя GROUP BY, чтобы доагрегировать данные:
|
||
|
||
.. code-block:: sql
|
||
|
||
SELECT
|
||
StartDate,
|
||
sumMerge(Visits) AS Visits,
|
||
uniqMerge(Users) AS Users
|
||
FROM test.basic
|
||
GROUP BY StartDate
|
||
ORDER BY StartDate;
|
||
|
||
Вы можете создать такое материализованное представление и навесить на него обычное представление, выполняющее доагрегацию данных.
|
||
|
||
Заметим, что в большинстве случаев, использование ``AggregatingMergeTree`` является неоправданным, так как можно достаточно эффективно выполнять запросы по неагрегированным данных.
|