Merge branch 'master' of github.com:yandex/ClickHouse

doc/reference_ru.html

@@ -1351,7 +1351,7 @@ ALTER TABLE ... FREEZE PARTITION копирует только данные, н
 
 %%SHOW TABLES [FROM db] [LIKE 'pattern'] [FORMAT format]%%
 
-Вывозит список таблиц
+Выводит список таблиц
 - из текущей БД или из БД db, если указано FROM db;
 - всех, или имя которых соответствует шаблону pattern, если указано LIKE 'pattern';
 
@@ -1367,19 +1367,19 @@ ALTER TABLE ... FREEZE PARTITION копирует только данные, н
 
 Выдаёт таблицу, содержащую столбцы:
 
-<b>user</b> - пользователь, под которым был задан запрос. Следует иметь ввиду, что при распределённой обработке запроса, на удалённые серверы запросы отправляются под пользователем default. И SHOW PROCESSLIST показывает имя пользователя для конкретного запроса, а не для запроса, который данный запрос инициировал.
+<b>user</b> - пользователь, под которым был задан запрос. Следует иметь ввиду, что при распределённой обработке запроса на удалённые серверы запросы отправляются под пользователем default. И SHOW PROCESSLIST показывает имя пользователя для конкретного запроса, а не для запроса, который данный запрос инициировал.
 
-<b>address</b> - имя хоста, с которого был отправлен запрос. При распределённой обработке запроса, на удалённых серверах, это - имя хоста-инициатора запроса. Чтобы проследить, откуда был задан распределённый запрос изначально, следует смотреть SHOW PROCESSLIST на сервере-инициаторе запроса.
+<b>address</b> - имя хоста, с которого был отправлен запрос. При распределённой обработке запроса на удалённых серверах — это имя хоста-инициатора запроса. Чтобы проследить, откуда был задан распределённый запрос изначально, следует смотреть SHOW PROCESSLIST на сервере-инициаторе запроса.
 
 <b>elapsed</b> - время выполнения запроса, в секундах. Запросы выводятся упорядоченными по убыванию времени выполнения.
 
-<b>rows_read</b>, <b>bytes_read</b> - сколько было прочитано строк, байт несжатых данных при обработке запроса. При распределённой обработке запроса, суммируются данные со всех удалённых серверов. Именно эти данные используются для ограничений и квот.
+<b>rows_read</b>, <b>bytes_read</b> - сколько было прочитано строк, байт несжатых данных при обработке запроса. При распределённой обработке запроса суммируются данные со всех удалённых серверов. Именно эти данные используются для ограничений и квот.
 
 <b>memory_usage</b> - текущее потребление оперативки в байтах. Смотрите настройку max_memory_usage.
 
-<b>query</b> - сам запрос. В запросах INSERT, данные для вставки не выводятся.
+<b>query</b> - сам запрос. В запросах INSERT данные для вставки не выводятся.
 
-<b>query_id</b> - идентификатор запроса. Непустой, только если был явно задан пользователем. При распределённой обработке запроса, идентификатор запроса не передаётся на удалённые серверы.
+<b>query_id</b> - идентификатор запроса. Непустой, только если был явно задан пользователем. При распределённой обработке запроса идентификатор запроса не передаётся на удалённые серверы.
 
 Запрос полностью аналогичен запросу: SELECT * FROM system.processes [FORMAT format].
 
@@ -1440,7 +1440,7 @@ ALTER TABLE ... FREEZE PARTITION копирует только данные, н
 Просит движок таблицы сделать что-нибудь, что может привести к более оптимальной работе.
 Поддерживается только движками *MergeTree, в котором выполнение этого запроса инициирует внеочередное слияние кусков данных.
 
-Для реплицируемых таблиц, запрос OPTIMIZE применяется только к нереплицируемым данным (эти данные присутствуют только после преобразования нереплицируемой таблицы в реплицируемую). Если такие отсутствуют, то запрос ничего не делает.
+Для реплицируемых таблиц запрос OPTIMIZE применяется только к нереплицируемым данным (эти данные присутствуют только после преобразования нереплицируемой таблицы в реплицируемую). Если такие отсутствуют, то запрос ничего не делает.
 
 
 ===INSERT===
@@ -1851,7 +1851,7 @@ GLOBAL - распределённость:
 
 Возможны все комбинации JOIN-ов. Например, %%GLOBAL ANY LEFT OUTER JOIN%%.
 
-При выполнении JOIN-а, отсутствует оптимизация порядка выполнения по отношению к другим стадиям запроса: соединение (поиск в "правой" таблице) выполняется до фильтрации в WHERE, до агрегации. Поэтому, чтобы явно задать порядок вычислений, рекомендуется выполнять JOIN подзапроса с подзапросом.
+При выполнении JOIN-а отсутствует оптимизация порядка выполнения по отношению к другим стадиям запроса: соединение (поиск в "правой" таблице) выполняется до фильтрации в WHERE, до агрегации. Поэтому, чтобы явно задать порядок вычислений, рекомендуется выполнять JOIN подзапроса с подзапросом.
 
 Пример:
 %%
@@ -1911,7 +1911,7 @@ LIMIT 10
 <h4>Секция WHERE</h4>
 
 Секция WHERE, если есть, должна содержать выражение, имеющее тип UInt8. Обычно это какое-либо выражение с операторами сравнения и логическими операторами.
-Это выражение будет использовано для фильтрации данных, перед всеми остальными преобразованиями.
+Это выражение будет использовано для фильтрации данных перед всеми остальными преобразованиями.
 
 Выражение анализируется на возможность использования индексов, если индексы поддерживаются движком таблицы.
 
@@ -1950,9 +1950,9 @@ PREWHERE поддерживается только таблицами семей
     count() - sum(Refresh)
 FROM hits%%
 
-Но, в отличие от стандартного SQL, если в таблице нет строк (вообще нет, или после фильтрации с помощью WHERE), в качестве результата возвращается пустой результат, а не результат из одной строки, содержащий "начальные" значения агрегатных функций.
+Но, в отличие от стандартного SQL, если в таблице нет строк (вообще нет или после фильтрации с помощью WHERE), в качестве результата возвращается пустой результат, а не результат из одной строки, содержащий "начальные" значения агрегатных функций.
 
-В отличие от MySQL (и в соответствии со стандартом SQL), вы не можете получить какое-нибудь значение некоторого столбца, не входящего в ключ или агрегатную функцию (за исключением константных выражений). Для обхода этого, вы можете воспользоваться агрегатной функцией any (получить первое попавшееся значение) или min/max.
+В отличие от MySQL (и в соответствии со стандартом SQL), вы не можете получить какое-нибудь значение некоторого столбца, не входящего в ключ или агрегатную функцию (за исключением константных выражений). Для обхода этого вы можете воспользоваться агрегатной функцией any (получить первое попавшееся значение) или min/max.
 
 Пример:
 
@@ -1972,44 +1972,44 @@ GROUP BY вычисляет для каждого встретившегося
 
 <h5>Модификатор WITH TOTALS</h5>
 
-Если указан модификатор WITH TOTALS, то будет посчитана ещё одна строчка, в которой, в столбцах-ключах будут содержаться значения по умолчанию (нули, пустые строки), а в столбцах агрегатных функций - значения, посчитанные по всем строкам ("тотальные" значения).
+Если указан модификатор WITH TOTALS, то будет посчитана ещё одна строчка, в которой в столбцах-ключах будут содержаться значения по умолчанию (нули, пустые строки), а в столбцах агрегатных функций - значения, посчитанные по всем строкам ("тотальные" значения).
 
-Эта дополнительная строчка выводится в форматах JSON*, TabSeparated*, Pretty* отдельно от остальных строчек. В остальных форматах, эта строчка не выводится.
+Эта дополнительная строчка выводится в форматах JSON*, TabSeparated*, Pretty* отдельно от остальных строчек. В остальных форматах эта строчка не выводится.
 
-В форматах JSON*, строчка выводится отдельным полем totals. В форматах TabSeparated строчка выводится после основного результата, и перед ней (после остальных данных) вставляется пустая строка. В форматах Pretty, строчка выводится отдельной табличкой, после основного результата.
+В форматах JSON* строчка выводится отдельным полем totals. В форматах TabSeparated* строчка выводится после основного результата, и перед ней (после остальных данных) вставляется пустая строка. В форматах Pretty* строчка выводится отдельной табличкой после основного результата.
 
 WITH TOTALS может выполняться по-разному при наличии HAVING. Поведение зависит от настройки totals_mode.
-По умолчанию, totals_mode = '<b>before_having</b>'. В этом случае, totals считается по всем строчкам, включая непрошедших через HAVING и max_rows_to_group_by.
+По умолчанию totals_mode = '<b>before_having</b>'. В этом случае totals считается по всем строчкам, включая непрошедших через HAVING и max_rows_to_group_by.
 
 Остальные варианты учитывают в totals только строчки, прошедшие через HAVING, и имеют разное поведение при наличии настройки max_rows_to_group_by и group_by_overflow_mode = 'any'.
 
-<b>after_having_exclusive</b> - не учитывать строчки, не прошедшие max_rows_to_group_by. То есть, в totals попадёт меньше или столько же строчек, чем если бы max_rows_to_group_by не было.
+<b>after_having_exclusive</b> - не учитывать строчки, не прошедшие max_rows_to_group_by. То есть в totals попадёт меньше или столько же строчек, чем если бы max_rows_to_group_by не было.
 
-<b>after_having_inclusive</b> - учитывать в totals все строчки, не прошедшие max_rows_to_group_by. То есть, в totals попадёт больше или столько же строчек, чем если бы max_rows_to_group_by не было.
+<b>after_having_inclusive</b> - учитывать в totals все строчки, не прошедшие max_rows_to_group_by. То есть в totals попадёт больше или столько же строчек, чем если бы max_rows_to_group_by не было.
 
 <b>after_having_auto</b> - считать долю строчек, прошедших через HAVING. Если она больше некоторого значения (по умолчанию - 50%), то включить все строчки, не прошедшние max_rows_to_group_by в totals, иначе - не включить.
 
-<b>totals_auto_threshold</b> - по умолчанию, 0.5 - коэффициент для работы <b>after_having_auto</b>.
+<b>totals_auto_threshold</b> - по умолчанию 0.5. Коэффициент для работы <b>after_having_auto</b>.
 
-Если max_rows_to_group_by и group_by_overflow_mode = 'any' не используются, то все варианты вида after_having не отличаются, и вы можете использовать любой из них - например, after_having_auto.
+Если max_rows_to_group_by и group_by_overflow_mode = 'any' не используются, то все варианты вида after_having не отличаются, и вы можете использовать любой из них, например, after_having_auto.
 
-Вы можете использовать WITH TOTALS в подзапросах, включая подзапросы в секции JOIN - в этом случае, соответствующие тотальные значения будут соединены.
+Вы можете использовать WITH TOTALS в подзапросах, включая подзапросы в секции JOIN (в этом случае соответствующие тотальные значения будут соединены).
 
 
 <h5>GROUP BY во внешней памяти</h5>
 
 Существует возможность включить сброс временных данных на диск для ограничения потребления оперативной памяти при GROUP BY.
-Настройка %%max_bytes_before_external_group_by%% - потребление оперативки, при котором временные данные GROUP BY сбрасываются в файловую систему. Если равно 0 (по-умолчанию) - значит выключено.
+Настройка %%max_bytes_before_external_group_by%% - потребление оперативки, при котором временные данные GROUP BY сбрасываются в файловую систему. Если равно 0 (по умолчанию) - значит выключено.
 
-При использовании %%max_bytes_before_external_group_by%%, рекомендуется выставить %%max_memory_usage%% примерно в два раза больше. Это следует сделать, потому что агрегация выполняется в две стадии: чтение и формирование промежуточных данных (1) и слияние промежуточных данных (2). Сброс данных на файловую систему может производиться только на стадии 1. Если сброса временных данных не было, то на стадии 2 может потребляться до такого же объёма памяти, как на стадии 1.
+При использовании %%max_bytes_before_external_group_by%% рекомендуется выставить %%max_memory_usage%% примерно в два раза больше. Это следует сделать, потому что агрегация выполняется в две стадии: чтение и формирование промежуточных данных (1) и слияние промежуточных данных (2). Сброс данных на файловую систему может производиться только на стадии 1. Если сброса временных данных не было, то на стадии 2 может потребляться до такого же объёма памяти, как на стадии 1.
 
-Например, если у вас %%max_memory_usage%% было высталвлено в 10000000000, и вы хотите использовать внешнюю агрегацию, то имеет смысл выставить %%max_bytes_before_external_group_by%% в 10000000000, а %%max_memory_usage%% в 20000000000. При срабатывании внешней агрегации (если был хотя бы один сброс временных данных в файловую систему), максимальное потребление оперативки будет лишь чуть-чуть больше %%max_bytes_before_external_group_by%%.
+Например, если у вас %%max_memory_usage%% было высталвлено в 10000000000, и вы хотите использовать внешнюю агрегацию, то имеет смысл выставить %%max_bytes_before_external_group_by%% в 10000000000, а %%max_memory_usage%% в 20000000000. При срабатывании внешней агрегации (если был хотя бы один сброс временных данных в файловую систему) максимальное потребление оперативки будет лишь чуть-чуть больше %%max_bytes_before_external_group_by%%.
 
-При распределённой обработке запроса, внешняя агрегация производится на удалённых серверах. Для того, чтобы на сервере-инициаторе запроса использовалось немного оперативки, нужно выставить настройку %%distributed_aggregation_memory_efficient%% в 1.
+При распределённой обработке запроса внешняя агрегация производится на удалённых серверах. Для того чтобы на сервере-инициаторе запроса использовалось немного оперативки, нужно выставить настройку %%distributed_aggregation_memory_efficient%% в 1.
 
 При слиянии данных, сброшенных на диск, а также при слиянии результатов с удалённых серверов, при включенной настройке %%distributed_aggregation_memory_efficient%%, потребляется до 1/256 * количество потоков от общего объёма оперативки.
 
-При включенной внешней агрегации, если данных было меньше %%max_bytes_before_external_group_by%% - то есть, если сброса данных не было, то запрос работает так же быстро, как без внешней агрегации. Если же какие-то временные данные были сброшены, то время выполнения будет в несколько раз больше - примерно в три раза.
+При включенной внешней агрегации, если данных было меньше %%max_bytes_before_external_group_by%% (то есть сброса данных не было), то запрос работает так же быстро, как без внешней агрегации. Если же какие-то временные данные были сброшены, то время выполнения будет в несколько раз больше (примерно в три раза).
 
 Если после GROUP BY у вас есть ORDER BY с небольшим LIMIT, то на ORDER BY не будет тратиться существенного количества оперативки.
 Но если есть ORDER BY без LIMIT, то не забудьте включить внешнюю сортировку (%%max_bytes_before_external_sort%%).
@@ -2026,7 +2026,7 @@ WHERE и HAVING отличаются тем, что WHERE выполняется
 
 Секция ORDER BY содержит список выражений, к каждому из которых также может быть приписано DESC или ASC (направление сортировки). Если ничего не приписано - это аналогично приписыванию ASC. ASC - сортировка по возрастанию, DESC - сортировка по убыванию. Обозначение направления сортировки действует на одно выражение, а не на весь список. Пример: %%ORDER BY Visits DESC, SearchPhrase%%
 
-Для сортировки по значениям типа String есть возможность указать collation (сравнение). Пример: %%ORDER BY SearchPhrase COLLATE 'tr'%% - для сортировки по поисковой фразе, по возрастанию, с учётом турецкого алфавита, регистронезависимо, при допущении, что строки в кодировке UTF-8. COLLATE может быть указан или не указан для каждого выражения в ORDER BY независимо. Если есть ASC или DESC, то COLLATE указывается после них. При использовании COLLATE, сортировка всегда регистронезависима.
+Для сортировки по значениям типа String есть возможность указать collation (сравнение). Пример: %%ORDER BY SearchPhrase COLLATE 'tr'%% - для сортировки по поисковой фразе, по возрастанию, с учётом турецкого алфавита, регистронезависимо, при допущении, что строки в кодировке UTF-8. COLLATE может быть указан или не указан для каждого выражения в ORDER BY независимо. Если есть ASC или DESC, то COLLATE указывается после них. При использовании COLLATE сортировка всегда регистронезависима.
 
 Рекомендуется использовать COLLATE только для окончательной сортировки небольшого количества строк, так как производительность сортировки с указанием COLLATE меньше, чем обычной сортировки по байтам.
 
@@ -2237,7 +2237,7 @@ ORDER BY EventDate ASC
 
 Вычисляются дополнительные две строчки - минимумы и максимумы, соответственно. Эти дополнительные две строчки выводятся в форматах JSON*, TabSeparated*, Pretty* отдельно от остальных строчек. В остальных форматах они не выводится.
 
-В форматах JSON*, экстремальные значения выводятся отдельным полем extremes. В форматах TabSeparated строчка выводится после основного результата, и после totals, если есть. Перед ней (после остальных данных) вставляется пустая строка. В форматах Pretty, строчка выводится отдельной табличкой, после основного результата, и после totals, если есть.
+В форматах JSON*, экстремальные значения выводятся отдельным полем extremes. В форматах TabSeparated* строчка выводится после основного результата, и после totals, если есть. Перед ней (после остальных данных) вставляется пустая строка. В форматах Pretty*, строчка выводится отдельной табличкой, после основного результата, и после totals, если есть.
 
 Экстремальные значения считаются по строчкам, прошедшим через LIMIT. Но при этом, при использовании LIMIT offset, size, строчки до offset, учитываются в extremes. В потоковых запросах, в результате может учитываться также небольшое количество строчек, прошедших LIMIT.