mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-23 10:10:50 +00:00
Merge pull request #740 from BayoNet/master
Description of distributed_product_mode was added.
This commit is contained in:
alexey-milovidov
GitHub
commit
1db9a73059
@ -84,8 +84,14 @@
|
||||
|
||||
Для продакшен использования, указывайте только элементы вида ip (IP-адреса и их маски), так как использование host и host_regexp может вызывать лишние задержки.
|
||||
|
||||
Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - default. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
|
||||
Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - ``default``. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
|
||||
|
||||
Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
|
||||
|
||||
Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию.
|
||||
|
||||
Доступ к БД ``system`` всегда считается разрешённым (так как эта БД используется для выполнения запросов).
|
||||
|
||||
Пользователь может получить список всех БД и таблиц в них с помощью запросов ``SHOW`` или системных таблиц, даже если у него нет доступа к отдельным ДБ.
|
||||
|
||||
Доступ к БД не связан с настройкой :ref:`query_complexity_readonly`. Невозможно дать полный доступ к одной БД и ``readonly`` к другой.
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _configuration_files:
|
||||
|
||||
Конфигурационные файлы
|
||||
======================
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
Словарь может полностью храниться в оперативке и периодически обновляться, или быть частично закэшированным в оперативке и динамически подгружать отсутствующие значения.
|
||||
|
||||
Конфигурация внешних словарей находится в отдельном файле или файлах, указанных в конфигурационном параметре dictionaries_config.
|
||||
Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы * и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/*.xml.
|
||||
Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы \* и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/\*.xml.
|
||||
|
||||
Конфигурация словарей, а также множество файлов с конфигурацией, может обновляться без перезапуска сервера. Сервер проверяет обновления каждые 5 секунд. То есть, словари могут подключаться динамически.
|
||||
|
||||
@ -68,6 +68,18 @@
|
||||
Для отказоустойчивости, вы можете создать Distributed таблицу на localhost и прописать её. - ->
|
||||
-->
|
||||
|
||||
<!-- Для <mysql> и <clickhouse> доступен атрибут <where>, позволяющий задать условие выбора
|
||||
<clickhouse>
|
||||
<host>example01-01-1</host>
|
||||
<port>9000</port>
|
||||
<user>default</user>
|
||||
<password></password>
|
||||
<db>default</db>
|
||||
<table>ids</table>
|
||||
<where>id=10</where>
|
||||
</clickhouse>
|
||||
-->
|
||||
|
||||
<!-- или источник - исполняемый файл. Если layout.cache - список нужных ключей будет записан в поток STDIN программы -->
|
||||
<executable>
|
||||
<!-- Путь или имя программы (если директория есть в переменной окружения PATH) и параметры -->
|
||||
@ -139,6 +151,14 @@
|
||||
<!-- Можно считать отображение id -> attribute инъективным, чтобы оптимизировать GROUP BY. (по умолчанию, false) -->
|
||||
<injective>true</injective>
|
||||
</attribute>
|
||||
|
||||
<!-- Атрибут может быть выражением -->
|
||||
<attribute>
|
||||
<name>expr</name>
|
||||
<type>UInt64</type>
|
||||
<expression>rand64()</expression>
|
||||
<null_value>0</null_value>
|
||||
</attribute>
|
||||
</structure>
|
||||
</dictionary>
|
||||
</dictionaries>
|
||||
@ -167,16 +187,21 @@ range_hashed
|
||||
------------
|
||||
В таблице прописаны какие-то данные для диапазонов дат, для каждого ключа. Дать возможность доставать эти данные для заданного ключа, для заданной даты.
|
||||
|
||||
Пример: в таблице записаны скидки для каждого рекламодателя в виде:
|
||||
::
|
||||
|
||||
id рекламодателя дата начала действия скидки дата конца величина
|
||||
123 2015-01-01 2015-01-15 0.15
|
||||
123 2015-01-16 2015-01-31 0.25
|
||||
456 2015-01-01 2015-01-15 0.05
|
||||
Пример: таблица содержит скидки для каждого рекламодателя в виде:
|
||||
|
||||
Добавляем layout = range_hashed.
|
||||
При использовании такого layout, в structure должны быть элементы range_min, range_max.
|
||||
+------------------+-----------------------------+------------+----------+
|
||||
| id рекламодателя | дата начала действия скидки | дата конца | величина |
|
||||
+==================+=============================+============+==========+
|
||||
| 123 | 2015-01-01 | 2015-01-15 | 0.15 |
|
||||
+------------------+-----------------------------+------------+----------+
|
||||
| 123 | 2015-01-16 | 2015-01-31 | 0.25 |
|
||||
+------------------+-----------------------------+------------+----------+
|
||||
| 456 | 2015-01-01 | 2015-01-15 | 0.05 |
|
||||
+------------------+-----------------------------+------------+----------+
|
||||
|
||||
Добавляем ``layout = range_hashed``.
|
||||
При использовании такого layout, в structure должны быть элементы ``range_min``, ``range_max``.
|
||||
|
||||
Пример:
|
||||
|
||||
|
||||
@ -60,4 +60,4 @@ ClickHouse поддерживает таблицы с первичным клю
|
||||
14. Репликация данных, поддержка целостности данных на репликах.
|
||||
----------------------------------------------------------------
|
||||
Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке".
|
||||
Подробнее смотрите раздел "Репликация данных".
|
||||
Подробнее смотрите раздел :ref:`table_engines-replication`.
|
||||
|
||||
@ -65,9 +65,9 @@ CREATE TABLE
|
||||
|
||||
``MATERIALIZED expr``
|
||||
|
||||
Материализованное выражение. Такой столбец не может быть указан при INSERT-е, то есть, он всегда вычисляется.
|
||||
При INSERT-е без указания списка столбцов, такие столбцы не рассматриваются.
|
||||
Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём SELECT *, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
|
||||
Материализованное выражение. Такой столбец не может быть указан при INSERT, то есть, он всегда вычисляется.
|
||||
При INSERT без указания списка столбцов, такие столбцы не рассматриваются.
|
||||
Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём ``SELECT *``, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
|
||||
|
||||
``ALIAS expr``
|
||||
|
||||
@ -675,7 +675,7 @@ SELECT
|
||||
|
||||
``ARRAY JOIN`` - это, по сути, ``INNER JOIN`` с массивом. Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) CREATE TABLE arrays_test (s String, arr Array(UInt8)) ENGINE = Memory
|
||||
|
||||
@ -728,7 +728,7 @@ SELECT
|
||||
|
||||
Для массива в секции ARRAY JOIN может быть указан алиас. В этом случае, элемент массива будет доступен под этим алиасом, а сам массив - под исходным именем. Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) SELECT s, arr, a FROM arrays_test ARRAY JOIN arr AS a
|
||||
|
||||
@ -748,7 +748,7 @@ SELECT
|
||||
|
||||
В секции ARRAY JOIN может быть указано несколько массивов одинаковых размеров через запятую. В этом случае, JOIN делается с ними одновременно (прямая сумма, а не прямое произведение). Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) SELECT s, arr, a, num, mapped FROM arrays_test ARRAY JOIN arr AS a, arrayEnumerate(arr) AS num, arrayMap(x -> x + 1, arr) AS mapped
|
||||
|
||||
@ -784,7 +784,7 @@ SELECT
|
||||
|
||||
ARRAY JOIN также работает с вложенными структурами данных. Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) CREATE TABLE nested_test (s String, nest Nested(x UInt8, y UInt32)) ENGINE = Memory
|
||||
|
||||
@ -839,7 +839,7 @@ ARRAY JOIN также работает с вложенными структур
|
||||
|
||||
При указании имени вложенной структуры данных в ARRAY JOIN, смысл такой же, как ARRAY JOIN со всеми элементами-массивами, из которых она состоит. Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) SELECT s, nest.x, nest.y FROM nested_test ARRAY JOIN nest.x, nest.y
|
||||
|
||||
@ -859,7 +859,7 @@ ARRAY JOIN также работает с вложенными структур
|
||||
|
||||
Такой вариант тоже имеет смысл:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) SELECT s, nest.x, nest.y FROM nested_test ARRAY JOIN nest.x
|
||||
|
||||
@ -879,7 +879,7 @@ ARRAY JOIN также работает с вложенными структур
|
||||
|
||||
Алиас для вложенной структуры данных можно использовать, чтобы выбрать как результат JOIN-а, так и исходный массив. Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) SELECT s, n.x, n.y, nest.x, nest.y FROM nested_test ARRAY JOIN nest AS n
|
||||
|
||||
@ -899,7 +899,7 @@ ARRAY JOIN также работает с вложенными структур
|
||||
|
||||
Пример использования функции arrayEnumerate:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
:) SELECT s, n.x, n.y, nest.x, nest.y, num FROM nested_test ARRAY JOIN nest AS n, arrayEnumerate(nest.x) AS num
|
||||
|
||||
@ -962,7 +962,7 @@ JOIN-ы бывают нескольких видов:
|
||||
|
||||
Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
SELECT
|
||||
CounterID,
|
||||
@ -1033,7 +1033,7 @@ PREWHERE имеет смысл использовать, если есть ус
|
||||
|
||||
Например, полезно писать PREWHERE для запросов, которые вынимают много столбцов, но в которых фильтрация производится лишь по нескольким столбцам.
|
||||
|
||||
PREWHERE поддерживается только таблицами семейства *MergeTree.
|
||||
PREWHERE поддерживается только таблицами семейства ``*MergeTree``.
|
||||
|
||||
В запросе могут быть одновременно указаны секции PREWHERE и WHERE. В этом случае, PREWHERE идёт перед WHERE.
|
||||
|
||||
@ -1289,7 +1289,7 @@ n и m должны быть неотрицательными целыми чи
|
||||
Оператор IN и подзапрос могут встречаться в любой части запроса, в том числе в агрегатных и лямбда функциях.
|
||||
Пример:
|
||||
|
||||
.. code-block:: sql
|
||||
::
|
||||
|
||||
SELECT
|
||||
EventDate,
|
||||
@ -1316,11 +1316,17 @@ n и m должны быть неотрицательными целыми чи
|
||||
за каждый день после 17 марта считаем долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
|
||||
Подзапрос в секции IN на одном сервере всегда выполняется только один раз. Зависимых подзапросов не существует.
|
||||
|
||||
|
||||
.. _queries-distributed-subrequests:
|
||||
|
||||
Распределённые подзапросы
|
||||
"""""""""""""""""""""""""
|
||||
|
||||
Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный ``IN`` / ``JOIN`` и ``GLOBAL IN`` / ``GLOBAL JOIN``. Они отличаются способом выполнения при распределённой обработке запроса.
|
||||
|
||||
.. attention::
|
||||
Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от :ref:`настройки <settings-distributed_product_mode>` ``distributed_product_mode``.
|
||||
|
||||
При использовании обычного IN-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях ``IN`` / ``JOIN``.
|
||||
|
||||
При использовании ``GLOBAL IN`` / ``GLOBAL JOIN-а``, сначала выполняются все подзапросы для ``GLOBAL IN`` / ``GLOBAL JOIN-ов``, и результаты складываются во временные таблицы. Затем эти временные таблицы передаются на каждый удалённый сервер, и на них выполняются запросы, с использованием этих переданных временных данных.
|
||||
@ -1343,7 +1349,8 @@ n и m должны быть неотрицательными целыми чи
|
||||
|
||||
.. code-block:: sql
|
||||
|
||||
SELECT uniq(UserID) FROM local_table``
|
||||
SELECT uniq(UserID) FROM local_table
|
||||
|
||||
|
||||
, выполнен параллельно на каждом из них до стадии, позволяющей объединить промежуточные результаты; затем промежуточные результаты вернутся на сервер-инициатор запроса, будут на нём объединены, и финальный результат будет отправлен клиенту.
|
||||
|
||||
|
||||
@ -1,7 +1,22 @@
|
||||
Настройки
|
||||
==========
|
||||
|
||||
Здесь будут рассмотрены настройки, которые можно задать с помощью запроса SET или в конфигурационном файле. Напомню, что эти настройки могут быть выставлены в пределах сессии или глобально. Настройки, которые можно задать только в конфигурационном файле сервера, здесь рассмотрены не будут.
|
||||
Описанные в разделе настройки могут быть заданы следующими способами:
|
||||
* Глобально.
|
||||
|
||||
В конфигурационных файлах сервера.
|
||||
|
||||
* Для сессии.
|
||||
|
||||
При запуске консольного клиента ClickHouse в интерактивном режиме отправьте запрос ``SET setting=value``.
|
||||
|
||||
* Для запроса.
|
||||
|
||||
* При запуске консольного клиента ClickHouse в неинтерактивном режиме установите параметр запуска ``--setting=value``.
|
||||
* При использовании HTTP API передавайте cgi-параметры (``URL?setting_1=value&setting_2=value...``).
|
||||
|
||||
|
||||
Настройки, которые можно задать только в конфигурационном файле сервера, в разделе не рассматриваются.
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
|
||||
@ -15,6 +15,8 @@
|
||||
|
||||
``any (только для group_by_overflow_mode)`` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
|
||||
|
||||
.. _query_complexity_readonly:
|
||||
|
||||
readonly
|
||||
--------
|
||||
При значении 0 можно выполнять любые запросы.
|
||||
@ -90,7 +92,11 @@ result_overflow_mode
|
||||
Использование break по смыслу похоже на LIMIT.
|
||||
|
||||
max_execution_time
|
||||
<<<<<<< HEAD
|
||||
-------------------
|
||||
=======
|
||||
------------------
|
||||
>>>>>>> upstream/master
|
||||
Максимальное время выполнения запроса в секундах.
|
||||
На данный момент не проверяется при одной из стадий сортировки а также при слиянии и финализации агрегатных функций.
|
||||
|
||||
|
||||
@ -1,3 +1,47 @@
|
||||
.. _settings-distributed_product_mode:
|
||||
|
||||
distributed_product_mode
|
||||
------------------------
|
||||
Изменяет поведение :ref:`распределенных подзапросов <queries-distributed-subrequests>`, т.е. в тех случаях, когда запрос содержит произведение распределённых таблиц.
|
||||
|
||||
ClickHouse применяет настройку в том случае, когда в подзапросах на любом уровне встретилась распределенная таблица, которая существует на локальном сервере и имеет больше одного шарда.
|
||||
|
||||
Условия применения:
|
||||
|
||||
* Только подзапросы для IN, JOIN.
|
||||
* Только если в секции FROM используется распределённая таблица.
|
||||
* Не используется в случае табличной функции :ref:`remote <table_functions-remote>`.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
.. list-table::
|
||||
:widths: 20 80
|
||||
:header-rows: 1
|
||||
|
||||
* - Значение
|
||||
- Поведение ClickHouse
|
||||
* - ``deny`` (по умолчанию)
|
||||
- Генерирует исключение.
|
||||
* - ``allow``
|
||||
- Выполняет запрос без изменения логики.
|
||||
* - ``global``
|
||||
- Преобразует ``IN`` в ``GLOBAL IN``, ``JOIN`` в ``GLOBAL JOIN``.
|
||||
* - ``local``
|
||||
- Преобразует все вхождения Distributed-таблиц в соответствующие им удалённые таблицы.
|
||||
|
||||
|
||||
.. _settings-settings-fallback_to_stale_replicas_for_distributed_queries:
|
||||
|
||||
fallback_to_stale_replicas_for_distributed_queries
|
||||
--------------------------------------------------
|
||||
Форсирует запрос в устаревшую реплику в случае, если актуальные данные недоступны. Смотрите :ref:`table_engines-replication`.
|
||||
|
||||
Из устаревших реплик таблицы ClickHouse выбирает наиболее актуальную.
|
||||
|
||||
Используется при выполнении ``SELECT`` из распределенной таблицы, которая указывает на реплицированные таблицы.
|
||||
|
||||
По умолчанию - 1 (включена).
|
||||
|
||||
max_block_size
|
||||
--------------
|
||||
Данные в ClickHouse обрабатываются по блокам (наборам кусочков столбцов). Внутренние циклы обработки одного блока достаточно эффективны, но при этом существуют заметные издержки на каждый блок. ``max_block_size`` - это рекомендация, какого размера блоки (в количестве строк) загружать из таблицы. Размер блока должен быть не слишком маленьким, чтобы издержки на каждый блок оставались незаметными, и не слишком большим, чтобы запрос с LIMIT-ом, который завершается уже после первого блока, выполнялся быстро; чтобы не использовалось слишком много оперативки при вынимании большого количества столбцов в несколько потоков; чтобы оставалась хоть какая-нибудь кэш-локальность.
|
||||
@ -22,7 +66,21 @@ max_insert_block_size
|
||||
|
||||
``По умолчанию - 1 048 576.``
|
||||
|
||||
Это намного больше, чем max_block_size. Это сделано, потому что некоторые движки таблиц (*MergeTree) будут на каждый вставляемый блок формировать кусок данных на диске, что является довольно большой сущностью. Также, в таблицах типа *MergeTree, данные сортируются при вставке, и достаточно большой размер блока позволяет отсортировать больше данных в оперативке.
|
||||
Это намного больше, чем ``max_block_size``. Это сделано, потому что некоторые движки таблиц (``*MergeTree``) будут на каждый вставляемый блок формировать кусок данных на диске, что является довольно большой сущностью. Также, в таблицах типа ``*MergeTree``, данные сортируются при вставке, и достаточно большой размер блока позволяет отсортировать больше данных в оперативке.
|
||||
|
||||
|
||||
.. _settings_settings_max_replica_delay_for_distributed_queries:
|
||||
|
||||
max_replica_delay_for_distributed_queries
|
||||
------------------------------------------
|
||||
Отключает отстающие реплики при распределенных запросах. Смотрите :ref:`table_engines-replication`.
|
||||
|
||||
Устанавливает время в секундах. Если оставание реплики больше установленного значения, то реплика не используется.
|
||||
|
||||
Значение по умолчанию: 0 (отключено).
|
||||
|
||||
Используется при выполнении ``SELECT`` из распределенной таблицы, которая указывает на реплицированные таблицы.
|
||||
|
||||
|
||||
max_threads
|
||||
-----------
|
||||
@ -48,7 +106,7 @@ max_compress_block_size
|
||||
|
||||
min_compress_block_size
|
||||
-----------------------
|
||||
Для таблиц типа *MergeTree. В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min_compress_block_size. По умолчанию - 65 536.
|
||||
Для таблиц типа :ref:`MergeTree <table_engines-mergetree>`. В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min_compress_block_size. По умолчанию - 65 536.
|
||||
|
||||
Реальный размер блока, если несжатых данных меньше max_compress_block_size, будет не меньше этого значения и не меньше объёма данных на одну засечку.
|
||||
|
||||
@ -136,6 +194,8 @@ replace_running_query
|
||||
|
||||
Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить.
|
||||
|
||||
.. _settings-load_balancing:
|
||||
|
||||
load_balancing
|
||||
--------------
|
||||
На какие реплики (среди живых реплик) предпочитать отправлять запрос (при первой попытке) при распределённой обработке запроса.
|
||||
|
||||
91
docs/ru/table_engines/graphitemergetree.rst
Normal file
91
docs/ru/table_engines/graphitemergetree.rst
Normal file
@ -0,0 +1,91 @@
|
||||
GraphiteMergeTree
|
||||
-----------------
|
||||
|
||||
Движок предназначен для rollup (прореживания и агрегирования/усреднения) данных `Graphite <http://graphite.readthedocs.io/en/latest/index.html>`_. Он может быть интересен разработчикам, которые хотят использовать ClickHouse как хранилище данных для Graphite.
|
||||
|
||||
Graphite хранит в ClickHouse полные данные, а получать их может следующими способами:
|
||||
|
||||
* Без прореживания.
|
||||
|
||||
Используется движок :ref:`MergeTree <table_engines-mergetree>`.
|
||||
|
||||
* С прореживанием.
|
||||
|
||||
Используется движок ``GraphiteMergeTree``.
|
||||
|
||||
Движок наследует свойства `MergeTree`. Настройки прореживания данных размещаются в :ref:`общей конфигурации <configuration_files>` ClickHouse (config.xml).
|
||||
|
||||
Использование движка
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Таблица с данными Graphite должна содержать как минимум следующие поля:
|
||||
|
||||
* ``Path`` - имя метрики (сенсора Graphite).
|
||||
* ``Time`` - время измерения.
|
||||
* ``Value`` - значение метрики в момент времени Time.
|
||||
* ``Version`` - настройка, которая определяет какое значение метрики с одинаковыми Path и Time останется в базе.
|
||||
|
||||
Шаблон правил rollup: ::
|
||||
|
||||
pattern
|
||||
regexp
|
||||
function
|
||||
age -> precision
|
||||
...
|
||||
pattern
|
||||
...
|
||||
default
|
||||
function
|
||||
age -> precision
|
||||
...
|
||||
|
||||
При обработке записи ClickHouse проверит правила в секции ```pattern```. Если имя метрики соответствует шаблону ```regexp```, то применяются правила из ```pattern```, в противном случае из ```default```.
|
||||
|
||||
Поля шаблона правил.
|
||||
|
||||
+---------------+----------------------------------------------------------------------------------------------------------------------------+
|
||||
| Поле | Описание |
|
||||
+===============+============================================================================================================================+
|
||||
| ``age`` | Минимальный возраст данных в секундах. |
|
||||
+---------------+----------------------------------------------------------------------------------------------------------------------------+
|
||||
| ``function`` | Имя агрегирующей функции, которую следует применить к данным, чей возраст оказался в интервале ``[age, age + precision]``. |
|
||||
+---------------+----------------------------------------------------------------------------------------------------------------------------+
|
||||
| ``precision`` | Точность определения возраста данных в секундах. |
|
||||
+---------------+----------------------------------------------------------------------------------------------------------------------------+
|
||||
| ``regexp`` | Шаблон имени метрики. |
|
||||
+---------------+----------------------------------------------------------------------------------------------------------------------------+
|
||||
|
||||
|
||||
Пример настройки:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<graphite_rollup>
|
||||
<pattern>
|
||||
<regexp>click_cost</regexp>
|
||||
<function>any</function>
|
||||
<retention>
|
||||
<age>0</age>
|
||||
<precision>5</precision>
|
||||
</retention>
|
||||
<retention>
|
||||
<age>86400</age>
|
||||
<precision>60</precision>
|
||||
</retention>
|
||||
</pattern>
|
||||
<default>
|
||||
<function>max</function>
|
||||
<retention>
|
||||
<age>0</age>
|
||||
<precision>60</precision>
|
||||
</retention>
|
||||
<retention>
|
||||
<age>3600</age>
|
||||
<precision>300</precision>
|
||||
</retention>
|
||||
<retention>
|
||||
<age>86400</age>
|
||||
<precision>3600</precision>
|
||||
</retention>
|
||||
</default>
|
||||
</graphite_rollup>
|
||||
@ -1,3 +1,5 @@
|
||||
.. _table_engines-mergetree:
|
||||
|
||||
MergeTree
|
||||
---------
|
||||
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. _table_engines-replication:
|
||||
|
||||
Репликация данных
|
||||
-----------------
|
||||
|
||||
@ -45,7 +47,7 @@ ReplicatedSummingMergeTree
|
||||
|
||||
Если в конфигурационном файле не настроен ZooKeeper, то вы не сможете создать реплицируемые таблицы, а уже имеющиеся реплицируемые таблицы будут доступны в режиме только на чтение.
|
||||
|
||||
При запросах SELECT, ZooKeeper не используется. То есть, репликация никак не влияет на производительность SELECT-ов - запросы работают так же быстро, как и для нереплицируемых таблиц.
|
||||
При запросах SELECT, ZooKeeper не используется. То есть, репликация никак не влияет на производительность SELECT-ов - запросы работают так же быстро, как и для нереплицируемых таблиц. При запросах к распределенным реплицированным таблицам поведение ClickHouse регулируется настройками :ref:`settings_settings_max_replica_delay_for_distributed_queries` и :ref:`settings-settings-fallback_to_stale_replicas_for_distributed_queries`.
|
||||
|
||||
При каждом запросе INSERT (точнее, на каждый вставляемый блок данных; запрос INSERT содержит один блок, или по блоку на каждые max_insert_block_size = 1048576 строк), делается около десятка записей в ZooKeeper в рамках нескольких транзакций. Это приводит к некоторому увеличению задержек при INSERT-е, по сравнению с нереплицируемыми таблицами. Но если придерживаться обычных рекомендаций - вставлять данные пачками не более одного INSERT-а в секунду, то это не составляет проблем. На всём кластере ClickHouse, использующим для координации один кластер ZooKeeper, может быть в совокупности несколько сотен INSERT-ов в секунду. Пропускная способность при вставке данных (количество строчек в секунду) такая же высокая, как для нереплицируемых таблиц.
|
||||
|
||||
@ -72,8 +74,7 @@ ReplicatedSummingMergeTree
|
||||
|
||||
Также добавляются два параметра в начало списка параметров - путь к таблице в ZooKeeper, имя реплики в ZooKeeper.
|
||||
|
||||
Пример:
|
||||
::
|
||||
Пример: ::
|
||||
|
||||
ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)
|
||||
|
||||
@ -124,6 +125,7 @@ ReplicatedSummingMergeTree
|
||||
Если обнаруживается, что локальный набор данных слишком сильно отличается от ожидаемого, то срабатывает защитный механизм - сервер сообщает об этом в лог и отказывается запускаться. Это сделано, так как такой случай может свидетельствовать об ошибке конфигурации - например, если реплика одного шарда была случайно сконфигурирована, как реплика другого шарда. Тем не менее, пороги защитного механизма поставлены довольно низкими, и такая ситуация может возникнуть и при обычном восстановлении после сбоя. В этом случае, восстановление делается полуавтоматически - "по кнопке".
|
||||
|
||||
Для запуска восстановления, создайте в ZooKeeper узел ``/path_to_table/replica_name/flags/force_restore_data`` с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
|
||||
|
||||
@ -1,22 +1,21 @@
|
||||
.. _table_functions-remote:
|
||||
|
||||
remote
|
||||
------
|
||||
|
||||
``remote('addresses_expr', db, table[, 'user'[, 'password']])``
|
||||
Позволяет обратиться к удалённым серверам без создания таблицы типа ``Distributed``.
|
||||
|
||||
или
|
||||
Сигнатуры: ::
|
||||
|
||||
``remote('addresses_expr', db.table[, 'user'[, 'password']])``
|
||||
remote('addresses_expr', db, table[, 'user'[, 'password']])
|
||||
remote('addresses_expr', db.table[, 'user'[, 'password']])
|
||||
|
||||
- позволяет обратиться к удалённым серверам без создания таблицы типа Distributed.
|
||||
|
||||
``addresses_expr`` - выражение, генерирующее адреса удалённых серверов.
|
||||
``addresses_expr`` - выражение, генерирующее адреса удалённых серверов. Это может быть просто один адрес сервера. Адрес сервера - это ``хост:порт``, или только ``хост``. Хост может быть указан в виде имени сервера, или в виде IPv4 или IPv6 адреса. IPv6 адрес указывается в квадратных скобках. Порт - TCP-порт удалённого сервера. Если порт не указан, используется ``tcp_port`` из конфигурационного файла сервера (по умолчанию - 9000).
|
||||
|
||||
Это может быть просто один адрес сервера. Адрес сервера - это хост:порт, или только хост. Хост может быть указан в виде имени сервера, или в виде IPv4 или IPv6 адреса. IPv6 адрес указывается в квадратных скобках. Порт - TCP-порт удалённого сервера. Если порт не указан, используется tcp_port из конфигурационного файла сервера (по умолчанию - 9000).
|
||||
.. important:: С IPv6-адресом обязательно указывать порт.
|
||||
|
||||
Замечание: в качестве исключения, при указании IPv6-адреса, обязательно также указывать порт.
|
||||
|
||||
Примеры:
|
||||
::
|
||||
Примеры: ::
|
||||
|
||||
example01-01-1
|
||||
example01-01-1:9000
|
||||
@ -25,43 +24,39 @@ remote
|
||||
[::]:9000
|
||||
[2a02:6b8:0:1111::11]:9000
|
||||
|
||||
Могут быть указаны адреса через запятую - в этом случае, запрос пойдёт на все указанные адреса (как на шарды с разными данными) и будет обработан распределённо.
|
||||
Адреса можно указать через запятую, в этом случае ClickHouse обработает запрос как распределённый, т.е. отправит его по всем указанным адресам как на шарды с разными данными.
|
||||
|
||||
Пример:
|
||||
::
|
||||
Пример: ::
|
||||
|
||||
example01-01-1,example01-02-1
|
||||
|
||||
Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом:
|
||||
::
|
||||
Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом: ::
|
||||
|
||||
example01-0{1,2}-1
|
||||
|
||||
В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом:
|
||||
::
|
||||
В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом: ::
|
||||
|
||||
example01-{01..02}-1
|
||||
|
||||
При наличии нескольких пар фигурных скобок, генерируется прямое произведение соответствующих множеств.
|
||||
|
||||
Адреса или их фрагменты в фигурных скобках, могут быть указаны через символ |. В этом случае, соответствующие множества адресов понимаются как реплики - запрос будет отправлен на первую живую реплику. При этом, реплики перебираются в порядке, согласно текущей настройке load_balancing.
|
||||
Адреса или их фрагменты в фигурных скобках можно указать через символ \|. В этом случае, соответствующие множества адресов понимаются как реплики - запрос будет отправлен на первую живую реплику. При этом, реплики перебираются в порядке, согласно текущей настройке :ref:`load_balancing <settings-load_balancing>`.
|
||||
|
||||
Пример:
|
||||
::
|
||||
Пример: ::
|
||||
|
||||
example01-{01..02}-{1|2}
|
||||
|
||||
В этом примере указано два шарда, в каждом из которых имеется две реплики.
|
||||
|
||||
Количество генерируемых адресов ограничено некоторой константой - сейчас это 1000 штук.
|
||||
Количество генерируемых адресов ограничено константой - сейчас это 1000 штук.
|
||||
|
||||
Использование табличной функции remote менее оптимально, чем создание таблицы типа Distributed, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте Distributed таблицу заранее, не используйте табличную функцию remote.
|
||||
Использование табличной функции ``remote`` менее оптимально, чем создание таблицы типа ``Distributed``, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте ``Distributed`` таблицу заранее, не используйте табличную функцию ``remote``.
|
||||
|
||||
Табличная функция remote может быть полезна для следующих случаев:
|
||||
Табличная функция ``remote`` может быть полезна для следующих случаях:
|
||||
* обращение на конкретный сервер в целях сравнения данных, отладки и тестирования;
|
||||
* запросы между разными кластерами ClickHouse в целях исследований;
|
||||
* нечастых распределённых запросов, задаваемых вручную;
|
||||
* распределённых запросов, где набор серверов определяется каждый раз заново.
|
||||
|
||||
Имя пользователя может быть не задано - тогда используется имя пользователя 'default'.
|
||||
Пароль может быть не задан - тогда используется пустой пароль.
|
||||
Если пользователь не задан,то используется ``default``.
|
||||
Если пароль не задан, то используется пустой пароль.
|
||||
Loading…
Reference in New Issue
Block a user