Тестовый кластер ClickHouse на lxc.
TODO
- развернуть
- потестить шардинг
- потестить репликацию
Создал шаблон для клонирования:
- ch-templ -- ubuntu xenial 16.04 с установленным clickhouse-server-common, clickhouse-server-base, clickhouse-client -- тут нет файла для тестовой БД -- его можно брать так
cp /var/lib/lxc/ch01/rootfs/opt/ontime.csv.xz /var/lib/lxc/my777/rootfs/opt/
где my777 -- нужный сервер
Создал следующие сервера:
ch01-01-1 ch01-01-2 ch01-02-1 ch01-02-2 ch01-03-1 ch01-03-2
for i in 1 2 3 ; do for j in 1 2 ; do lxc-start -n ch01-0$i-$j ; done ; done for i in 1 2 3 ; do for j in 1 2 ; do lxc-stop -n ch01-0$i-$j ; done ; done
запускаем и останавливаем все ноды
clickhouse_remote_servers -- прописываем в /etc/metrika.xml
после можно
select * from system.clusters;
Место на диске до загрузки данных: 18G /var/lib/lxc/ch01 737M /var/lib/lxc/ch01-01-1 737M /var/lib/lxc/ch01-01-2 737M /var/lib/lxc/ch01-02-1 737M /var/lib/lxc/ch01-02-2 736M /var/lib/lxc/ch01-03-1 736M /var/lib/lxc/ch01-03-2
в серверных конфигах нужно раскомментить <listen_host>::</listen_host> чтоб не было проблем с сетью
таблицу, например ontime_local -- нужно руками создать на всех хостах таблицу же объединенную ontime_all -- на том откуда запросы но можно на всех хостах
при этом на репликах основных серверов таблицы заполнились как на праймари т.е. на ch01-03-1 и ch01-03-2 -- одинаково
записать данные в шардированную таблицу получилось только именно таким спрособом, который описан в быстром старте: сначала делаем полную таблицу на одном из серверов -- после в распределенную
INSERT INTO ontime_all SELECT * FROM ontime;
в моем случае с lxc при загрузки из сжатого файла праямо и даже из csv -- загрузка падала из-за ошибок в сетевом взаимодействии при большой нагрузке общей на комп.
h2. Без Zookeeper -- тест как работает
Данные при загрузке в распределенную таблицу -- залились на шарды равномерно примерно. Данные на репликах залились тоже и соответствуют данным на мастерах.
При схеме с тремя шардами и репликой каждого шарда, запросы к распределенной таблице работают при наличии мастера ИЛИ реплики из каждого шарда. Это без использования ZooKeeper -- только то, что есть в metrika.xml. Если запрос делается с мастера ???
При запросе к распределенной таблице с реплики -- требуется чтоб все мастера были доступны для этой таблицы. Но после выключения мастера и реплики -- вообще не работает, а затем достаточно включить что-то одно, хватает теперь уже и реплики только. Те можно сделать, что будут работать только одни реплики. (Хотя изначильно этого не получилось).
Наверно получается так при первом запросе все равно где по распределенной таблице -- все хотят, чтоб были доступны все мастера для нее. А после можно уже вместо мастеров оставлять реплики -- будет работать.
h2. Вместе с Zookeeper
Устанавливаем на 3 сервера zk01-[1-3] Делаем 1 шaблон с явой и zk отдельностосящий. Шаблон размножаем.
Раскомментил для сетевой конфигурации там где сам сервер нужно писать 0.0.0.0 и записал в myid циферки.
interserver_http_host -- пишут нужно выставить, чтоб без сюрпризов
autopurge -- нужно чтоб работало -- обратить внимание на этот параметр.
Нужно думать о ключе шардирования
В простейшем случае ключом шардирования может быть случайное число, т. е. результат вызова функции rand(). Однако в качестве ключа шардирования рекомендуется брать значение хеш-функции от поля в таблице, которое позволит, с одной стороны, локализовать небольшие наборы данных на одном шарде, а с другой — обеспечит достаточно ровное распределение таких наборов по разным шардам в кластере. Например, идентификатор сессии (sess_id) пользователя позволит локализовать показы страниц одному пользователю на одном шарде, при этом сессии разных пользователей будут распределены равномерно по всем шардам в кластере (при условии, что значения поля sess_id будут иметь хорошее распределение). Ключ шардирования может быть также нечисловым или составным. В этом случае можно использовать встроенную хеширующую функцию cityHash64. Более сложный способ заключается в том, чтобы вне ClickHouse вычислять нужный шард и выполнять запись напрямую в шардированную таблицу. Сложность здесь обусловлена тем, что нужно знать набор доступных узлов-шардов. Однако в этом случае запись становится более эффективной, и механизм шардирования (определения нужного шарда) может быть более гибким.
https://groups.google.com/forum/#!topic/clickhouse/0I7ohN8k5Ns -- интересно