diff --git a/docs/ru/access_rights.rst b/docs/ru/access_rights.rst index 0987d4d8465..4078b357252 100644 --- a/docs/ru/access_rights.rst +++ b/docs/ru/access_rights.rst @@ -84,8 +84,14 @@ Для продакшен использования, указывайте только элементы вида ip (IP-адреса и их маски), так как использование host и host_regexp может вызывать лишние задержки. -Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - default. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение. +Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - ``default``. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение. Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности. -Также в необязательном разделе ```` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию. +Также в необязательном разделе ```` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию. + +Доступ к БД ``system`` всегда считается разрешённым (так как эта БД используется для выполнения запросов). + +Пользователь может получить список всех БД и таблиц в них с помощью запросов ``SHOW`` или системных таблиц, даже если у него нет доступа к отдельным ДБ. + +Доступ к БД не связан с настройкой :ref:`query_complexity_readonly`. Невозможно дать полный доступ к одной БД и ``readonly`` к другой. diff --git a/docs/ru/configuration_files.rst b/docs/ru/configuration_files.rst index 27e1c321a0a..efe396a89fa 100644 --- a/docs/ru/configuration_files.rst +++ b/docs/ru/configuration_files.rst @@ -1,3 +1,5 @@ +.. _configuration_files: + Конфигурационные файлы ====================== diff --git a/docs/ru/dicts/external_dicts.rst b/docs/ru/dicts/external_dicts.rst index 94dcffa13e5..dce4e0c8d78 100644 --- a/docs/ru/dicts/external_dicts.rst +++ b/docs/ru/dicts/external_dicts.rst @@ -6,7 +6,7 @@ Словарь может полностью храниться в оперативке и периодически обновляться, или быть частично закэшированным в оперативке и динамически подгружать отсутствующие значения. Конфигурация внешних словарей находится в отдельном файле или файлах, указанных в конфигурационном параметре dictionaries_config. -Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы * и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/*.xml. +Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы \* и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/\*.xml. Конфигурация словарей, а также множество файлов с конфигурацией, может обновляться без перезапуска сервера. Сервер проверяет обновления каждые 5 секунд. То есть, словари могут подключаться динамически. @@ -68,6 +68,18 @@ Для отказоустойчивости, вы можете создать Distributed таблицу на localhost и прописать её. - -> --> + + @@ -139,6 +151,14 @@ true + + + + expr + UInt64 + rand64() + 0 + @@ -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``. Пример: diff --git a/docs/ru/introduction/distinctive_features.rst b/docs/ru/introduction/distinctive_features.rst index 0f160a5880a..5636b6688b4 100644 --- a/docs/ru/introduction/distinctive_features.rst +++ b/docs/ru/introduction/distinctive_features.rst @@ -60,4 +60,4 @@ ClickHouse поддерживает таблицы с первичным клю 14. Репликация данных, поддержка целостности данных на репликах. ---------------------------------------------------------------- Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке". -Подробнее смотрите раздел "Репликация данных". +Подробнее смотрите раздел :ref:`table_engines-replication`. diff --git a/docs/ru/query_language/queries.rst b/docs/ru/query_language/queries.rst index db7de94dd05..bd1bbaa1722 100644 --- a/docs/ru/query_language/queries.rst +++ b/docs/ru/query_language/queries.rst @@ -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:`настройки ` ``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 + , выполнен параллельно на каждом из них до стадии, позволяющей объединить промежуточные результаты; затем промежуточные результаты вернутся на сервер-инициатор запроса, будут на нём объединены, и финальный результат будет отправлен клиенту. diff --git a/docs/ru/settings/index.rst b/docs/ru/settings/index.rst index 65b8816fc38..aa51d89e264 100644 --- a/docs/ru/settings/index.rst +++ b/docs/ru/settings/index.rst @@ -1,7 +1,22 @@ Настройки ========== -Здесь будут рассмотрены настройки, которые можно задать с помощью запроса SET или в конфигурационном файле. Напомню, что эти настройки могут быть выставлены в пределах сессии или глобально. Настройки, которые можно задать только в конфигурационном файле сервера, здесь рассмотрены не будут. +Описанные в разделе настройки могут быть заданы следующими способами: +* Глобально. + + В конфигурационных файлах сервера. + +* Для сессии. + + При запуске консольного клиента ClickHouse в интерактивном режиме отправьте запрос ``SET setting=value``. + +* Для запроса. + + * При запуске консольного клиента ClickHouse в неинтерактивном режиме установите параметр запуска ``--setting=value``. + * При использовании HTTP API передавайте cgi-параметры (``URL?setting_1=value&setting_2=value...``). + + +Настройки, которые можно задать только в конфигурационном файле сервера, в разделе не рассматриваются. .. toctree:: :glob: diff --git a/docs/ru/settings/query_complexity.rst b/docs/ru/settings/query_complexity.rst index 7de814db6a1..d89d8758a86 100644 --- a/docs/ru/settings/query_complexity.rst +++ b/docs/ru/settings/query_complexity.rst @@ -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 Максимальное время выполнения запроса в секундах. На данный момент не проверяется при одной из стадий сортировки а также при слиянии и финализации агрегатных функций. diff --git a/docs/ru/settings/settings.rst b/docs/ru/settings/settings.rst index 022cf1d2656..4d0c54fccd6 100644 --- a/docs/ru/settings/settings.rst +++ b/docs/ru/settings/settings.rst @@ -1,3 +1,47 @@ +.. _settings-distributed_product_mode: + +distributed_product_mode +------------------------ +Изменяет поведение :ref:`распределенных подзапросов `, т.е. в тех случаях, когда запрос содержит произведение распределённых таблиц. + +ClickHouse применяет настройку в том случае, когда в подзапросах на любом уровне встретилась распределенная таблица, которая существует на локальном сервере и имеет больше одного шарда. + +Условия применения: + +* Только подзапросы для IN, JOIN. +* Только если в секции FROM используется распределённая таблица. +* Не используется в случае табличной функции :ref:`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 `. В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min_compress_block_size. По умолчанию - 65 536. Реальный размер блока, если несжатых данных меньше max_compress_block_size, будет не меньше этого значения и не меньше объёма данных на одну засечку. @@ -136,6 +194,8 @@ replace_running_query Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить. +.. _settings-load_balancing: + load_balancing -------------- На какие реплики (среди живых реплик) предпочитать отправлять запрос (при первой попытке) при распределённой обработке запроса. diff --git a/docs/ru/table_engines/graphitemergetree.rst b/docs/ru/table_engines/graphitemergetree.rst new file mode 100644 index 00000000000..249ae4dd935 --- /dev/null +++ b/docs/ru/table_engines/graphitemergetree.rst @@ -0,0 +1,91 @@ +GraphiteMergeTree +----------------- + +Движок предназначен для rollup (прореживания и агрегирования/усреднения) данных `Graphite `_. Он может быть интересен разработчикам, которые хотят использовать ClickHouse как хранилище данных для Graphite. + +Graphite хранит в ClickHouse полные данные, а получать их может следующими способами: + +* Без прореживания. + + Используется движок :ref:`MergeTree `. + +* С прореживанием. + + Используется движок ``GraphiteMergeTree``. + +Движок наследует свойства `MergeTree`. Настройки прореживания данных размещаются в :ref:`общей конфигурации ` 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 + + + + click_cost + any + + 0 + 5 + + + 86400 + 60 + + + + max + + 0 + 60 + + + 3600 + 300 + + + 86400 + 3600 + + + diff --git a/docs/ru/table_engines/mergetree.rst b/docs/ru/table_engines/mergetree.rst index 94f0eb3d98e..8c51a1a85f4 100644 --- a/docs/ru/table_engines/mergetree.rst +++ b/docs/ru/table_engines/mergetree.rst @@ -1,3 +1,5 @@ +.. _table_engines-mergetree: + MergeTree --------- diff --git a/docs/ru/table_engines/replication.rst b/docs/ru/table_engines/replication.rst index 0684ddcb600..1d88755a67f 100644 --- a/docs/ru/table_engines/replication.rst +++ b/docs/ru/table_engines/replication.rst @@ -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 diff --git a/docs/ru/table_functions/remote.rst b/docs/ru/table_functions/remote.rst index 6901bc53679..b7c67bcf259 100644 --- a/docs/ru/table_functions/remote.rst +++ b/docs/ru/table_functions/remote.rst @@ -1,67 +1,62 @@ +.. _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 + localhost + 127.0.0.1 + [::]:9000 + [2a02:6b8:0:1111::11]:9000 - example01-01-1 - example01-01-1:9000 - localhost - 127.0.0.1 - [::]:9000 - [2a02:6b8:0:1111::11]:9000 +Адреса можно указать через запятую, в этом случае ClickHouse обработает запрос как распределённый, т.е. отправит его по всем указанным адресам как на шарды с разными данными. -Могут быть указаны адреса через запятую - в этом случае, запрос пойдёт на все указанные адреса (как на шарды с разными данными) и будет обработан распределённо. +Пример: :: -Пример: -:: + 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 `. -Пример: -:: +Пример: :: - example01-{01..02}-{1|2} + example01-{01..02}-{1|2} В этом примере указано два шарда, в каждом из которых имеется две реплики. -Количество генерируемых адресов ограничено некоторой константой - сейчас это 1000 штук. +Количество генерируемых адресов ограничено константой - сейчас это 1000 штук. -Использование табличной функции remote менее оптимально, чем создание таблицы типа Distributed, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте Distributed таблицу заранее, не используйте табличную функцию remote. +Использование табличной функции ``remote`` менее оптимально, чем создание таблицы типа ``Distributed``, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте ``Distributed`` таблицу заранее, не используйте табличную функцию ``remote``. -Табличная функция remote может быть полезна для следующих случаев: +Табличная функция ``remote`` может быть полезна для следующих случаях: * обращение на конкретный сервер в целях сравнения данных, отладки и тестирования; * запросы между разными кластерами ClickHouse в целях исследований; * нечастых распределённых запросов, задаваемых вручную; * распределённых запросов, где набор серверов определяется каждый раз заново. -Имя пользователя может быть не задано - тогда используется имя пользователя 'default'. -Пароль может быть не задан - тогда используется пустой пароль. +Если пользователь не задан,то используется ``default``. +Если пароль не задан, то используется пустой пароль. \ No newline at end of file