mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-20 00:30:49 +00:00
Updating documentation [#METR-21710].
This commit is contained in:
Alexey Milovidov
parent
21b0167125
commit
6188c018e5
@ -389,7 +389,7 @@ inline void writeProbablyBackQuotedString(const String & s, WriteBuffer & buf)
|
||||
/** Выводит строку в для формата CSV.
|
||||
* Правила:
|
||||
* - строка выводится в кавычках;
|
||||
* - кавычка внутри строки выводится как двойная кавычка.
|
||||
* - кавычка внутри строки выводится как две кавычки подряд.
|
||||
*/
|
||||
template <char quote = '"'>
|
||||
void writeCSVString(const char * begin, const char * end, WriteBuffer & buf)
|
||||
|
||||
@ -36,13 +36,14 @@ body
|
||||
h1
|
||||
{
|
||||
font-family: 'Yandex Sans Display Web', Arial, sans-serif;
|
||||
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
h2
|
||||
{
|
||||
font-family: 'Yandex Sans Display Web', Arial, sans-serif;
|
||||
margin-top: 30px;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
|
||||
h3
|
||||
@ -53,7 +54,6 @@ h3
|
||||
p
|
||||
{
|
||||
line-height: 20px;
|
||||
|
||||
white-space: pre-wrap;
|
||||
}
|
||||
|
||||
@ -180,8 +180,8 @@ a:hover
|
||||
.head-anchor
|
||||
{
|
||||
float: right;
|
||||
|
||||
color: #aaa;
|
||||
margin-top: 10px;
|
||||
}
|
||||
|
||||
.head-anchor:hover
|
||||
|
||||
@ -101,7 +101,6 @@ ClickHouse - столбцовая СУБД для OLAP (Columnar DBMS).
|
||||
|
||||
В обычной, "строковой" СУБД, данные хранятся в таком порядке:
|
||||
|
||||
|
||||
%%
|
||||
5123456789123456789 1 Евробаскет - Греция - Босния и Герцеговина - example.com 1 2011-09-01 01:03:02 6274717 1294101174 11409 612345678912345678 0 33 6 http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html 0 1366 768 32 10 3183 0 0 13 0\0 1 1 0 0 2011142 -1 0 0 01321 613 660 2011-09-01 08:01:17 0 0 0 0 utf-8 1466 0 0 0 5678901234567890123 277789954 0 0 0 0 0
|
||||
5234985259563631958 0 Консалтинг, налогообложение, бухгалтерский учет, право 1 2011-09-01 01:03:02 6320881 2111222333 213 6458937489576391093 0 3 2 http://www.example.ru/ 0 800 600 16 10 2 153.1 0 0 10 63 1 1 0 0 2111678 000 0 588 368 240 2011-09-01 01:03:17 4 0 60310 0 windows-1251 1466 0 000 778899001 0 0 0 0 0
|
||||
@ -126,7 +125,6 @@ ClickHouse - столбцовая СУБД для OLAP (Columnar DBMS).
|
||||
То есть, значения из разных столбцов хранятся отдельно, а данные одного столбца - вместе.
|
||||
Примеры столбцовых СУБД: Vertica, Paraccel (Actian Matrix) (Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise) (Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Metamarkets Druid, kdb+ и т. п.
|
||||
|
||||
|
||||
Разный порядок хранения данных лучше подходит для разных сценариев работы.
|
||||
Сценарий работы с данными - это то, какие производятся запросы, как часто и в каком соотношении; сколько читается данных на запросы каждого вида - строк, столбцов, байт; как соотносятся чтения и обновления данных; какой рабочий размер данных и насколько локально он используется; используются ли транзакции и с какой изолированностью; какие требования к дублированию данных и логической целостности; требования к задержкам на выполнение и пропускной способности запросов каждого вида и т. п.
|
||||
|
||||
@ -2414,27 +2412,6 @@ calcs - имя кластера в конфигурационном файле
|
||||
|
||||
Кластеры задаются следующим образом:
|
||||
|
||||
%%
|
||||
<!-- Группы удалённых серверов, которые могут быть подключены в таблицах типа Distributed. -->
|
||||
<remote_servers>
|
||||
<test>
|
||||
<node>
|
||||
<host>example01-01-1</host>
|
||||
<port>9000</port>
|
||||
<weight>1</weight> <!-- Не обязательно. Вес шарда при записи данных. По умолчанию, 1.-->
|
||||
</node>
|
||||
<node>
|
||||
<host>example01-01-2</host>
|
||||
<port>9001</port>
|
||||
</node>
|
||||
</test>
|
||||
</remote_servers>
|
||||
%%
|
||||
|
||||
Здесь задан кластер с именем test, состоящий из двух серверов (шардов).
|
||||
|
||||
Также возможно задать кластер, состоящий из шардов и реплик:
|
||||
|
||||
%%
|
||||
<remote_servers>
|
||||
<logs>
|
||||
@ -2490,7 +2467,7 @@ calcs - имя кластера в конфигурационном файле
|
||||
|
||||
Для просмотра имеющихся кластеров, вы можете использовать системную таблицу system.clusters.
|
||||
|
||||
Движок Distributed позволяет работать с кластером, как с локальным сервером. При этом, кластер является неэластичным: вы должны прописать его конфигурацию в конфигурационный файл сервера (лучше всех серверов кластера), система сама не переносит данные между серверами.
|
||||
Движок Distributed позволяет работать с кластером, как с локальным сервером. При этом, кластер является неэластичным: вы должны прописать его конфигурацию в конфигурационный файл сервера (лучше всех серверов кластера).
|
||||
|
||||
Не поддерживаются Distributed таблицы, смотрящие на другие Distributed таблицы (за исключением случаев, когда у Distributed таблицы всего один шард). Вместо этого, сделайте так, чтобы Distributed таблица смотрела на "конечные" таблицы.
|
||||
|
||||
@ -2519,7 +2496,7 @@ calcs - имя кластера в конфигурационном файле
|
||||
|
||||
Простой остаток от деления является довольно ограниченным решением для шардирования и подходит не для всех случаев. Он подходит для среднего и большого объёма данных (десятки серверов), но не для очень больших объёмов данных (сотни серверов и больше). В последнем случае, лучше использовать схему шардирования, продиктованную требованиями предметной области, и не использовать возможность записи в Distributed таблицы.
|
||||
|
||||
Ещё раз отметим, что Distributed таблица не умеет автоматически перешардировать данные. Во многих случаях можно обойтись без этого. Запросы SELECT отправляются на все шарды, и работают независимо от того, каким образом данные распределены по шардам (они могут быть распределены полностью случайно). При добавлении нового шарда, можно не переносить на него старые данные, а записывать новые данные с большим весом - данные будут распределены слегка неравномерно, но запросы будут работать корректно и достаточно эффективно.
|
||||
В случае использования реплицированных таблиц, есть возможность перешардировать данные - смотрите раздел "Перешардирование". Но во многих случаях лучше обойтись без этого. Запросы SELECT отправляются на все шарды, и работают независимо от того, каким образом данные распределены по шардам (они могут быть распределены полностью случайно). При добавлении нового шарда, можно не переносить на него старые данные, а записывать новые данные с большим весом - данные будут распределены слегка неравномерно, но запросы будут работать корректно и достаточно эффективно.
|
||||
|
||||
Беспокоиться о схеме шардирования имеет смысл в следующих случаях:
|
||||
- используются запросы, требующие соединение данных (IN, JOIN) по определённому ключу - тогда если данные шардированы по этому ключу, то можно использовать локальные IN, JOIN вместо GLOBAL IN, GLOBAL JOIN, что кардинально более эффективно.
|
||||
@ -3016,6 +2993,85 @@ min_bytes, max_bytes - условие на количество байт в бу
|
||||
Если вы продолбали ZooKeeper, то вы можете сохранить данные, переместив их в нереплицируемую таблицу, как описано в пункте выше.
|
||||
|
||||
|
||||
==Перешардирование==
|
||||
|
||||
%%ALTER TABLE t RESHARD [COPY] [PARTITION partition] TO описание кластера USING ключ шардирования%%
|
||||
|
||||
Запрос работает только для Replicated-таблиц и для Distributed-таблиц, смотрящих на Replicated-таблицы.
|
||||
|
||||
При выполнении, запрос сначала проверяет корректность запроса, наличие свободного места на серверах и кладёт в ZooKeeper по некоторому пути задачу, которую нужно сделать. Дальнейшее выполнение делается асинхронно.
|
||||
|
||||
Для того, чтобы использовать перешардирование, в конфигурационном файле каждого сервера должен быть указан путь в ZooKeeper к очереди задач:
|
||||
|
||||
%%
|
||||
<resharding>
|
||||
<task_queue_path>/clickhouse/task_queue</task_queue_path>
|
||||
</resharding>
|
||||
%%
|
||||
|
||||
При выполнении запроса %%ALTER TABLE t RESHARD%%, узел в ZooKeeper создаётся, если его не было.
|
||||
|
||||
Описание кластера - список шардов с весами, на которые нужно перераспределить указанные данные.
|
||||
Шард указывается в виде адреса таблицы в ZooKeeper. Например, %%/clickhouse/tables/01-03/hits%%
|
||||
Относительный вес шарда (не обязательно, по-умолчнию, 1) может быть указан после ключевого слова %%WEIGHT%%.
|
||||
Пример:
|
||||
|
||||
%%
|
||||
ALTER TABLE merge.hits
|
||||
RESHARD PARTITION 201501
|
||||
TO
|
||||
/clickhouse/tables/01-01/hits WEIGHT 1,
|
||||
/clickhouse/tables/01-02/hits WEIGHT 2,
|
||||
/clickhouse/tables/01-03/hits WEIGHT 1,
|
||||
/clickhouse/tables/01-04/hits WEIGHT 1
|
||||
USING UserID
|
||||
%%
|
||||
|
||||
Ключ шардирования (в примере: %%UserID%%) имеет такой же смысл, как для Distributed таблиц. Вы можете указать %%rand()%% в качестве ключа шардирования для случайного перераспределения данных.
|
||||
|
||||
При выполнении запроса, сразу проверяется:
|
||||
- совпадение структур таблиц локально и на всех указанных шардах.
|
||||
- наличие на локальном сервере свободного места в количестве, равном размеру партиции в байтах, с запасом в 10%.
|
||||
- наличие на всех репликах всех указанных шардов, кроме являющейся локальной, если такая есть, свободного места в количестве равном размеру партиции, домноженном на отношение веса шарда к суммарному весу, с запасом в 10%.
|
||||
|
||||
Далее, асинхронное выполнение задачи состоит из следующих шагов:
|
||||
|
||||
1. Нарезка партиции на кусочки на локальном сервере.
|
||||
Для этого делается слияние всех кусков, входящих в партицию и, одновременно, разбиение их на несколько, согласно ключу шардирования.
|
||||
Результат складывается в директорию /reshard в директории с данными таблицы.
|
||||
Исходные куски никак не модифицируются и весь процесс не влияет на рабочие данные таблицы.
|
||||
|
||||
2. Копирование всех кусков на удалённые серверы (на каждую реплику соответствующих шардов).
|
||||
|
||||
3. Выполнение запроса %%ALTER TABLE t DROP PARTITION%% на локальном сервере, выполнение запросов %%ALTER TABLE t ATTACH PARTITION%% на всех шардах.
|
||||
Замечание: это делается неатомарно. Есть момент времени, в течение которого пользователь может увидеть отсутствие данных партиции.
|
||||
|
||||
В случае указания в запросе слова %%COPY%%, исходные данные не удаляются. Это подходит для копирования данных с одного кластера на другой с одновременным изменением схемы шардирования.
|
||||
|
||||
4. Удаление временных данных с локального сервера.
|
||||
|
||||
При наличии нескольких запросов на перешардирование, соответствующие задачи будут делаться последовательно.
|
||||
|
||||
Указанный выше запрос предназначен для того, чтобы перешардировать одну партицию.
|
||||
Если не указать партицию в запросе, то в задачи на перешардирование будут добавлены все партиции. Пример:
|
||||
|
||||
%%
|
||||
ALTER TABLE merge.hits
|
||||
RESHARD
|
||||
TO ...
|
||||
%%
|
||||
|
||||
В этом случае, последовательно вставляются задачи на перешардирование каждой партиции.
|
||||
|
||||
В случае перешардирования Distributed-таблицы, производится перешардирование каждого шарда (соответствующий запрос отправляется на каждый шард).
|
||||
|
||||
Вы можете перешардировать Distributed-таблицу как в саму себя, так и в другую таблицу.
|
||||
|
||||
Перешардирование предназначено для перераспределения "старых" данных: в случае, если во время работы, перешардируемая партиция была изменена, то перешардирование этой партиции отменяется.
|
||||
|
||||
На каждом сервере, перешардирование осуществляется в один поток, чтобы в процессе длительных операций перешардирования, не мешать другим задачам.
|
||||
|
||||
По состоянию на июнь 2016, перешардирование находится в состоянии "бета": тестировалось лишь на небольшом объёме данных - до 5 ТБ.
|
||||
|
||||
</div>
|
||||
<div class="island">
|
||||
@ -3581,6 +3637,22 @@ world%%
|
||||
Формат подходит только для записи, но не для чтения.
|
||||
|
||||
|
||||
==CSV==
|
||||
|
||||
Формат comma separated values (<a href="https://tools.ietf.org/html/rfc4180">RFC</a>).
|
||||
|
||||
При записи, строки выводятся в двойных кавычках. Двойная кавычка внутри строки выводится как две двойные кавычки подряд. Других правил экранирования нет. Даты и даты-с-временем выводятся в двойных кавычках. Числа выводятся без кавычек. Значения разделяются запятыми. Строки разделяются unix переводом строки (LF). Массивы сериализуются в CSV следующим образом: сначла массив сериализуется в строку, как в формате TabSeparated, а затем полученная строка выводится в CSV в двойных кавычках. Кортежи в формате CSV сериализуются, как отдельные столбцы (то есть, теряется их вложенность в кортеж).
|
||||
|
||||
При чтении, все значения могут парситься как в кавычках, так и без кавычек. Поддерживаются как двойные так и одинарные кавычки. В том числе, строки могут быть расположены без кавычек - тогда они парсятся до запятой или перевода строки (CR или LF). В нарушение RFC, в случае парсинга строк не в кавычках, начальные и конечные пробелы и табы игнорируются. В качестве перевода строки, поддерживаются как Unix (LF), так и Windows (CR LF) и Mac OS Classic (LF CR) варианты.
|
||||
|
||||
Формат CSV поддерживает вывод totals и extremes аналогично TabSeparated.
|
||||
|
||||
|
||||
==CSVWithNames==
|
||||
|
||||
Выводит также заголовок, аналогично TabSeparatedWithNames.
|
||||
|
||||
|
||||
==RowBinary==
|
||||
|
||||
Пишет данные по строкам, в бинарном виде. Строки и значения уложены подряд, без разделителей.
|
||||
@ -3796,6 +3868,13 @@ JSON совместим с JavaScript. Для этого, дополнитель
|
||||
%%
|
||||
|
||||
|
||||
==JSONEachRow==
|
||||
|
||||
Выводит данные в виде отдельных JSON объектов для каждой строки.
|
||||
|
||||
|
||||
|
||||
|
||||
==Null==
|
||||
|
||||
Ничего не выводит. При этом, запрос обрабатывается, а при использовании клиента командной строки, данные ещё и передаются на клиент. Используется для тестов, в том числе, тестов производительности.
|
||||
@ -3866,6 +3945,33 @@ JSON совместим с JavaScript. Для этого, дополнитель
|
||||
То есть, при работе с датой в виде текста (например, при сохранении текстовых дампов), следует иметь ввиду о проблемах с неоднозначностью во время перевода стрелок назад, и о проблемах с соответствием данных, при смене часового пояса.
|
||||
|
||||
|
||||
==Enum==
|
||||
|
||||
Enum8 или Enum16. Представляет собой конечное множество строковых значений, сохраняемых более эффективно, чем это делает тип данных %%String%%. Пример:
|
||||
|
||||
%%Enum8('hello' = 1, 'world' = 2)%%
|
||||
- тип данных с двумя возможными значениями - 'hello' и 'world'.
|
||||
|
||||
Для каждого из значений прописывается число в диапазоне -128..127 для %%Enum8%% или в диапазоне -32768..32767 для %%Enum16%%. Все строки должны быть разными, числа - тоже. Разрешена пустая строка. При указании такого типа (в определении таблицы), числа могут идти не подряд и в произвольном порядке. При этом, порядок не имеет значения.
|
||||
|
||||
В оперативке столбец такого типа представлен так же, как %%Int8%% или %%Int16%% соответствующими числовыми значениями.
|
||||
При чтении в текстовом виде, парсит значение как строку и ищет соответствующую строку из множества значений Enum-а. Если не находит - кидается исключение.
|
||||
При записи в текстовом виде, записывает значение как соответствующую строку. Если в данных столбца есть мусор - числа не из допустимого множества, то кидается исключение. При чтении и записи в бинарном виде, оно осуществляется так же, как для типов данных %%Int8%%, %%Int16%%.
|
||||
Неявное значение по-умолчанию - это значение с минимальным номером.
|
||||
|
||||
При %%ORDER BY%%, %%GROUP BY%%, %%IN%%, %%DISTINCT%% и т. п., Enum-ы ведут себя так же, как соответствующие числа. Например, при %%ORDER BY%% они сортируются по числовым значениям. Функции сравнения на равенство и сравнения на отношение порядка двух Enum-ов работают с Enum-ами так же, как с числами.
|
||||
|
||||
Сравнивать Enum с числом нельзя. Можно сравнивать Enum с константной строкой - при этом, для строки ищется соответствующее значение Enum-а; если не находится - кидается исключение. Поддерживается оператор IN, где слева стоит Enum, а справа - множество строк. В этом случае, строки рассматриваются как значения соответствующего Enum-а.
|
||||
|
||||
Большинство операций с числами и со строками не имеет смысла и не работают для Enum-ов: например, к Enum-у нельзя прибавить число.
|
||||
Для Enum-а естественным образом определяется функция %%toString%%, которая возвращает его строковое значение.
|
||||
|
||||
Также для Enum-а определяются функции %%to<i>T</i>%%, где <i>T</i> - числовой тип. При совпадении T с типом столбца Enum-а, преобразование работает бесплатно.
|
||||
При ALTER, есть возможность бесплатно изменить тип Enum-а, если меняется только множество значений. При этом, можно добавлять новые значения; можно удалять старые значения (это безопасно только если они ни разу не использовались, так как это не проверяется). В качестве "защиты от дурака", нельзя менять числовые значения у имеющихся строк - в этом случае, кидается исключение.
|
||||
|
||||
При ALTER, есть возможность поменять Enum8 на Enum16 и обратно - так же, как можно поменять Int8 на Int16.
|
||||
|
||||
|
||||
==Array(T)==
|
||||
|
||||
Массив из элементов типа T. Типом T может быть любой тип, в том числе, массив.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user