From 9fcf76fead4d17266bf8b57ebb8a890819600d12 Mon Sep 17 00:00:00 2001 From: BayoNet Date: Tue, 7 Nov 2017 14:39:22 +0300 Subject: [PATCH] Syncronization with the 'rst' sources. --- docs/ru/agg_functions/reference.md | 7 +++++++ docs/ru/formats/capnproto.md | 21 +++++++++++++++++++++ docs/ru/query_language/queries.md | 14 ++++++++++++-- 3 files changed, 40 insertions(+), 2 deletions(-) create mode 100644 docs/ru/formats/capnproto.md diff --git a/docs/ru/agg_functions/reference.md b/docs/ru/agg_functions/reference.md index aa685a28685..57380e178e8 100644 --- a/docs/ru/agg_functions/reference.md +++ b/docs/ru/agg_functions/reference.md @@ -54,6 +54,13 @@ sum(x) Вычисляет сумму. Работает только для чисел. +sumWithOverflow(x) +------------------ + +Вычисляет сумму чисел, используя для результата тот же тип данных, что и для входных параметров. Если сумма выйдет за максимальное значение для заданного типа данных, то функция вернёт ошибку. + +Работает только для чисел. + sumMap(key, value) ------------------ diff --git a/docs/ru/formats/capnproto.md b/docs/ru/formats/capnproto.md new file mode 100644 index 00000000000..570334f9161 --- /dev/null +++ b/docs/ru/formats/capnproto.md @@ -0,0 +1,21 @@ +CapnProto +========= + +Cap'n Proto - формат бинарных сообщений, похож на Protocol Buffers и Thrift, но не похож на JSON или MessagePack. + +Сообщения Cap'n Proto строго типизированы и не самоописывающиеся, т.е. нуждаются во внешнем описании схемы. Схема применяется "на лету" и кешируется для каждого запроса. + +```sql +SELECT SearchPhrase, count() AS c FROM test.hits GROUP BY SearchPhrase FORMAT CapnProto SETTINGS schema = 'schema.capnp:Message' +``` + +When the schema file looks like: + +``` +struct Message { + SearchPhrase @0 :Text; + c @1 :Uint64; +} +``` + +Десериализация эффективна и обычно не повышает нагрузку на систему. diff --git a/docs/ru/query_language/queries.md b/docs/ru/query_language/queries.md index 00e498687be..6fafab1f7d7 100644 --- a/docs/ru/query_language/queries.md +++ b/docs/ru/query_language/queries.md @@ -109,11 +109,15 @@ CREATE TABLE IF NOT EXISTS all_hits ON CLUSTER cluster (p Date, i Int32) ENGINE ### CREATE VIEW ```sql -CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]name [ENGINE = engine] [POPULATE] AS SELECT ... +CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]name [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ... ``` Создаёт представление. Представления бывают двух видов - обычные и материализованные (MATERIALIZED). +При создании материализованного представления, нужно обязательно указать ENGINE - движок таблицы для хранения данных. + +Материализованное представление работает следующим образом: при вставлении данных в таблицу, указанную в SELECT, часть вставленных данных конвертируется запросом, а результат вставляется в представление. + Обычные представления не хранят никаких данных, а всего лишь производят чтение из другой таблицы. То есть, обычное представление - не более чем сохранённый запрос. При чтении из представления, этот сохранённый запрос, используется в качестве подзапроса в секции FROM. Для примера, пусть вы создали представление: @@ -144,7 +148,7 @@ SELECT a, b, c FROM (SELECT ...) Запрос `SELECT` может содержать `DISTINCT`, `GROUP BY`, `ORDER BY`, `LIMIT`... Следует иметь ввиду, что соответствующие преобразования будут выполняться независимо, на каждый блок вставляемых данных. Например, при наличии `GROUP BY`, данные будут агрегироваться при вставке, но только в рамках одной пачки вставляемых данных. Далее, данные не будут доагрегированы. Исключение - использование ENGINE, производящего агрегацию данных самостоятельно, например, `SummingMergeTree`. -Недоработано выполнение запросов `ALTER` над материализованными представлениями, поэтому они могут быть неудобными для использования. +Недоработано выполнение запросов `ALTER` над материализованными представлениями, поэтому они могут быть неудобными для использования. Если материализованное представление использует конструкцию ``TO [db.]name``, то можно выполнить ``DETACH`` представления, ``ALTER`` для целевой таблицы и последующий ``ATTACH`` ранее отсоединенного (``DETACH``) представления. Представления выглядят так же, как обычные таблицы. Например, они перечисляются в результате запроса `SHOW TABLES`. @@ -156,6 +160,12 @@ SELECT a, b, c FROM (SELECT ...) - запрос не создаёт данные на диске, а предполагает, что данные уже лежат в соответствующих местах, и всего лишь добавляет информацию о таблице в сервер. После выполнения запроса ATTACH, сервер будет знать о существовании таблицы. +Если таблица перед этим была отсоединена (``DETACH``), т.е. её структура известна, то можно использовать сокращенную форму записи без определения структуры. + +```sql +ATTACH TABLE [IF NOT EXISTS] [db.]name +``` + Этот запрос используется при старте сервера. Сервер хранит метаданные таблиц в виде файлов с запросами `ATTACH`, которые он просто исполняет при запуске (за исключением системных таблиц, создание которых явно вписано в сервер). ### DROP