Updated text [#METR-20000].

This commit is contained in:
Alexey Milovidov 2016-06-01 11:19:20 +03:00
parent a2e1521223
commit 978810ca37

View File

@ -105,6 +105,8 @@ clickhouse-client --query='INSERT INTO table FORMAT TabSeparated' < data.tsv
В данном примере, некоторая неоптимальность состоит в том, что в таблице используется тип данных String тогда, когда подошёл бы Enum или числовой тип. Если множество разных значений строк заведомо небольшое (пример: название операционной системы, производитель мобильного телефона), то для максимальной производительности, мы рекомендуем использовать Enum-ы или числа. Если множество строк потенциально неограничено (пример: поисковый запрос, URL), то используйте тип данных String. В данном примере, некоторая неоптимальность состоит в том, что в таблице используется тип данных String тогда, когда подошёл бы Enum или числовой тип. Если множество разных значений строк заведомо небольшое (пример: название операционной системы, производитель мобильного телефона), то для максимальной производительности, мы рекомендуем использовать Enum-ы или числа. Если множество строк потенциально неограничено (пример: поисковый запрос, URL), то используйте тип данных String.
Во вторых отметим, что в данном примере, структура таблицы содержит избыточные столбцы Year, Quarter, Month, DayofMonth, DayOfWeek, тогда как достаточно одного FlightDate. Скорее всего, это сделано для эффективной работы других СУБД, в которых функции для работы с датой и временем, могут быть неэффективными. В случае ClickHouse, в этом нет необходимости, так как соответствующие функции хорошо оптимизированы.
Для примера, посчитаем... Для примера, посчитаем...
Теперь рассмотрим, как установить ClickHouse на кластер из нескольких серверов. Теперь рассмотрим, как установить ClickHouse на кластер из нескольких серверов.
@ -119,7 +121,7 @@ Distributed таблица представляет собой "вид" на к
Отметим, что для перешардирования больших таблиц, такой способ не подходит, и вместо этого следует воспользоваться встроенной функциональностью перешардирования. Отметим, что для перешардирования больших таблиц, такой способ не подходит, и вместо этого следует воспользоваться встроенной функциональностью перешардирования.
В данном примере, мы использовали кластер из трёх шардов, каждый шард которого состоит из одной реплики. Для реальных задач, в целях отказоустойчивости, каждый шард должен состоять из двух или трёх реплик, расположенных в разных датацентрах. (В общем случае, поддерживается произвольное количество реплик). В данном примере, мы использовали кластер из трёх шардов, каждый шард которого состоит из одной реплики. Для реальных задач, в целях отказоустойчивости, каждый шард должен состоять из двух или трёх реплик, расположенных в разных датацентрах. (Поддерживается произвольное количество реплик).
Для примера, создадим кластер, который будет состоять из одного шарда, представленного тремя репликами. Для примера, создадим кластер, который будет состоять из одного шарда, представленного тремя репликами.
@ -131,3 +133,7 @@ Distributed таблица представляет собой "вид" на к
Также пропишем подстановки, идентифицирующие шард и реплику - они будут использоваться при создании таблицы. Также пропишем подстановки, идентифицирующие шард и реплику - они будут использоваться при создании таблицы.
При создании реплицированной таблицы, если других реплик ещё нет, то создаётся первая реплика, а если есть - создаётся новая реплика и клонирует данные существующих реплик. Вы можете сразу создать все таблицы-реплики и затем загрузить в них данные, либо сначала создать одну реплику, а затем добавить другие, уже после загрузки или во время загрузки данных.
Репликация работает в режиме multi-master. Вы можете вставлять данные на любую реплику, и данные автоматически разъезжаются по всем репликам. При этом, репликация асинхронная, и в заданный момент времени, реплики могут содержать не все недавно записанные данные. Для записи данных, достаточно доступности хотя бы одной реплики. Остальные реплики будут скачивать новые данные как только станут активными.