Docapi 4479 merge tree new syntax translate (#4085)

* Update of english version of descriprion of the table function `file`.

* New syntax for ReplacingMergeTree.
Some improvements in text.

* Significantly change article about SummingMergeTree.
Article is restructured, text is changed in many places of the document. New syntax for table creation is described.

* Descriptions of AggregateFunction and AggregatingMergeTree are updated. Russian version.

* New syntax for new syntax of CREATE TABLE

* Added english docs on Aggregating, Replacing and SummingMergeTree.

* CollapsingMergeTree docs. English version.

* 1. Update of CollapsingMergeTree. 2. Minor changes in markup

* Update aggregatefunction.md

* Update aggregatefunction.md

* Update aggregatefunction.md

* Update aggregatingmergetree.md

* GraphiteMergeTree docs update.
New syntax for creation of Replicated* tables.
Minor changes in *MergeTree tables creation syntax.

* Markup fix

* Markup and language fixes

* Clarification in the CollapsingMergeTree article

* DOCAPI-4821. Sync between ru and en versions of docs.

* Fixed the ambiguity in geo functions description.

* Example of JOIN in ru docs

* Deleted misinforming example.

* Fixed links to IN operators.

* Updated the description of ALTER MODIFY.

* [RU] Updated ALTER MODIFY description.

* DOCAPI-4479. English changes are translated into russian.

* DOCAPI-4479. Minor text and markup fixes.

* DOCAPI-4479. Minor text edits.

docs/en/operations/server_settings/settings.md

@@ -163,7 +163,7 @@ You can configure multiple `<graphite>` clauses. For instance, you can use this
 ```
 
 
-## graphite_rollup
+## graphite_rollup {#server_settings-graphite_rollup}
 
 Settings for thinning data for Graphite.
 
@@ -416,7 +416,7 @@ The value 0 means that you can delete all tables without any restrictions.
 ```
 
 
-## merge_tree
+## merge_tree {#server_settings-merge_tree}
 
 Fine tuning for tables in the [ MergeTree](../../operations/table_engines/mergetree.md).
 

docs/en/operations/settings/settings.md

@@ -22,7 +22,7 @@ The possible values are:
 - `allow`  — Allows the use of these types of subqueries.
 
 
-## fallback_to_stale_replicas_for_distributed_queries
+## fallback_to_stale_replicas_for_distributed_queries {#settings-fallback_to_stale_replicas_for_distributed_queries}
 
 Forces a query to an out-of-date replica if updated data is not available. See "[Replication](../../operations/table_engines/replication.md)".
 

docs/en/operations/table_engines/collapsingmergetree.md

@@ -2,7 +2,7 @@
 
 The engine inherits from [MergeTree](mergetree.md) and adds the logic of rows collapsing to data parts merge algorithm.
 
-`CollapsingMergeTree` asynchronously deletes (collapses) pairs of rows if all of the fields in a row are equivalent excepting the particular field `Sign` which can have `1` and `-1` values. Rows without a pair are kept. For more details see the [Collapsing](#collapsing) section of the document.
+`CollapsingMergeTree` asynchronously deletes (collapses) pairs of rows if all of the fields in a row are equivalent excepting the particular field `Sign` which can have `1` and `-1` values. Rows without a pair are kept. For more details see the [Collapsing](#table_engine-collapsingmergetree-collapsing) section of the document.
 
 The engine may significantly reduce the volume of storage and increase efficiency of `SELECT` query as a consequence.
 
@@ -31,7 +31,7 @@ For a description of query parameters, see [query description](../../query_langu
 
 **Query clauses**
 
-When creating a `CollapsingMergeTree` table, the same [clauses](mergetree.md) are required, as when creating a `MergeTree` table.
+When creating a `CollapsingMergeTree` table, the same [query clauses](mergetree.md#table_engine-mergetree-creating-a-table) are required, as when creating a `MergeTree` table.
 
 <details markdown="1"><summary>Deprecated Method for Creating a Table</summary>
 
@@ -55,13 +55,13 @@ All of the parameters excepting `sign` have the same meaning as in `MergeTree`.
 </details>
 
 
-## Collapsing
+## Collapsing {#table_engine-collapsingmergetree-collapsing}
 
 ### Data
 
 Consider the situation where you need to save continually changing data for some object. It sounds logical to have one row for an object and update it at any change, but update operation is expensive and slow for DBMS because it requires rewriting of the data in the storage. If you need to write data quickly, update not acceptable, but you can write the changes of an object sequentially as follows.
 
-Use the particular column `Sign` when writing row. If `Sign = 1` it means that the row is a state of an object, let's call it "state" row. If `Sign = -1` it means the cancellation of the state of an object with the same attributes, let's call it "cancel" row.
+Use the particular column `Sign`. If `Sign = 1` it means that the row is a state of an object, let's call it "state" row. If `Sign = -1` it means the cancellation of the state of an object with the same attributes, let's call it "cancel" row.
 
 For example, we want to calculate how much pages users checked at some site and how long they were there. At some moment of time we write the following row with the state of user activity:
 
@@ -95,15 +95,15 @@ As we need only the last state of user activity, the rows
 
 can be deleted collapsing the invalid (old) state of an object. `CollapsingMergeTree` does this while merging of the data parts.
 
-Why we need 2 rows for each change read in the "Algorithm" paragraph.
+Why we need 2 rows for each change read in the [Algorithm](#table_engine-collapsingmergetree-collapsing-algorithm) paragraph.
 
 **Peculiar properties of such approach**
 
 1. The program that writes the data should remember the state of an object to be able to cancel it. "Cancel" string should be the copy of "state" string with the opposite `Sign`. It increases the initial size of storage but allows to write the data quickly.
 2. Long growing arrays in columns reduce the efficiency of the engine due to load for writing. The more straightforward data, the higher efficiency.
-3. `SELECT` results depend strongly on the consistency of object changes history. Be accurate when preparing data for inserting. You can get unpredictable results in inconsistent data, for example, negative values for non-negative metrics such as session depth.
+3. The `SELECT` results depend strongly on the consistency of object changes history. Be accurate when preparing data for inserting. You can get unpredictable results in inconsistent data, for example, negative values for non-negative metrics such as session depth.
 
-### Algorithm
+### Algorithm {#table_engine-collapsingmergetree-collapsing-algorithm}
 
 When ClickHouse merges data parts, each group of consecutive rows with the same primary key is reduced to not more than two rows, one with `Sign = 1` ("state" row) and another with `Sign = -1` ("cancel" row). In other words, entries collapse.
 
@@ -181,8 +181,8 @@ SELECT * FROM UAct
 ```
 
 What do we see and where is collapsing?
-With two `INSERT` queries, we created 2 data parts. The `SELECT` query was performed in 2 threads, and we got a random order of rows.
-Collapsing not occurred because there was no merge of the data parts yet. ClickHouse merges data part in an unknown moment of time which we can not predict.
+
+With two `INSERT` queries, we created 2 data parts. The `SELECT` query was performed in 2 threads, and we got a random order of rows. Collapsing not occurred because there was no merge of the data parts yet. ClickHouse merges data part in an unknown moment of time which we can not predict.
 
 Thus we need aggregation:
 

docs/en/operations/table_engines/graphitemergetree.md

 
 # GraphiteMergeTree
 
-This engine is designed for rollup (thinning and aggregating/averaging) [Graphite](http://graphite.readthedocs.io/en/latest/index.html) data. It may be helpful to developers who want to use ClickHouse as a data store for Graphite.
+This engine is designed for thinning and aggregating/averaging (rollup) [Graphite](http://graphite.readthedocs.io/en/latest/index.html) data. It may be helpful to developers who want to use ClickHouse as a data store for Graphite.
 
 You can use any ClickHouse table engine to store the Graphite data if you don't need rollup, but if you need a rollup use `GraphiteMergeTree`. The engine reduces the volume of storage and increases the efficiency of queries from Graphite.
 
@@ -29,9 +29,9 @@ For a description of request parameters, see [request description](../../query_l
 A table for the Graphite date should have the following columns:
 
 - Column with the metric name (Graphite sensor). Data type: `String`.
-- Column with the time for measuring the metric. Data type: `DateTime`.
+- Column with the time of measuring the metric. Data type: `DateTime`.
 - Column with the value of the metric. Data type: any numeric.
-- Column with the version of the metric with the same name and time of measurement. Data type: any numeric.
+- Column with the version of the metric. Data type: any numeric.
 
     ClickHouse saves the rows with the highest version or the last written if versions are the same. Other rows are deleted during the merge of data parts.
 
@@ -43,7 +43,7 @@ The names of these columns should be set in the rollup configuration.
 
 **Query clauses**
 
-When creating a `GraphiteMergeTree` table, the same [clauses](mergetree.md) are required, as when creating a `MergeTree` table.
+When creating a `GraphiteMergeTree` table, the same [clauses](mergetree.md#table_engine-mergetree-creating-a-table) are required, as when creating a `MergeTree` table.
 
 <details markdown="1"><summary>Deprecated Method for Creating a Table</summary>
 
@@ -69,7 +69,7 @@ All of the parameters excepting `config_section` have the same meaning as in `Me
 
 ## Rollup configuration
 
-The settings for rollup are defined by the [graphite_rollup](../server_settings/settings.md) parameter in the server configuration. The name of the parameter could be any. You can create several configurations and use them for different tables.
+The settings for rollup are defined by the [graphite_rollup](../server_settings/settings.md#server_settings-graphite_rollup) parameter in the server configuration. The name of the parameter could be any. You can create several configurations and use them for different tables.
 
 Rollup configuration structure:
 
@@ -102,10 +102,9 @@ Fields for `pattern` and `default` sections:
 The `required-columns`:
 
 - `path_column_name` — Column with the metric name (Graphite sensor).
-- `time_column_name` — Column with the time for measuring the metric.
+- `time_column_name` — Column with the time of measuring the metric.
 - `value_column_name` — Column with the value of the metric at the time set in `time_column_name`.
-- `version_column_name` — Column with the version timestamp of the metric with the same name and time remains in the database.
-
+- `version_column_name` — Column with the version of the metric.
 
 Example of settings:
 

docs/en/operations/table_engines/mergetree.md

@@ -26,7 +26,7 @@ Main features:
     The [Merge](merge.md) engine does not belong to the `*MergeTree` family.
 
 
-## Creating a Table
+## Creating a Table  {#table_engine-mergetree-creating-a-table}
 
 ```
 CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]

docs/en/operations/table_engines/replication.md

@@ -18,9 +18,9 @@ Compressed data for `INSERT` and `ALTER` queries is replicated (for more informa
 
 `CREATE`, `DROP`, `ATTACH`, `DETACH` and `RENAME` queries are executed on a single server and are not replicated:
 
-- `The CREATE TABLE` query creates a new replicatable table on the server where the query is run. If this table already exists on other servers, it adds a new replica.
-- `The DROP TABLE` query deletes the replica located on the server where the query is run.
-- `The RENAME` query renames the table on one of the replicas. In other words, replicated tables can have different names on different replicas.
+- The `CREATE TABLE` query creates a new replicatable table on the server where the query is run. If this table already exists on other servers, it adds a new replica.
+- The `DROP TABLE` query deletes the replica located on the server where the query is run.
+- The `RENAME` query renames the table on one of the replicas. In other words, replicated tables can have different names on different replicas.
 
 To use replication, set the addresses of the ZooKeeper cluster in the config file. Example:
 
@@ -47,7 +47,7 @@ You can specify any existing ZooKeeper cluster and the system will use a directo
 
 If ZooKeeper isn't set in the config file, you can't create replicated tables, and any existing replicated tables will be read-only.
 
-ZooKeeper is not used in `SELECT` queries because replication does not affect the performance of `SELECT` and queries run just as fast as they do for non-replicated tables. When querying distributed replicated tables, ClickHouse behavior is controlled by the settings [max_replica_delay_for_distributed_queries](../settings/settings.md#settings-max_replica_delay_for_distributed_queries) and [fallback_to_stale_replicas_for_distributed_queries](../settings/settings.md).
+ZooKeeper is not used in `SELECT` queries because replication does not affect the performance of `SELECT` and queries run just as fast as they do for non-replicated tables. When querying distributed replicated tables, ClickHouse behavior is controlled by the settings [max_replica_delay_for_distributed_queries](../settings/settings.md#settings-max_replica_delay_for_distributed_queries) and [fallback_to_stale_replicas_for_distributed_queries](../settings/settings.md#settings-fallback_to_stale_replicas_for_distributed_queries).
 
 For each `INSERT` query, approximately ten entries are added to ZooKeeper through several transactions. (To be more precise, this is for each inserted block of data; an INSERT query contains one block or one block per `max_insert_block_size = 1048576` rows.) This leads to slightly longer latencies for `INSERT` compared to non-replicated tables. But if you follow the recommendations to insert data in batches of no more than one `INSERT` per second, it doesn't create any problems. The entire ClickHouse cluster used for coordinating one ZooKeeper cluster has a total of several hundred `INSERTs` per second. The throughput on data inserts (the number of rows per second) is just as high as for non-replicated data.
 
@@ -59,7 +59,7 @@ By default, an INSERT query waits for confirmation of writing the data from only
 
 Each block of data is written atomically. The INSERT query is divided into blocks up to `max_insert_block_size = 1048576` rows. In other words, if the `INSERT` query has less than 1048576 rows, it is made atomically.
 
-Data blocks are deduplicated. For multiple writes of the same data block (data blocks of the same size containing the same rows in the same order), the block is only written once. The reason for this is in case of network failures when the client application doesn't know if the data was written to the DB, so the `INSERT` query can simply be repeated. It doesn't matter which replica INSERTs were sent to with identical data. `INSERTs` are idempotent. Deduplication parameters are controlled by [merge_tree](../server_settings/settings.md) server settings.
+Data blocks are deduplicated. For multiple writes of the same data block (data blocks of the same size containing the same rows in the same order), the block is only written once. The reason for this is in case of network failures when the client application doesn't know if the data was written to the DB, so the `INSERT` query can simply be repeated. It doesn't matter which replica INSERTs were sent to with identical data. `INSERTs` are idempotent. Deduplication parameters are controlled by [merge_tree](../server_settings/settings.md#server_settings-merge_tree) server settings.
 
 During replication, only the source data to insert is transferred over the network. Further data transformation (merging) is coordinated and performed on all the replicas in the same way. This minimizes network usage, which means that replication works well when replicas reside in different datacenters. (Note that duplicating data in different datacenters is the main goal of replication.)
 

docs/ru/operations/server_settings/settings.md

@@ -164,7 +164,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
 ```
 
 
-## graphite_rollup
+## graphite_rollup {#server_settings-graphite_rollup}
 
 Настройка прореживания данных для Graphite.
 
@@ -416,7 +416,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
 ```
 
 
-## merge_tree
+## merge_tree {#server_settings-merge_tree}
 
 Тонкая настройка таблиц семейства [MergeTree](../../operations/table_engines/mergetree.md).
 

docs/ru/operations/table_engines/graphitemergetree.md

-
 # GraphiteMergeTree
 
-Движок предназначен для rollup (прореживания и агрегирования/усреднения) данных [Graphite](http://graphite.readthedocs.io/en/latest/index.html). Он может быть интересен разработчикам, которые хотят использовать ClickHouse как хранилище данных для Graphite.
+Движок предназначен для прореживания и агрегирования/усреднения (rollup) данных [Graphite](http://graphite.readthedocs.io/en/latest/index.html). Он может быть интересен разработчикам, которые хотят использовать ClickHouse как хранилище данных для Graphite.
+
+Если rollup не требуется, то для хранения данных Graphite можно использовать любой движок таблиц ClickHouse, в противном случае используйте `GraphiteMergeTree`. Движок уменьшает объем хранения и повышает эффективность запросов от Graphite.
+
+Движок наследует свойства от [MergeTree](mergetree.md).
+
+## Создание таблицы
+
+```sql
+CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
+(
+    Path String,
+    Time DateTime,
+    Value <Numeric_type>,
+    Version <Numeric_type>
+    ...
+) ENGINE = GraphiteMergeTree(config_section)
+[PARTITION BY expr]
+[ORDER BY expr]
+[SAMPLE BY expr]
+[SETTINGS name=value, ...]
+```
+
+Описание параметров запроса смотрите в [описании запроса](../../query_language/create.md).
+
+Таблица для данных Graphite должна содержать следующие столбцы:
 
-Graphite хранит в ClickHouse полные данные, а получать их может следующими способами:
+- Колонка с названием метрики (Graphite sensor). Тип данных: `String`.
 
--   Без прореживания.
+- Столбец со временем измерения метрики. Тип данных `DateTime`.
 
-    Используется движок [MergeTree](mergetree.md).
+- Столбец со значением метрики. Тип данных: любой числовой.
 
--   С прореживанием.
+- Столбец с версией метрики. Тип данных: любой числовой.
 
-    Используется движок `GraphiteMergeTree`.
+    ClickHouse сохраняет строки с последней версией или последнюю записанную строку, если версии совпадают. Другие строки удаляются при слиянии кусков данных.
 
-Движок наследует свойства MergeTree. Настройки прореживания данных задаются параметром [graphite_rollup](../server_settings/settings.md) в конфигурации сервера .
+Имена этих столбцов должны быть заданы в конфигурации rollup.
 
-## Использование движка
+**Параметры GraphiteMergeTree**
 
-Таблица с данными Graphite должна содержать как минимум следующие поля:
+- `config_section` — имя раздела в конфигурационном файле, в котором находятся правила rollup.
 
--   `Path` - имя метрики (сенсора Graphite).
--   `Time` - время измерения.
--   `Value` - значение метрики в момент времени Time.
--   `Version` - настройка, которая определяет какое значение метрики с одинаковыми Path и Time останется в базе.
+**Секции запроса**
 
-Шаблон правил rollup:
+При создании таблицы `GraphiteMergeTree` используются те же [секции](mergetree.md#table_engine-mergetree-creating-a-table) запроса, что при создании таблицы `MergeTree`.
 
+<details markdown="1"><summary>Устаревший способ создания таблицы</summary>
+
+!!! attention
+Не используйте этот способ в новых проектах и по возможности переведите старые проекты на способ описанный выше.
+
+```sql
+CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
+(
+    EventDate Date,
+    Path String,
+    Time DateTime,
+    Value <Numeric_type>,
+    Version <Numeric_type>
+    ...
+) ENGINE [=] GraphiteMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, config_section)
 ```
+
+Все параметры, кроме `config_section` имеют то же значение, что в `MergeTree`.
+
+- `config_section` — имя раздела в конфигурационном файле, в котором находятся правила rollup.
+
+</details>
+
+## Конфигурация rollup
+
+Настройки для прореживания данных задаются параметром [graphite_rollup](../server_settings/settings.md#server_settings-graphite_rollup) Имя параметра может быть любым. Можно создать несколько конфигураций и использовать их для разных таблиц.
+
+Структура конфигурации rollup:
+
+```
+required-columns
 pattern
     regexp
     function
-    age -> precision
+    age + precision
     ...
 pattern
     ...
 default
     function
-       age -> precision
+    age + precision
     ...
 ```
 
-При обработке записи ClickHouse проверит правила в секции `pattern`. Если имя метрики соответствует шаблону `regexp`, то применяются правила из `pattern`, в противном случае из `default`.
+При обработке строки ClickHouse проверяет правила в разделе `pattern`. Если имя метрики соответствует шаблону `regexp`, то  применяются правила из раздела `pattern`, в противном случае из раздела `default`.
+
+Правила определяются с помощью полей `function` и `age + precision`.
+
+Поля для разделов `pattenrn` и `default`:
+
+- `regexp` – шаблон имени метрики.
+- `age` – минимальный возраст данных в секундах.
+- `precision` – точность определения возраста данных в секундах.
+- `function` – имя агрегирующей функции, которую следует применить к данным, чей возраст оказался в интервале `[age, age + precision]`.
 
-Поля шаблона правил.
+`required-columns`:
 
-- `age` - Минимальный возраст данных в секундах.
-- `function` - Имя агрегирующей функции, которую следует применить к данным, чей возраст оказался в интервале `[age, age + precision]`.
-- `precision` - Точность определения возраста данных в секундах.
-- `regexp` - Шаблон имени метрики.
+- `path_column_name` — колонка с названием метрики (Graphite sensor).
+- `time_column_name` — столбец со временем измерения метрики.
+- `value_column_name` — столбец со значением метрики в момент времени, установленный в `time_column_name`.
+- `version_column_name` — столбец с версией метрики.
 
 Пример настройки:
 
 ```xml
 <graphite_rollup>
+    <path_column_name>Path</path_column_name>
+    <time_column_name>Time</time_column_name>
+    <value_column_name>Value</value_column_name>
+    <version_column_name>Version</version_column_name>
     <pattern>
         <regexp>click_cost</regexp>
         <function>any</function>

docs/ru/operations/table_engines/mergetree.md

@@ -24,7 +24,7 @@
     При необходимости можно задать способ сэмплирования данных в таблице.
 
 
-## Создание таблицы
+## Создание таблицы {#table_engine-mergetree-creating-a-table}
 
 ```sql
 CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]

docs/ru/query_language/create.md

 ## CREATE DATABASE
+
 Создание базы данных db_name
 
-``` sql
+```sql
 CREATE DATABASE [IF NOT EXISTS] db_name
 ```
 
 `База данных` - это просто директория для таблиц.
 Если написано `IF NOT EXISTS`, то запрос не будет возвращать ошибку, если база данных уже существует.
 
-
-
 ## CREATE TABLE
+
 Запрос `CREATE TABLE` может иметь несколько форм.
 
-``` sql
-CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name [ON CLUSTER cluster]
+```sql
+CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
 (
     name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [compression_codec],
     name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [compression_codec],
@@ -28,14 +28,14 @@ CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name [ON CLUSTER cluster]
 Описание столбца, это `name type`, в простейшем случае. Пример: `RegionID UInt32`.
 Также могут быть указаны выражения для значений по умолчанию - смотрите ниже.
 
-``` sql
-CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name AS [db2.]name2 [ENGINE = engine]
+```sql
+CREATE TABLE [IF NOT EXISTS] [db.]table_name AS [db2.]name2 [ENGINE = engine]
 ```
 
 Создаёт таблицу с такой же структурой, как другая таблица. Можно указать другой движок для таблицы. Если движок не указан, то будет выбран такой же движок, как у таблицы `db2.name2`.
 
-``` sql
-CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name ENGINE = engine AS SELECT ...
+```sql
+CREATE TABLE [IF NOT EXISTS] [db.]table_name ENGINE = engine AS SELECT ...
 ```
 
 Создаёт таблицу со структурой, как результат запроса `SELECT`, с движком engine, и заполняет её данными из SELECT-а.
@@ -46,7 +46,6 @@ CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name ENGINE = engine AS SELECT ...
 
 ### Значения по умолчанию
 
-
 В описании столбца, может быть указано выражение для значения по умолчанию, одного из следующих видов:
 `DEFAULT expr`, `MATERIALIZED expr`, `ALIAS expr`.
 Пример: `URLDomain String DEFAULT domain(URL)`.
@@ -67,7 +66,7 @@ CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name ENGINE = engine AS SELECT ...
 
 Материализованное выражение. Такой столбец не может быть указан при INSERT, то есть, он всегда вычисляется.
 При INSERT без указания списка столбцов, такие столбцы не рассматриваются.
-Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём `SELECT *`, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
+Также этот столбец не подставляется при использовании звёздочки в запросе SELECT. Это необходимо, чтобы сохранить инвариант, что дамп, полученный путём `SELECT *`, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
 
 `ALIAS expr`
 
@@ -88,58 +87,64 @@ CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name ENGINE = engine AS SELECT ...
 
 ### Временные таблицы
 
-Во всех случаях, если указано `TEMPORARY`, то будет создана временная таблица. Временные таблицы обладают следующими особенностями:
+ClickHouse поддерживает временные таблицы со следующими характеристиками:
+
 - временные таблицы исчезают после завершения сессии; в том числе, при обрыве соединения;
-- временная таблица создаётся с движком Memory; все остальные движки таблиц не поддерживаются;
-- для временной таблицы нет возможности указать БД: она создаётся вне баз данных;
+- Временная таблица использует только модуль памяти.
+- Невозможно указать базу данных для временной таблицы. Временные таблицы создается вне баз данных.
 - если временная таблица имеет то же имя, что и некоторая другая, то, при упоминании в запросе без указания БД, будет использована временная таблица;
 - при распределённой обработке запроса, используемые в запросе временные таблицы, передаются на удалённые серверы.
 
+Чтобы создать временную таблицу, используйте следующий синтаксис:
+
+```sql
+CREATE TEMPORARY TABLE [IF NOT EXISTS] table_name [ON CLUSTER cluster]
+(
+    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
+    name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
+    ...
+)
+```
+
 В большинстве случаев, временные таблицы создаются не вручную, а при использовании внешних данных для запроса, или при распределённом `(GLOBAL) IN`. Подробнее см. соответствующие разделы
 
-Распределенные DDL запросы (секция ON CLUSTER)
-----------------------------------------------
+## Распределенные DDL запросы (секция ON CLUSTER)
 
 Запросы `CREATE`, `DROP`, `ALTER`, `RENAME` поддерживают возможность распределенного выполнения на кластере.
-Например, следующий запрос создает `Distributed`-таблицу `all_hits` на каждом хосте кластера `cluster`:
+Например, следующий запрос создает распределенную (Distributed) таблицу `all_hits` на каждом хосте в `cluster`:
 
-``` sql
+```sql
 CREATE TABLE IF NOT EXISTS all_hits ON CLUSTER cluster (p Date, i Int32) ENGINE = Distributed(cluster, default, hits)
 ```
 
-Для корректного выполнения таких запросов необходимо на каждом хосте иметь одинаковое определение кластера (для упрощения синхронизации конфигов можете использовать подстановки из ZooKeeper), также необходимо подключение к ZooKeeper серверам.
-Локальная версия запроса в конечном итоге будет выполнена на каждом хосте кластера, даже если некоторые хосты в данный момент не доступны, гарантируется упорядоченность выполнения запросов в рамках одного хоста.
-Пока не поддерживаются `ALTER`-запросы для реплицированных таблиц.
+Для корректного выполнения таких запросов необходимо на каждом хосте иметь одинаковое определение кластера (для упрощения синхронизации конфигов можете использовать подстановки из ZooKeeper). Также необходимо подключение к ZooKeeper серверам.
+Локальная версия запроса в конечном итоге будет выполнена на каждом хосте кластера, даже если некоторые хосты в данный момент не доступны. Гарантируется упорядоченность выполнения запросов в рамках одного хоста. Для реплицированных таблиц не поддерживаются запросы `ALTER`.
 
 ## CREATE VIEW
 
-``` sql
-CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]name [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ...
+```sql
+CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]table_name [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ...
 ```
 
 Создаёт представление. Представления бывают двух видов - обычные и материализованные (MATERIALIZED).
 
-При создании материализованного представления, нужно обязательно указать ENGINE - движок таблицы для хранения данных.
-
-Материализованное представление работает следующим образом: при вставлении данных в таблицу, указанную в SELECT, часть вставленных данных конвертируется запросом, а результат вставляется в представление.
-
 Обычные представления не хранят никаких данных, а всего лишь производят чтение из другой таблицы. То есть, обычное представление - не более чем сохранённый запрос. При чтении из представления, этот сохранённый запрос, используется в качестве подзапроса в секции FROM.
 
 Для примера, пусть вы создали представление:
 
-``` sql
+```sql
 CREATE VIEW view AS SELECT ...
 ```
 
 и написали запрос:
 
-``` sql
+```sql
 SELECT a, b, c FROM view
 ```
 
 Этот запрос полностью эквивалентен использованию подзапроса:
 
-``` sql
+```sql
 SELECT a, b, c FROM (SELECT ...)
 ```
 
@@ -159,5 +164,4 @@ SELECT a, b, c FROM (SELECT ...)
 
 Отсутствует отдельный запрос для удаления представлений. Чтобы удалить представление, следует использовать `DROP TABLE`.
 
-
 [Оригинальная статья](https://clickhouse.yandex/docs/ru/query_language/create/) <!--hide-->