Description of <allow_databes> was improved.

Description of distributed_product_mode was improved.
Some decorative edits was made.

docs/ru/access_rights.rst

@@ -88,4 +88,10 @@
 
 Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
 
-Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию.
+Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию. 
+
+Доступ к БД ``system`` всегда считается разрешённым (так как эта БД используется для выполнения запросов).
+
+Пользователь может получить список всех БД и таблиц в них с помощью запросов ``SHOW`` или системных таблиц, даже если у него нет доступа к отдельным ДБ.
+
+Доступ к БД не связан с настройкой :ref:`query_complexity_readonly`. Невозможно дать полный доступ к одной БД и ``readonly`` к другой.

docs/ru/settings/query_complexity.rst

@@ -1,5 +1,5 @@
 Ограничения на сложность запроса
-=====================
+================================
 Ограничения на сложность запроса - часть настроек.
 Используются, чтобы обеспечить более безопасное исполнение запросов из пользовательского интерфейса.
 Почти все ограничения действуют только на SELECT-ы.
@@ -15,8 +15,10 @@
 
 ``any (только для group_by_overflow_mode)`` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
 
+.. _query_complexity_readonly:
+
 readonly
--------
+--------
 При значении 0 можно выполнять любые запросы.
 При значении 1 можно выполнять только запросы на чтение (например, SELECT и SHOW). Запросы на запись и изменение настроек (INSERT, SET) запрещены.
 При значении 2 можно выполнять запросы на чтение (SELECT, SHOW) и изменение настроек (SET).
@@ -26,7 +28,7 @@ readonly
 При использовании метода GET HTTP интерфейса, автоматически выставляется readonly = 1. То есть, для запросов, модифицирующие данные, можно использовать только метод POST. Сам запрос при этом можно отправлять как в теле POST-а, так и в параметре URL.
 
 max_memory_usage
---------------
+----------------
 Максимальное количество потребляемой памяти при выполнении запроса на одном сервере. По умолчанию - 10 GB.
 
 Настройка не учитывает объём свободной памяти или общий объём памяти на машине.
@@ -41,134 +43,134 @@ max_memory_usage
 Потребление оперативки не полностью учитывается для состояний агрегатных функций min, max, any, anyLast, argMin, argMax от аргументов String и Array.
 
 max_rows_to_read
----------------
+----------------
 Следующие ограничения могут проверяться на каждый блок (а не на каждую строку). То есть, ограничения могут быть немного нарушены.
 При выполнении запроса в несколько потоков, следующие ограничения действуют в каждом потоке по-отдельности.
 
 Максимальное количество строчек, которое можно прочитать из таблицы при выполнении запроса.
 
 max_bytes_to_read
--------------
+-----------------
 Максимальное количество байт (несжатых данных), которое можно прочитать из таблицы при выполнении запроса.
 
 read_overflow_mode
--------------
+------------------
 Что делать, когда количество прочитанных данных превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_rows_to_group_by
--------------
+--------------------
 Максимальное количество уникальных ключей, получаемых в процессе агрегации. Позволяет ограничить потребление оперативки при агрегации.
 
 group_by_overflow_mode
----------------
+----------------------
 Что делать, когда количество уникальных ключей при агрегации превысило ограничение: throw, break или any. По умолчанию: throw.
 Использование значения any позволяет выполнить GROUP BY приближённо. Качество такого приближённого вычисления сильно зависит от статистических свойств данных.
 
 max_rows_to_sort
---------------
+----------------
 Максимальное количество строк до сортировки. Позволяет ограничить потребление оперативки при сортировке.
 
 max_bytes_to_sort
--------------
+-----------------
 Максимальное количество байт до сортировки.
 
 sort_overflow_mode
-------------
+------------------
 Что делать, если количество строк, полученное перед сортировкой, превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_result_rows
--------------
+---------------
 Ограничение на количество строк результата. Проверяются также для подзапросов и на удалённых серверах при выполнении части распределённого запроса.
 
 max_result_bytes
--------------
+----------------
 Ограничение на количество байт результата. Аналогично.
 
 result_overflow_mode
---------------
+--------------------
 Что делать, если объём результата превысил одно из ограничений: throw или break. По умолчанию: throw.
 Использование break по смыслу похоже на LIMIT.
 
 max_execution_time
---------------
+-------------------
 Максимальное время выполнения запроса в секундах.
 На данный момент не проверяется при одной из стадий сортировки а также при слиянии и финализации агрегатных функций.
 
 timeout_overflow_mode
----------------
+---------------------
 Что делать, если запрос выполняется дольше max_execution_time: throw или break. По умолчанию: throw.
 
 min_execution_speed
---------------
+-------------------
 Минимальная скорость выполнения запроса в строчках в секунду. Проверяется на каждый блок данных по истечении timeout_before_checking_execution_speed. Если скорость выполнения запроса оказывается меньше, то кидается исключение.
 
 timeout_before_checking_execution_speed
----------------
+---------------------------------------
 Проверять, что скорость выполнения запроса не слишком низкая (не меньше min_execution_speed), после прошествия указанного времени в секундах.
 
 max_columns_to_read
---------------
+-------------------
 Максимальное количество столбцов, которых можно читать из таблицы в одном запросе. Если запрос требует чтения большего количества столбцов - кинуть исключение.
 
 max_temporary_columns
-----------------
+---------------------
 Максимальное количество временных столбцов, которых необходимо одновременно держать в оперативке, в процессе выполнения запроса, включая константные столбцы. Если временных столбцов оказалось больше - кидается исключение.
 
 max_temporary_non_const_columns
----------------------
+-------------------------------
 То же самое, что и max_temporary_columns, но без учёта столбцов-констант.
 Стоит заметить, что столбцы-константы довольно часто образуются в процессе выполнения запроса, но расходуют примерно нулевое количество вычислительных ресурсов.
 
 max_subquery_depth
--------------
+------------------
 Максимальная вложенность подзапросов. Если подзапросы более глубокие - кидается исключение. По умолчанию: 100.
 
 max_pipeline_depth
------------
+------------------
 Максимальная глубина конвейера выполнения запроса. Соответствует количеству преобразований, которое проходит каждый блок данных в процессе выполнения запроса. Считается в пределах одного сервера. Если глубина конвейера больше - кидается исключение. По умолчанию: 1000.
 
 max_ast_depth
------------
+-------------
 Максимальная вложенность синтаксического дерева запроса. Если превышена - кидается исключение.
 На данный момент, проверяются не во время парсинга а уже после парсинга запроса. То есть, во время парсинга может быть создано слишком глубокое синтаксическое дерево, но запрос не будет выполнен. По умолчанию: 1000.
 
 max_ast_elements
------------
+----------------
 Максимальное количество элементов синтаксического дерева запроса. Если превышено - кидается исключение.
 Аналогично, проверяется уже после парсинга запроса. По умолчанию: 10 000.
 
 max_rows_in_set
-----------
+---------------
 Максимальное количество строчек для множества в секции IN, создаваемого из подзапроса.
 
 max_bytes_in_set
------------
+----------------
 Максимальное количество байт (несжатых данных), занимаемое множеством в секции IN, создаваемым из подзапроса.
 
 set_overflow_mode
------------
+-----------------
 Что делать, когда количество данных превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_rows_in_distinct
------------
+--------------------
 Максимальное количество различных строчек при использовании DISTINCT.
 
 max_bytes_in_distinct
---------------
+---------------------
 Максимальное количество байт, занимаемых хэш-таблицей, при использовании DISTINCT.
 
 distinct_overflow_mode
-------------
+----------------------
 Что делать, когда количество данных превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_rows_to_transfer
------------
+--------------------
 Максимальное количество строчек, которых можно передать на удалённый сервер или сохранить во временную таблицу, при использовании GLOBAL IN.
 
 max_bytes_to_transfer
------------
+---------------------
 Максимальное количество байт (несжатых данных), которых можно передать на удалённый сервер или сохранить во временную таблицу, при использовании GLOBAL IN.
 
 transfer_overflow_mode
----------
+----------------------
 Что делать, когда количество данных превысило одно из ограничений: throw или break. По умолчанию: throw.

docs/ru/settings/settings.rst

@@ -2,10 +2,16 @@
 
 distributed_product_mode
 ------------------------
-Изменяет поведение :ref:`распределенных подзапросов <queries-distributed-subrequests>`.
+Изменяет поведение :ref:`распределенных подзапросов <queries-distributed-subrequests>`, т.е. в тех случаях, когда запрос содержит произведение распределённых таблиц.
 
 ClickHouse применяет настройку в том случае, когда в подзапросах на любом уровне встретилась распределенная таблица, которая существует на локальном сервере и имеет больше одного шарда.
 
+Условия применения:
+
+* Только подзапросы для IN, JOIN.
+* Только если в секции FROM используется распределённая таблица.
+* Не используется в случае табличной функции :ref:`remote <table_functions-remote>`.
+
 Возможные значения:
 
 .. list-table::
@@ -14,7 +20,7 @@ ClickHouse применяет настройку в том случае, ког
 
     * - Значение
       - Поведение ClickHouse
-    * - ``deny``
+    * - ``deny`` (по умолчанию)
       - Генерирует исключение.
     * - ``allow``
       - Выполняет запрос без изменения логики.
@@ -162,6 +168,8 @@ replace_running_query
 
 Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить.
 
+.. _settings-load_balancing:
+
 load_balancing
 --------------
 На какие реплики (среди живых реплик) предпочитать отправлять запрос (при первой попытке) при распределённой обработке запроса.

docs/ru/table_functions/remote.rst

@@ -1,62 +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-0{1,2}-1
+    example01-01-1,example01-02-1
 
-В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом:
-::
-  example01-{01..02}-1
+Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом: ::
+
+    example01-0{1,2}-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 в целях исследований;
  * нечастых распределённых запросов, задаваемых вручную;
  * распределённых запросов, где набор серверов определяется каждый раз заново.
 
-Имя пользователя может быть не задано - тогда используется имя пользователя 'default'.
-Пароль может быть не задан - тогда используется пустой пароль.
+Если пользователь не задан,то используется ``default``.
+Если пароль не задан, то используется пустой пароль.