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:
commit
1db9a73059
@ -84,8 +84,14 @@
|
|||||||
|
|
||||||
Для продакшен использования, указывайте только элементы вида ip (IP-адреса и их маски), так как использование host и host_regexp может вызывать лишние задержки.
|
Для продакшен использования, указывайте только элементы вида ip (IP-адреса и их маски), так как использование host и host_regexp может вызывать лишние задержки.
|
||||||
|
|
||||||
Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - default. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
|
Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - ``default``. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
|
||||||
|
|
||||||
Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
|
Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
|
||||||
|
|
||||||
Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию.
|
Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию.
|
||||||
|
|
||||||
|
Доступ к БД ``system`` всегда считается разрешённым (так как эта БД используется для выполнения запросов).
|
||||||
|
|
||||||
|
Пользователь может получить список всех БД и таблиц в них с помощью запросов ``SHOW`` или системных таблиц, даже если у него нет доступа к отдельным ДБ.
|
||||||
|
|
||||||
|
Доступ к БД не связан с настройкой :ref:`query_complexity_readonly`. Невозможно дать полный доступ к одной БД и ``readonly`` к другой.
|
||||||
|
@ -1,3 +1,5 @@
|
|||||||
|
.. _configuration_files:
|
||||||
|
|
||||||
Конфигурационные файлы
|
Конфигурационные файлы
|
||||||
======================
|
======================
|
||||||
|
|
||||||
|
@ -6,7 +6,7 @@
|
|||||||
Словарь может полностью храниться в оперативке и периодически обновляться, или быть частично закэшированным в оперативке и динамически подгружать отсутствующие значения.
|
Словарь может полностью храниться в оперативке и периодически обновляться, или быть частично закэшированным в оперативке и динамически подгружать отсутствующие значения.
|
||||||
|
|
||||||
Конфигурация внешних словарей находится в отдельном файле или файлах, указанных в конфигурационном параметре dictionaries_config.
|
Конфигурация внешних словарей находится в отдельном файле или файлах, указанных в конфигурационном параметре dictionaries_config.
|
||||||
Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы * и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/*.xml.
|
Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы \* и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/\*.xml.
|
||||||
|
|
||||||
Конфигурация словарей, а также множество файлов с конфигурацией, может обновляться без перезапуска сервера. Сервер проверяет обновления каждые 5 секунд. То есть, словари могут подключаться динамически.
|
Конфигурация словарей, а также множество файлов с конфигурацией, может обновляться без перезапуска сервера. Сервер проверяет обновления каждые 5 секунд. То есть, словари могут подключаться динамически.
|
||||||
|
|
||||||
@ -68,6 +68,18 @@
|
|||||||
Для отказоустойчивости, вы можете создать Distributed таблицу на localhost и прописать её. - ->
|
Для отказоустойчивости, вы можете создать 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 программы -->
|
<!-- или источник - исполняемый файл. Если layout.cache - список нужных ключей будет записан в поток STDIN программы -->
|
||||||
<executable>
|
<executable>
|
||||||
<!-- Путь или имя программы (если директория есть в переменной окружения PATH) и параметры -->
|
<!-- Путь или имя программы (если директория есть в переменной окружения PATH) и параметры -->
|
||||||
@ -139,6 +151,14 @@
|
|||||||
<!-- Можно считать отображение id -> attribute инъективным, чтобы оптимизировать GROUP BY. (по умолчанию, false) -->
|
<!-- Можно считать отображение id -> attribute инъективным, чтобы оптимизировать GROUP BY. (по умолчанию, false) -->
|
||||||
<injective>true</injective>
|
<injective>true</injective>
|
||||||
</attribute>
|
</attribute>
|
||||||
|
|
||||||
|
<!-- Атрибут может быть выражением -->
|
||||||
|
<attribute>
|
||||||
|
<name>expr</name>
|
||||||
|
<type>UInt64</type>
|
||||||
|
<expression>rand64()</expression>
|
||||||
|
<null_value>0</null_value>
|
||||||
|
</attribute>
|
||||||
</structure>
|
</structure>
|
||||||
</dictionary>
|
</dictionary>
|
||||||
</dictionaries>
|
</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. Репликация данных, поддержка целостности данных на репликах.
|
14. Репликация данных, поддержка целостности данных на репликах.
|
||||||
----------------------------------------------------------------
|
----------------------------------------------------------------
|
||||||
Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке".
|
Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке".
|
||||||
Подробнее смотрите раздел "Репликация данных".
|
Подробнее смотрите раздел :ref:`table_engines-replication`.
|
||||||
|
@ -65,9 +65,9 @@ CREATE TABLE
|
|||||||
|
|
||||||
``MATERIALIZED expr``
|
``MATERIALIZED expr``
|
||||||
|
|
||||||
Материализованное выражение. Такой столбец не может быть указан при INSERT-е, то есть, он всегда вычисляется.
|
Материализованное выражение. Такой столбец не может быть указан при INSERT, то есть, он всегда вычисляется.
|
||||||
При INSERT-е без указания списка столбцов, такие столбцы не рассматриваются.
|
При INSERT без указания списка столбцов, такие столбцы не рассматриваются.
|
||||||
Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём SELECT *, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
|
Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём ``SELECT *``, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
|
||||||
|
|
||||||
``ALIAS expr``
|
``ALIAS expr``
|
||||||
|
|
||||||
@ -675,7 +675,7 @@ SELECT
|
|||||||
|
|
||||||
``ARRAY JOIN`` - это, по сути, ``INNER JOIN`` с массивом. Пример:
|
``ARRAY JOIN`` - это, по сути, ``INNER JOIN`` с массивом. Пример:
|
||||||
|
|
||||||
.. code-block:: sql
|
::
|
||||||
|
|
||||||
:) CREATE TABLE arrays_test (s String, arr Array(UInt8)) ENGINE = Memory
|
:) CREATE TABLE arrays_test (s String, arr Array(UInt8)) ENGINE = Memory
|
||||||
|
|
||||||
@ -728,7 +728,7 @@ SELECT
|
|||||||
|
|
||||||
Для массива в секции ARRAY JOIN может быть указан алиас. В этом случае, элемент массива будет доступен под этим алиасом, а сам массив - под исходным именем. Пример:
|
Для массива в секции ARRAY JOIN может быть указан алиас. В этом случае, элемент массива будет доступен под этим алиасом, а сам массив - под исходным именем. Пример:
|
||||||
|
|
||||||
.. code-block:: sql
|
::
|
||||||
|
|
||||||
:) SELECT s, arr, a FROM arrays_test ARRAY JOIN arr AS a
|
:) SELECT s, arr, a FROM arrays_test ARRAY JOIN arr AS a
|
||||||
|
|
||||||
@ -748,7 +748,7 @@ SELECT
|
|||||||
|
|
||||||
В секции ARRAY JOIN может быть указано несколько массивов одинаковых размеров через запятую. В этом случае, JOIN делается с ними одновременно (прямая сумма, а не прямое произведение). Пример:
|
В секции 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
|
:) 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 также работает с вложенными структурами данных. Пример:
|
ARRAY JOIN также работает с вложенными структурами данных. Пример:
|
||||||
|
|
||||||
.. code-block:: sql
|
::
|
||||||
|
|
||||||
:) CREATE TABLE nested_test (s String, nest Nested(x UInt8, y UInt32)) ENGINE = Memory
|
:) CREATE TABLE nested_test (s String, nest Nested(x UInt8, y UInt32)) ENGINE = Memory
|
||||||
|
|
||||||
@ -839,7 +839,7 @@ ARRAY JOIN также работает с вложенными структур
|
|||||||
|
|
||||||
При указании имени вложенной структуры данных в ARRAY JOIN, смысл такой же, как ARRAY JOIN со всеми элементами-массивами, из которых она состоит. Пример:
|
При указании имени вложенной структуры данных в ARRAY JOIN, смысл такой же, как ARRAY JOIN со всеми элементами-массивами, из которых она состоит. Пример:
|
||||||
|
|
||||||
.. code-block:: sql
|
::
|
||||||
|
|
||||||
:) SELECT s, nest.x, nest.y FROM nested_test ARRAY JOIN nest.x, nest.y
|
:) 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
|
:) SELECT s, nest.x, nest.y FROM nested_test ARRAY JOIN nest.x
|
||||||
|
|
||||||
@ -879,7 +879,7 @@ ARRAY JOIN также работает с вложенными структур
|
|||||||
|
|
||||||
Алиас для вложенной структуры данных можно использовать, чтобы выбрать как результат JOIN-а, так и исходный массив. Пример:
|
Алиас для вложенной структуры данных можно использовать, чтобы выбрать как результат JOIN-а, так и исходный массив. Пример:
|
||||||
|
|
||||||
.. code-block:: sql
|
::
|
||||||
|
|
||||||
:) SELECT s, n.x, n.y, nest.x, nest.y FROM nested_test ARRAY JOIN nest AS n
|
:) 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:
|
Пример использования функции 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
|
:) 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
|
SELECT
|
||||||
CounterID,
|
CounterID,
|
||||||
@ -1033,7 +1033,7 @@ PREWHERE имеет смысл использовать, если есть ус
|
|||||||
|
|
||||||
Например, полезно писать PREWHERE для запросов, которые вынимают много столбцов, но в которых фильтрация производится лишь по нескольким столбцам.
|
Например, полезно писать PREWHERE для запросов, которые вынимают много столбцов, но в которых фильтрация производится лишь по нескольким столбцам.
|
||||||
|
|
||||||
PREWHERE поддерживается только таблицами семейства *MergeTree.
|
PREWHERE поддерживается только таблицами семейства ``*MergeTree``.
|
||||||
|
|
||||||
В запросе могут быть одновременно указаны секции PREWHERE и WHERE. В этом случае, PREWHERE идёт перед WHERE.
|
В запросе могут быть одновременно указаны секции PREWHERE и WHERE. В этом случае, PREWHERE идёт перед WHERE.
|
||||||
|
|
||||||
@ -1289,7 +1289,7 @@ n и m должны быть неотрицательными целыми чи
|
|||||||
Оператор IN и подзапрос могут встречаться в любой части запроса, в том числе в агрегатных и лямбда функциях.
|
Оператор IN и подзапрос могут встречаться в любой части запроса, в том числе в агрегатных и лямбда функциях.
|
||||||
Пример:
|
Пример:
|
||||||
|
|
||||||
.. code-block:: sql
|
::
|
||||||
|
|
||||||
SELECT
|
SELECT
|
||||||
EventDate,
|
EventDate,
|
||||||
@ -1316,11 +1316,17 @@ n и m должны быть неотрицательными целыми чи
|
|||||||
за каждый день после 17 марта считаем долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
|
за каждый день после 17 марта считаем долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
|
||||||
Подзапрос в секции IN на одном сервере всегда выполняется только один раз. Зависимых подзапросов не существует.
|
Подзапрос в секции IN на одном сервере всегда выполняется только один раз. Зависимых подзапросов не существует.
|
||||||
|
|
||||||
|
|
||||||
|
.. _queries-distributed-subrequests:
|
||||||
|
|
||||||
Распределённые подзапросы
|
Распределённые подзапросы
|
||||||
"""""""""""""""""""""""""
|
"""""""""""""""""""""""""
|
||||||
|
|
||||||
Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный ``IN`` / ``JOIN`` и ``GLOBAL IN`` / ``GLOBAL JOIN``. Они отличаются способом выполнения при распределённой обработке запроса.
|
Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный ``IN`` / ``JOIN`` и ``GLOBAL IN`` / ``GLOBAL JOIN``. Они отличаются способом выполнения при распределённой обработке запроса.
|
||||||
|
|
||||||
|
.. attention::
|
||||||
|
Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от :ref:`настройки <settings-distributed_product_mode>` ``distributed_product_mode``.
|
||||||
|
|
||||||
При использовании обычного IN-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях ``IN`` / ``JOIN``.
|
При использовании обычного IN-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях ``IN`` / ``JOIN``.
|
||||||
|
|
||||||
При использовании ``GLOBAL IN`` / ``GLOBAL JOIN-а``, сначала выполняются все подзапросы для ``GLOBAL IN`` / ``GLOBAL JOIN-ов``, и результаты складываются во временные таблицы. Затем эти временные таблицы передаются на каждый удалённый сервер, и на них выполняются запросы, с использованием этих переданных временных данных.
|
При использовании ``GLOBAL IN`` / ``GLOBAL JOIN-а``, сначала выполняются все подзапросы для ``GLOBAL IN`` / ``GLOBAL JOIN-ов``, и результаты складываются во временные таблицы. Затем эти временные таблицы передаются на каждый удалённый сервер, и на них выполняются запросы, с использованием этих переданных временных данных.
|
||||||
@ -1343,7 +1349,8 @@ n и m должны быть неотрицательными целыми чи
|
|||||||
|
|
||||||
.. code-block:: sql
|
.. 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::
|
.. toctree::
|
||||||
:glob:
|
:glob:
|
||||||
|
@ -15,6 +15,8 @@
|
|||||||
|
|
||||||
``any (только для group_by_overflow_mode)`` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
|
``any (только для group_by_overflow_mode)`` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
|
||||||
|
|
||||||
|
.. _query_complexity_readonly:
|
||||||
|
|
||||||
readonly
|
readonly
|
||||||
--------
|
--------
|
||||||
При значении 0 можно выполнять любые запросы.
|
При значении 0 можно выполнять любые запросы.
|
||||||
@ -90,7 +92,11 @@ result_overflow_mode
|
|||||||
Использование break по смыслу похоже на LIMIT.
|
Использование break по смыслу похоже на LIMIT.
|
||||||
|
|
||||||
max_execution_time
|
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
|
max_block_size
|
||||||
--------------
|
--------------
|
||||||
Данные в ClickHouse обрабатываются по блокам (наборам кусочков столбцов). Внутренние циклы обработки одного блока достаточно эффективны, но при этом существуют заметные издержки на каждый блок. ``max_block_size`` - это рекомендация, какого размера блоки (в количестве строк) загружать из таблицы. Размер блока должен быть не слишком маленьким, чтобы издержки на каждый блок оставались незаметными, и не слишком большим, чтобы запрос с LIMIT-ом, который завершается уже после первого блока, выполнялся быстро; чтобы не использовалось слишком много оперативки при вынимании большого количества столбцов в несколько потоков; чтобы оставалась хоть какая-нибудь кэш-локальность.
|
Данные в ClickHouse обрабатываются по блокам (наборам кусочков столбцов). Внутренние циклы обработки одного блока достаточно эффективны, но при этом существуют заметные издержки на каждый блок. ``max_block_size`` - это рекомендация, какого размера блоки (в количестве строк) загружать из таблицы. Размер блока должен быть не слишком маленьким, чтобы издержки на каждый блок оставались незаметными, и не слишком большим, чтобы запрос с LIMIT-ом, который завершается уже после первого блока, выполнялся быстро; чтобы не использовалось слишком много оперативки при вынимании большого количества столбцов в несколько потоков; чтобы оставалась хоть какая-нибудь кэш-локальность.
|
||||||
@ -22,7 +66,21 @@ max_insert_block_size
|
|||||||
|
|
||||||
``По умолчанию - 1 048 576.``
|
``По умолчанию - 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
|
max_threads
|
||||||
-----------
|
-----------
|
||||||
@ -48,7 +106,7 @@ max_compress_block_size
|
|||||||
|
|
||||||
min_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, будет не меньше этого значения и не меньше объёма данных на одну засечку.
|
Реальный размер блока, если несжатых данных меньше max_compress_block_size, будет не меньше этого значения и не меньше объёма данных на одну засечку.
|
||||||
|
|
||||||
@ -136,6 +194,8 @@ replace_running_query
|
|||||||
|
|
||||||
Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить.
|
Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить.
|
||||||
|
|
||||||
|
.. _settings-load_balancing:
|
||||||
|
|
||||||
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
|
MergeTree
|
||||||
---------
|
---------
|
||||||
|
|
||||||
|
@ -1,3 +1,5 @@
|
|||||||
|
.. _table_engines-replication:
|
||||||
|
|
||||||
Репликация данных
|
Репликация данных
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
@ -45,7 +47,7 @@ ReplicatedSummingMergeTree
|
|||||||
|
|
||||||
Если в конфигурационном файле не настроен ZooKeeper, то вы не сможете создать реплицируемые таблицы, а уже имеющиеся реплицируемые таблицы будут доступны в режиме только на чтение.
|
Если в конфигурационном файле не настроен 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-ов в секунду. Пропускная способность при вставке данных (количество строчек в секунду) такая же высокая, как для нереплицируемых таблиц.
|
При каждом запросе INSERT (точнее, на каждый вставляемый блок данных; запрос INSERT содержит один блок, или по блоку на каждые max_insert_block_size = 1048576 строк), делается около десятка записей в ZooKeeper в рамках нескольких транзакций. Это приводит к некоторому увеличению задержек при INSERT-е, по сравнению с нереплицируемыми таблицами. Но если придерживаться обычных рекомендаций - вставлять данные пачками не более одного INSERT-а в секунду, то это не составляет проблем. На всём кластере ClickHouse, использующим для координации один кластер ZooKeeper, может быть в совокупности несколько сотен INSERT-ов в секунду. Пропускная способность при вставке данных (количество строчек в секунду) такая же высокая, как для нереплицируемых таблиц.
|
||||||
|
|
||||||
@ -72,8 +74,7 @@ ReplicatedSummingMergeTree
|
|||||||
|
|
||||||
Также добавляются два параметра в начало списка параметров - путь к таблице в ZooKeeper, имя реплики в ZooKeeper.
|
Также добавляются два параметра в начало списка параметров - путь к таблице в ZooKeeper, имя реплики в ZooKeeper.
|
||||||
|
|
||||||
Пример:
|
Пример: ::
|
||||||
::
|
|
||||||
|
|
||||||
ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)
|
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`` с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:
|
Для запуска восстановления, создайте в ZooKeeper узел ``/path_to_table/replica_name/flags/force_restore_data`` с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:
|
||||||
|
|
||||||
.. code-block:: bash
|
.. code-block:: bash
|
||||||
|
|
||||||
sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
|
sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
|
||||||
|
@ -1,67 +1,62 @@
|
|||||||
|
.. _table_functions-remote:
|
||||||
|
|
||||||
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
|
||||||
|
localhost
|
||||||
|
127.0.0.1
|
||||||
|
[::]:9000
|
||||||
|
[2a02:6b8:0:1111::11]:9000
|
||||||
|
|
||||||
example01-01-1
|
Адреса можно указать через запятую, в этом случае ClickHouse обработает запрос как распределённый, т.е. отправит его по всем указанным адресам как на шарды с разными данными.
|
||||||
example01-01-1:9000
|
|
||||||
localhost
|
|
||||||
127.0.0.1
|
|
||||||
[::]:9000
|
|
||||||
[2a02:6b8:0:1111::11]:9000
|
|
||||||
|
|
||||||
Могут быть указаны адреса через запятую - в этом случае, запрос пойдёт на все указанные адреса (как на шарды с разными данными) и будет обработан распределённо.
|
Пример: ::
|
||||||
|
|
||||||
Пример:
|
example01-01-1,example01-02-1
|
||||||
::
|
|
||||||
|
|
||||||
example01-01-1,example01-02-1
|
Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом: ::
|
||||||
|
|
||||||
Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом:
|
example01-0{1,2}-1
|
||||||
::
|
|
||||||
|
|
||||||
example01-0{1,2}-1
|
В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом: ::
|
||||||
|
|
||||||
В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом:
|
example01-{01..02}-1
|
||||||
::
|
|
||||||
|
|
||||||
example01-{01..02}-1
|
|
||||||
|
|
||||||
При наличии нескольких пар фигурных скобок, генерируется прямое произведение соответствующих множеств.
|
При наличии нескольких пар фигурных скобок, генерируется прямое произведение соответствующих множеств.
|
||||||
|
|
||||||
Адреса или их фрагменты в фигурных скобках, могут быть указаны через символ |. В этом случае, соответствующие множества адресов понимаются как реплики - запрос будет отправлен на первую живую реплику. При этом, реплики перебираются в порядке, согласно текущей настройке load_balancing.
|
Адреса или их фрагменты в фигурных скобках можно указать через символ \|. В этом случае, соответствующие множества адресов понимаются как реплики - запрос будет отправлен на первую живую реплику. При этом, реплики перебираются в порядке, согласно текущей настройке :ref:`load_balancing <settings-load_balancing>`.
|
||||||
|
|
||||||
Пример:
|
Пример: ::
|
||||||
::
|
|
||||||
|
|
||||||
example01-{01..02}-{1|2}
|
example01-{01..02}-{1|2}
|
||||||
|
|
||||||
В этом примере указано два шарда, в каждом из которых имеется две реплики.
|
В этом примере указано два шарда, в каждом из которых имеется две реплики.
|
||||||
|
|
||||||
Количество генерируемых адресов ограничено некоторой константой - сейчас это 1000 штук.
|
Количество генерируемых адресов ограничено константой - сейчас это 1000 штук.
|
||||||
|
|
||||||
Использование табличной функции remote менее оптимально, чем создание таблицы типа Distributed, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте Distributed таблицу заранее, не используйте табличную функцию remote.
|
Использование табличной функции ``remote`` менее оптимально, чем создание таблицы типа ``Distributed``, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте ``Distributed`` таблицу заранее, не используйте табличную функцию ``remote``.
|
||||||
|
|
||||||
Табличная функция remote может быть полезна для следующих случаев:
|
Табличная функция ``remote`` может быть полезна для следующих случаях:
|
||||||
* обращение на конкретный сервер в целях сравнения данных, отладки и тестирования;
|
* обращение на конкретный сервер в целях сравнения данных, отладки и тестирования;
|
||||||
* запросы между разными кластерами ClickHouse в целях исследований;
|
* запросы между разными кластерами ClickHouse в целях исследований;
|
||||||
* нечастых распределённых запросов, задаваемых вручную;
|
* нечастых распределённых запросов, задаваемых вручную;
|
||||||
* распределённых запросов, где набор серверов определяется каждый раз заново.
|
* распределённых запросов, где набор серверов определяется каждый раз заново.
|
||||||
|
|
||||||
Имя пользователя может быть не задано - тогда используется имя пользователя 'default'.
|
Если пользователь не задан,то используется ``default``.
|
||||||
Пароль может быть не задан - тогда используется пустой пароль.
|
Если пароль не задан, то используется пустой пароль.
|
Loading…
Reference in New Issue
Block a user