RU Docs spelling fix

doc/reference_ru.html

@@ -2098,12 +2098,12 @@ SELECT CounterID, 2 AS table, sum(Sign) AS c
 
 <h4>Секция FORMAT</h4>
 
-При указании FORMAT format, вы можете получить данные в любом указанном формате.
+При указании FORMAT format вы можете получить данные в любом указанном формате.
 Это может использоваться для удобства или для создания дампов.
 Подробнее смотрите раздел "Форматы".
 Если секция FORMAT отсутствует, то используется формат по умолчанию, который зависит от используемого интерфейся для доступа к БД и от настроек. Для HTTP интерфейса, а также для клиента командной строки, используемого в batch режиме, по умолчанию используется формат TabSeparated. Для клиента командной строки, используемого в интерактивном режиме, по умолчанию используется формат PrettyCompact (прикольные таблички, компактные).
 
-При использовании клиента командной строки, данные на клиент передаются во внутреннем эффективном формате. При этом, клиент самостоятельно интерпретирует секцию FORMAT запроса и форматирует данные на своей стороне (снимая нагрузку на сеть и сервер).
+При использовании клиента командной строки данные на клиент передаются во внутреннем эффективном формате. При этом клиент самостоятельно интерпретирует секцию FORMAT запроса и форматирует данные на своей стороне (снимая нагрузку на сеть и сервер).
 
 
 <h4>Операторы IN</h4>
@@ -2121,13 +2121,13 @@ SELECT CounterID, 2 AS table, sum(Sign) AS c
 
 Не перечисляйте слишком большое количество значений (миллионы) явно. Если множество большое - лучше загрузить его во временную таблицу (например, смотрите раздел "Внешние данные для обработки запроса"), и затем воспользоваться подзапросом.
 
-В качестве правой части оператора, может быть множество константных выражений, множество кортежей с константными выражениями (показано в примерах выше), а также имя таблицы или подзапрос SELECT в скобках.
+В качестве правой части оператора может быть множество константных выражений, множество кортежей с константными выражениями (показано в примерах выше), а также имя таблицы или подзапрос SELECT в скобках.
 
-Если в качестве правой части оператора, указано имя таблицы (например, %%UserID IN users%%), то это эквивалентно подзапросу %%UserID IN (SELECT * FROM users)%%. Это используется при работе с внешними данными, отправляемым вместе с запросом. Например, вместе с запросом может быть отправлено множество идентификаторов посетителей, загруженное во временную таблицу users, по которому следует выполнить фильтрацию.
+Если в качестве правой части оператора указано имя таблицы (например, %%UserID IN users%%), то это эквивалентно подзапросу %%UserID IN (SELECT * FROM users)%%. Это используется при работе с внешними данными, отправляемым вместе с запросом. Например, вместе с запросом может быть отправлено множество идентификаторов посетителей, загруженное во временную таблицу users, по которому следует выполнить фильтрацию.
 
 Если качестве правой части оператора, указано имя таблицы, имеющий движок Set (подготовленное множество, постоянно находящееся в оперативке), то множество не будет создаваться заново при каждом запросе.
 
-В подзапросе может быть указано более одного столбца, для фильтрации кортежей.
+В подзапросе может быть указано более одного столбца для фильтрации кортежей.
 Пример:
 %%SELECT (CounterID, UserID) IN (SELECT CounterID, UserID FROM ...) FROM ...%%
 
@@ -2139,7 +2139,7 @@ SELECT CounterID, 2 AS table, sum(Sign) AS c
 Если слева от NOT IN стоит массив, то проверяется, что хотя бы один элемент массива не принадлежит множеству.
 Например, %%[1, 2, 3] NOT IN (3, 4, 5)%% вернёт 1. Это совсем нелогично, и лучше не полагаться на такое поведение. Лучше воспользуйтесь функциями высшего порядка. Пример: <span class="inline-example">arrayAll(x -> x IN (3, 4, 5), [1, 2, 3])</span> вернёт 0 - проверяет принадлежность всех элементов массива множеству.
 
-Оператор IN и подзапрос могут встречаться в любой части запроса - в том числе, в агрегатных функциях, в лямбда функциях.
+Оператор IN и подзапрос могут встречаться в любой части запроса, в том числе в агрегатных и лямбда функциях.
 Пример:
 
 %%SELECT
@@ -2164,14 +2164,14 @@ ORDER BY EventDate ASC
 │ 2014-03-23 │ 0.648416 │
 └────────────┴──────────┘
 %%
-- за каждый день после 17 марта, посчитать долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
+- за каждый день после 17 марта считаем долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
 
-Подзапрос в секции IN, на одном сервере, всегда выполняется только один раз. Зависимых подзапросов не существует.
+Подзапрос в секции IN на одном сервере всегда выполняется только один раз. Зависимых подзапросов не существует.
 
 
 <h4>Распределённые подзапросы</h4>
 
-Существует два варианта IN-ов с подзапросами (аналогично, для JOIN-ов): обычный %%IN%% / %%JOIN%% и %%GLOBAL IN%% / %%GLOBAL JOIN%%. Они отличаются способом выполнения при распределённой обработке запроса.
+Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный %%IN%% / %%JOIN%% и %%GLOBAL IN%% / %%GLOBAL JOIN%%. Они отличаются способом выполнения при распределённой обработке запроса.
 
 При использовании обычного %%IN%%-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях IN / JOIN.
 
@@ -2200,7 +2200,7 @@ ORDER BY EventDate ASC
 %%SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM local_table WHERE CounterID = 34)%%
 То есть, множество в секции %%IN%% будет собрано на каждом сервере независимо, только по тем данным, которые есть локально на каждом из серверов.
 
-Это будет работать правильно и оптимально, если вы предусмотрели такой случай, и раскладываете данные по серверам кластера таким образом, чтобы данные одного UserID-а лежали только на одном сервере. В таком случае, все необходимые данные будут присутствовать на каждом сервере локально. В противном случае, результат будет посчитан неточно. Назовём этот вариант запроса "локальный IN".
+Это будет работать правильно и оптимально, если вы предусмотрели такой случай, и раскладываете данные по серверам кластера таким образом, чтобы данные одного UserID-а лежали только на одном сервере. В таком случае все необходимые данные будут присутствовать на каждом сервере локально. В противном случае результат будет посчитан неточно. Назовём этот вариант запроса "локальный IN".
 
 Чтобы исправить работу запроса, когда данные размазаны по серверам кластера произвольным образом, можно было бы указать <b>distributed_table</b> внутри подзапроса. Запрос будет выглядить так:
 %%SELECT uniq(UserID) FROM distributed_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM distributed_table WHERE CounterID = 34)%%
@@ -2211,10 +2211,10 @@ ORDER BY EventDate ASC
 %%SELECT UserID FROM local_table WHERE CounterID = 34%%
 Например, если у вас кластер из 100 серверов, то выполнение всего запроса потребует 10 000 элементарных запросов, что, как правило, является неприемлимым.
 
-В таких случаях, всегда следует использовать %%GLOBAL IN%% вместо %%IN%%. Рассмотрим его работу для запроса
+В таких случаях всегда следует использовать %%GLOBAL IN%% вместо %%IN%%. Рассмотрим его работу для запроса
 %%SELECT uniq(UserID) FROM distributed_table WHERE CounterID = 101500 AND UserID GLOBAL IN (SELECT UserID FROM distributed_table WHERE CounterID = 34)%%
 
-На сервере-инициаторе запроса, будет выполнен подзапрос
+На сервере-инициаторе запроса будет выполнен подзапрос
 %%SELECT UserID FROM distributed_table WHERE CounterID = 34%%
 , и результат будет сложен во временную таблицу в оперативке. Затем запрос будет отправлен на каждый удалённый сервер в виде
 %%SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID GLOBAL IN _data1%%
@@ -2222,9 +2222,9 @@ ORDER BY EventDate ASC
 
 Это гораздо более оптимально, чем при использовании обычного IN. Но при этом, следует помнить о нескольких вещах:
 
-1. При создании временной таблицы, данные не уникализируются. Чтобы уменьшить объём передаваемых по сети данных, укажите в подзапросе %%DISTINCT%%. (Для обычного IN-а этого делать не нужно.)
-2. Временная таблица будет передана на все удалённые серверы. Передача не учитывает топологию сети. Например, если 10 удалённых серверов расположены в удалённом относительно сервера-инициатора запроса датацентре, то по каналу в удалённый датацентр, данные будет переданы 10 раз. Старайтесь не использовать большие множества при использовании %%GLOBAL IN%%.
-3. При передаче данных на удалённые серверы, не настраивается ограничение использования сетевой полосы. Вы можете перегрузить сеть.
+1. При создании временной таблицы данные не уникализируются. Чтобы уменьшить объём передаваемых по сети данных, укажите в подзапросе %%DISTINCT%% (для обычного IN-а этого делать не нужно).
+2. Временная таблица будет передана на все удалённые серверы. Передача не учитывает топологию сети. Например, если 10 удалённых серверов расположены в удалённом относительно сервера-инициатора запроса датацентре, то по каналу в удалённый датацентр данные будет переданы 10 раз. Старайтесь не использовать большие множества при использовании %%GLOBAL IN%%.
+3. При передаче данных на удалённые серверы не настраивается ограничение использования сетевой полосы. Вы можете перегрузить сеть.
 4. Старайтесь распределять данные по серверам так, чтобы в %%GLOBAL IN%%-ах не было частой необходимости.
 5. Если в %%GLOBAL IN%% есть частая необходимость, то спланируйте размещение кластера ClickHouse таким образом, чтобы одна группа реплик располагалась не более чем в одном датацентре, и среди них была быстрая сеть.
 
@@ -2233,13 +2233,13 @@ ORDER BY EventDate ASC
 
 <h4>Экстремальные значения</h4>
 
-Вы можете получить в дополнение к результату также минимальные и максимальные значения по столбцам результата. Для этого, выставите настройку extremes в 1. Минимумы и максимумы считаются для числовых типов, дат, дат-с-временем. Для остальных столбцов, будут выведены значения по умолчанию.
+Вы можете получить в дополнение к результату также минимальные и максимальные значения по столбцам результата. Для этого выставите настройку extremes в 1. Минимумы и максимумы считаются для числовых типов, дат, дат-с-временем. Для остальных столбцов будут выведены значения по умолчанию.
 
 Вычисляются дополнительные две строчки - минимумы и максимумы, соответственно. Эти дополнительные две строчки выводятся в форматах JSON*, TabSeparated*, Pretty* отдельно от остальных строчек. В остальных форматах они не выводится.
 
-В форматах JSON*, экстремальные значения выводятся отдельным полем extremes. В форматах TabSeparated* строчка выводится после основного результата, и после totals, если есть. Перед ней (после остальных данных) вставляется пустая строка. В форматах Pretty*, строчка выводится отдельной табличкой, после основного результата, и после totals, если есть.
+В форматах JSON* экстремальные значения выводятся отдельным полем extremes. В форматах TabSeparated* строчка выводится после основного результата и после totals, если есть. Перед ней (после остальных данных) вставляется пустая строка. В форматах Pretty* строчка выводится отдельной табличкой после основного результата и после totals, если есть.
 
-Экстремальные значения считаются по строчкам, прошедшим через LIMIT. Но при этом, при использовании LIMIT offset, size, строчки до offset, учитываются в extremes. В потоковых запросах, в результате может учитываться также небольшое количество строчек, прошедших LIMIT.
+Экстремальные значения считаются по строчкам, прошедшим через LIMIT. Но при этом, при использовании LIMIT offset, size, строчки до offset учитываются в extremes. В потоковых запросах, в результате может учитываться также небольшое количество строчек, прошедших LIMIT.
 
 
 <h4>Замечания</h4>
@@ -2249,13 +2249,13 @@ ORDER BY EventDate ASC
 
 Вы можете использовать синонимы (алиасы AS) в любом месте запроса.
 
-В любом месте запроса, вместо выражения, может стоять звёздочка. При анализе запроса, звёздочка раскрывается в список всех столбцов таблицы (за исключением MATERIALIZED и ALIAS столбцов). Есть лишь немного случаев, когда оправданно использовать звёздочку:
+В любом месте запроса, вместо выражения, может стоять звёздочка. При анализе запроса звёздочка раскрывается в список всех столбцов таблицы (за исключением MATERIALIZED и ALIAS столбцов). Есть лишь немного случаев, когда оправданно использовать звёздочку:
 - при создании дампа таблицы;
 - для таблиц, содержащих всего несколько столбцов - например, системных таблиц;
 - для получения информации о том, какие столбцы есть в таблице; в этом случае, укажите LIMIT 1. Но лучше используйте запрос <b>DESC TABLE</b>;
 - при наличии сильной фильтрации по небольшому количеству столбцов с помощью PREWHERE;
 - в подзапросах (так как из подзапросов выкидываются столбцы, не нужные для внешнего запроса).
-В других случаях, использование звёздочки является издевательством над системой, так как вместо преимуществ столбцовой СУБД вы получаете недостатки. То есть, использовать звёздочку не рекомендуется.
+В других случаях использование звёздочки является издевательством над системой, так как вместо преимуществ столбцовой СУБД вы получаете недостатки. То есть использовать звёздочку не рекомендуется.
 
 
 </div>