thevar1able/ClickHouse
1
0
Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2024-11-26 17:41:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updated text [#METR-20000].

Browse Source
This commit is contained in:
Alexey Milovidov 2016-06-01 11:19:20 +03:00
parent a2e1521223
commit 978810ca37
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/habrahabr/2/text.txt
View File

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