mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-18 05:32:52 +00:00
b076933009
* Update create.md * DOCAPI-7400: RU translation. * DOCAPI-7400: Fixes. * Update docs/ru/query_language/create.md Co-Authored-By: Ivan Blinkov <github@blinkov.ru> * Update docs/ru/query_language/create.md Co-Authored-By: Ivan Blinkov <github@blinkov.ru> * DOCAPI-7400: Clarifications. * DOCAPI-7400: Link fix.
261 lines
24 KiB
Markdown
261 lines
24 KiB
Markdown
## CREATE DATABASE {#query_language-create-database}
|
||
|
||
Создает базу данных.
|
||
|
||
```sql
|
||
CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster] [ENGINE = engine(...)]
|
||
```
|
||
|
||
### Секции
|
||
|
||
- `IF NOT EXISTS`
|
||
|
||
Если база данных с именем `db_name` уже существует, то ClickHouse не создаёт базу данных и:
|
||
- Не генерирует исключение, если секция указана.
|
||
- Генерирует исключение, если секция не указана.
|
||
|
||
- `ON CLUSTER`
|
||
|
||
ClickHouse создаёт базу данных `db_name` на всех серверах указанного кластера.
|
||
|
||
- `ENGINE`
|
||
|
||
- [MySQL](../database_engines/mysql.md)
|
||
|
||
Позволяет получать данные с удаленного сервера MySQL.
|
||
|
||
По умолчанию ClickHouse использует собственный [движок баз данных](../database_engines/index.md).
|
||
|
||
## CREATE TABLE {#create-table-query}
|
||
|
||
Запрос `CREATE TABLE` может иметь несколько форм.
|
||
|
||
```sql
|
||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||
(
|
||
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [compression_codec] [TTL expr1],
|
||
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [compression_codec] [TTL expr2],
|
||
...
|
||
) ENGINE = engine
|
||
```
|
||
|
||
Создаёт таблицу с именем name в БД db или текущей БД, если db не указана, со структурой, указанной в скобках, и движком engine.
|
||
Структура таблицы представляет список описаний столбцов. Индексы, если поддерживаются движком, указываются в качестве параметров для движка таблицы.
|
||
|
||
Описание столбца, это `name type`, в простейшем случае. Пример: `RegionID UInt32`.
|
||
Также могут быть указаны выражения для значений по умолчанию - смотрите ниже.
|
||
|
||
```sql
|
||
CREATE TABLE [IF NOT EXISTS] [db.]table_name AS [db2.]name2 [ENGINE = engine]
|
||
```
|
||
|
||
Создаёт таблицу с такой же структурой, как другая таблица. Можно указать другой движок для таблицы. Если движок не указан, то будет выбран такой же движок, как у таблицы `db2.name2`.
|
||
|
||
``` sql
|
||
CREATE TABLE [IF NOT EXISTS] [db.]table_name AS table_fucntion()
|
||
```
|
||
|
||
Создаёт таблицу с такой же структурой и данными, как результат соотвествующей табличной функцией.
|
||
|
||
```sql
|
||
CREATE TABLE [IF NOT EXISTS] [db.]table_name ENGINE = engine AS SELECT ...
|
||
```
|
||
|
||
Создаёт таблицу со структурой, как результат запроса `SELECT`, с движком engine, и заполняет её данными из SELECT-а.
|
||
|
||
Во всех случаях, если указано `IF NOT EXISTS`, то запрос не будет возвращать ошибку, если таблица уже существует. В этом случае, запрос будет ничего не делать.
|
||
|
||
После секции `ENGINE` в запросе могут использоваться и другие секции в зависимости от движка. Подробную документацию по созданию таблиц смотрите в описаниях [движков таблиц](../operations/table_engines/index.md#table_engines).
|
||
|
||
### Значения по умолчанию {#create-default-values}
|
||
|
||
В описании столбца, может быть указано выражение для значения по умолчанию, одного из следующих видов:
|
||
`DEFAULT expr`, `MATERIALIZED expr`, `ALIAS expr`.
|
||
Пример: `URLDomain String DEFAULT domain(URL)`.
|
||
|
||
Если выражение для значения по умолчанию не указано, то в качестве значений по умолчанию будут использоваться нули для чисел, пустые строки для строк, пустые массивы для массивов, а также `0000-00-00` для дат и `0000-00-00 00:00:00` для дат с временем. NULL-ы не поддерживаются.
|
||
|
||
В случае, если указано выражение по умолчанию, то указание типа столбца не обязательно. При отсутствии явно указанного типа, будет использован тип выражения по умолчанию. Пример: `EventDate DEFAULT toDate(EventTime)` - для столбца EventDate будет использован тип Date.
|
||
|
||
При наличии явно указанного типа данных и выражения по умолчанию, это выражение будет приводиться к указанному типу с использованием функций приведения типа. Пример: `Hits UInt32 DEFAULT 0` - имеет такой же смысл, как `Hits UInt32 DEFAULT toUInt32(0)`.
|
||
|
||
В качестве выражения для умолчания, может быть указано произвольное выражение от констант и столбцов таблицы. При создании и изменении структуры таблицы, проверяется, что выражения не содержат циклов. При INSERT-е проверяется разрешимость выражений - что все столбцы, из которых их можно вычислить, переданы.
|
||
|
||
`DEFAULT expr`
|
||
|
||
Обычное значение по умолчанию. Если в запросе INSERT не указан соответствующий столбец, то он будет заполнен путём вычисления соответствующего выражения.
|
||
|
||
`MATERIALIZED expr`
|
||
|
||
Материализованное выражение. Такой столбец не может быть указан при INSERT, то есть, он всегда вычисляется.
|
||
При INSERT без указания списка столбцов, такие столбцы не рассматриваются.
|
||
Также этот столбец не подставляется при использовании звёздочки в запросе SELECT. Это необходимо, чтобы сохранить инвариант, что дамп, полученный путём `SELECT *`, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
|
||
|
||
`ALIAS expr`
|
||
|
||
Синоним. Такой столбец вообще не хранится в таблице.
|
||
Его значения не могут быть вставлены в таблицу, он не подставляется при использовании звёздочки в запросе SELECT.
|
||
Он может быть использован в SELECT-ах - в таком случае, во время разбора запроса, алиас раскрывается.
|
||
|
||
При добавлении новых столбцов с помощью запроса ALTER, старые данные для этих столбцов не записываются. Вместо этого, при чтении старых данных, для которых отсутствуют значения новых столбцов, выполняется вычисление выражений по умолчанию на лету. При этом, если выполнение выражения требует использования других столбцов, не указанных в запросе, то эти столбцы будут дополнительно прочитаны, но только для тех блоков данных, для которых это необходимо.
|
||
|
||
Если добавить в таблицу новый столбец, а через некоторое время изменить его выражение по умолчанию, то используемые значения для старых данных (для данных, где значения не хранились на диске) поменяются. Также заметим, что при выполнении фоновых слияний, данные для столбцов, отсутствующих в одном из сливаемых кусков, записываются в объединённый кусок.
|
||
|
||
Отсутствует возможность задать значения по умолчанию для элементов вложенных структур данных.
|
||
|
||
### Ограничения (constraints) {#constraints}
|
||
|
||
WARNING: Находится в экспериментальном режиме, поддержано в MergeTree (работоспособность на других типах движков таблиц не гарантируется).
|
||
|
||
Наряду с объявлением столбцов можно объявить ограчения на значения в столбцах таблицы:
|
||
|
||
```sql
|
||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||
(
|
||
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [compression_codec] [TTL expr1],
|
||
...
|
||
CONSTRAINT constraint_name_1 CHECK boolean_expr_1,
|
||
...
|
||
) ENGINE = engine
|
||
```
|
||
|
||
`boolean_expr_1` может быть любым булевым выражением, состоящим из операторов сравнения или функций. При наличии одного или нескольких ограничений в момент вставки данных выражения ограничений будут проверяться на истинность для каждой вставляемой строки данных. В случае, если в теле INSERT запроса придут некорректные данные — клиент получит исключение с описанием нарушенного ограничения.
|
||
|
||
Добавление большого числа ограничений может негативно повлиять на производительность `INSERT` запросов.
|
||
|
||
### Выражение для TTL
|
||
|
||
Определяет время хранения значений. Может быть указано только для таблиц семейства MergeTree. Подробнее смотрите в [TTL для столбцов и таблиц](../operations/table_engines/mergetree.md#table_engine-mergetree-ttl).
|
||
|
||
## Кодеки сжатия столбцов
|
||
|
||
Помимо сжатия данных по умолчанию, определяемого [конфигурационными параметрами сервера](../operations/server_settings/settings.md#compression), можно задать сжатие для каждого отдельного столбца.
|
||
|
||
Поддерживаемые алгоритмы сжатия:
|
||
|
||
- `NONE` — без сжатия.
|
||
- `LZ4` — [алгоритм сжатия данных](https://github.com/lz4/lz4) без потерь, используемый по умолчанию. Применяет быстрое сжатие LZ4.
|
||
- `LZ4HC[(level)]` — алгоритм сильного сжатия LZ4 HC с настраиваемым уровнем. Уровень по умолчанию — 9. Настройка `level <= 0` устанавливает уровень по умолчанию. Возможные уровни: [1, 12]. Рекомендуемый диапазон уровней: [4, 9].
|
||
- `ZSTD[(level)]` — [Алгоритм сжатия ZSTD](https://en.wikipedia.org/wiki/Zstandard) с настаиваемым уровнем `level`. Возможные уровни: [1, 22]. Значение по умолчанию — 1.
|
||
- `Delta(delta_bytes)` — способ сжатия, при котором исходные значения заменяются разностью двух соседних значений. Для хранение разностей используется до `delta_bytes` байтов, т.е. `delta_bytes` — это максимальный размер исходных значений. Возможные значения `delta_bytes` — 1, 2, 4, 8. Значение `delta_bytes` по умолчанию равно `sizeof(type)`, если вычисленный размер равен 1, 2, 4 или 8. Во всех остальных случаях — 1.
|
||
- `DoubleDelta` — Сжимает значения вплоть до размера в 1 бит благодаря сохранению разностей. Оптимальные уровни сжатия достигаются для монотонных последовательностей с постоянным шагом, например, временные ряды. Может использоваться с любым типом данных фиксированного размера. Реализует алгоритм, используемый в Gorilla TSDB, расширяя его для поддержки 64-битных типов. Использует 1 дополнительный бит для 32-байтовых значений: 5-битные префиксы вместо 4-битных префиксов. Подробнее смотрите в разделе "Compressing Time Stamps" в [Gorilla: A Fast, Scalable, In-Memory Time Series Database](http://www.vldb.org/pvldb/vol8/p1816-teller.pdf).
|
||
- `Gorilla` — Сжимает значения вплоть до размера в 1 bit. Эффективен при хранении рядов медленно изменяющихся чисел с плавающей запятой, потому, что лучшее сжатие достигается, когда соседние значения бинарно равны. Реализует алгоритм, используемый в Gorilla TSDB, расширяя его для поддержки 64-битных типов. Подробнее смотрите в разделе "Compressing Values" в [Gorilla: A Fast, Scalable, In-Memory Time Series Database](http://www.vldb.org/pvldb/vol8/p1816-teller.pdf).
|
||
|
||
Высокие уровни сжатия полезны для асимметричных сценариев, например, для таких, в которых требуется однократное сжатие и многократная распаковка. Более высокие уровни обеспечивают лучшее сжатие, но более высокое потребление вычислительных ресурсов.
|
||
|
||
!!! warning "Предупреждение"
|
||
Базу данных ClickHouse не получится распаковать с помощью внешних утилит типа `lz4`. Используйте специальную программу [clickhouse-compressor](https://github.com/yandex/ClickHouse/tree/master/dbms/programs/compressor).
|
||
|
||
Пример использования:
|
||
|
||
```sql
|
||
CREATE TABLE codec_example
|
||
(
|
||
dt Date CODEC(ZSTD), /* используется уровень сжатия по умолчанию */
|
||
ts DateTime CODEC(LZ4HC),
|
||
float_value Float32 CODEC(NONE),
|
||
double_value Float64 CODEC(LZ4HC(9))
|
||
)
|
||
ENGINE = MergeTree
|
||
PARTITION BY tuple()
|
||
ORDER BY dt
|
||
```
|
||
|
||
Кодеки можно комбинировать. Если для колонки указана своя последовательность кодеков, то общий табличный кодек не применяется (должен быть указан в последовательности принудительно, если нужен). В примере ниже - оптимизация для хранения timeseries метрик.
|
||
Как правило, значения одной и той же метрики `path` не сильно различаются между собой, и выгоднее использовать дельта-компрессию вместо записи всего числа:
|
||
|
||
```sql
|
||
CREATE TABLE timeseries_example
|
||
(
|
||
dt Date,
|
||
ts DateTime,
|
||
path String,
|
||
value Float32 CODEC(Delta, ZSTD)
|
||
)
|
||
ENGINE = MergeTree
|
||
PARTITION BY dt
|
||
ORDER BY (path, ts)
|
||
```
|
||
|
||
|
||
## Временные таблицы
|
||
|
||
ClickHouse поддерживает временные таблицы со следующими характеристиками:
|
||
|
||
- временные таблицы исчезают после завершения сессии; в том числе, при обрыве соединения;
|
||
- Временная таблица использует только модуль памяти.
|
||
- Невозможно указать базу данных для временной таблицы. Временные таблицы создается вне баз данных.
|
||
- если временная таблица имеет то же имя, что и некоторая другая, то, при упоминании в запросе без указания БД, будет использована временная таблица;
|
||
- при распределённой обработке запроса, используемые в запросе временные таблицы, передаются на удалённые серверы.
|
||
|
||
Чтобы создать временную таблицу, используйте следующий синтаксис:
|
||
|
||
```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)
|
||
|
||
Запросы `CREATE`, `DROP`, `ALTER`, `RENAME` поддерживают возможность распределенного выполнения на кластере.
|
||
Например, следующий запрос создает распределенную (Distributed) таблицу `all_hits` на каждом хосте в `cluster`:
|
||
|
||
```sql
|
||
CREATE TABLE IF NOT EXISTS all_hits ON CLUSTER cluster (p Date, i Int32) ENGINE = Distributed(cluster, default, hits)
|
||
```
|
||
|
||
Для корректного выполнения таких запросов необходимо на каждом хосте иметь одинаковое определение кластера (для упрощения синхронизации конфигов можете использовать подстановки из ZooKeeper). Также необходимо подключение к ZooKeeper серверам.
|
||
Локальная версия запроса в конечном итоге будет выполнена на каждом хосте кластера, даже если некоторые хосты в данный момент не доступны. Гарантируется упорядоченность выполнения запросов в рамках одного хоста. Для реплицированных таблиц не поддерживаются запросы `ALTER`.
|
||
|
||
## CREATE VIEW
|
||
|
||
```sql
|
||
CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]table_name [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ...
|
||
```
|
||
|
||
Создаёт представление. Представления бывают двух видов - обычные и материализованные (MATERIALIZED).
|
||
|
||
Обычные представления не хранят никаких данных, а всего лишь производят чтение из другой таблицы. То есть, обычное представление - не более чем сохранённый запрос. При чтении из представления, этот сохранённый запрос, используется в качестве подзапроса в секции FROM.
|
||
|
||
Для примера, пусть вы создали представление:
|
||
|
||
```sql
|
||
CREATE VIEW view AS SELECT ...
|
||
```
|
||
|
||
и написали запрос:
|
||
|
||
```sql
|
||
SELECT a, b, c FROM view
|
||
```
|
||
|
||
Этот запрос полностью эквивалентен использованию подзапроса:
|
||
|
||
```sql
|
||
SELECT a, b, c FROM (SELECT ...)
|
||
```
|
||
|
||
Материализованные (MATERIALIZED) представления хранят данные, преобразованные соответствующим запросом SELECT.
|
||
|
||
При создании материализованного представления, нужно обязательно указать ENGINE - движок таблицы для хранения данных.
|
||
|
||
Материализованное представление устроено следующим образом: при вставке данных в таблицу, указанную в SELECT-е, кусок вставляемых данных преобразуется этим запросом SELECT, и полученный результат вставляется в представление.
|
||
|
||
Если указано POPULATE, то при создании представления, в него будут вставлены имеющиеся данные таблицы, как если бы был сделан запрос `CREATE TABLE ... AS SELECT ...` . Иначе, представление будет содержать только данные, вставляемые в таблицу после создания представления. Не рекомендуется использовать POPULATE, так как вставляемые в таблицу данные во время создания представления, не попадут в него.
|
||
|
||
Запрос `SELECT` может содержать `DISTINCT`, `GROUP BY`, `ORDER BY`, `LIMIT`... Следует иметь ввиду, что соответствующие преобразования будут выполняться независимо, на каждый блок вставляемых данных. Например, при наличии `GROUP BY`, данные будут агрегироваться при вставке, но только в рамках одной пачки вставляемых данных. Далее, данные не будут доагрегированы. Исключение - использование ENGINE, производящего агрегацию данных самостоятельно, например, `SummingMergeTree`.
|
||
|
||
Недоработано выполнение запросов `ALTER` над материализованными представлениями, поэтому они могут быть неудобными для использования. Если материализованное представление использует конструкцию ``TO [db.]name``, то можно выполнить ``DETACH`` представления, ``ALTER`` для целевой таблицы и последующий ``ATTACH`` ранее отсоединенного (``DETACH``) представления.
|
||
|
||
Представления выглядят так же, как обычные таблицы. Например, они перечисляются в результате запроса `SHOW TABLES`.
|
||
|
||
Отсутствует отдельный запрос для удаления представлений. Чтобы удалить представление, следует использовать `DROP TABLE`.
|
||
|
||
[Оригинальная статья](https://clickhouse.yandex/docs/ru/query_language/create/) <!--hide-->
|