clickhouse-client -q "..." | clickhouse-compressor > data.compressed

спасибо)

Скажите сервера 1 CPU и 2gb RAM это очень плохо для запросов на select sum в таблицы с 100 млн записей каждую минуту и около 1000-2000 вставок в секунду ? прочитал что RAM должно быть столько же сколько ГБ данных (я так понял данные в памяти висят). кто что скажет по этому поводу?

Привет. Мы выложили в OpenSource Graphouse - компонент, который позволяет использовать ClickHouse как хранилище метрик для Графита. Graphouse содержит: 1. TCP cервер для приема метрик 2. HTTP API для поиска метрик и получения данных (с питонячим модулем для graphite-web) 3. HTTP API для управления деревом метрик. Лежит тут - https://github.com/yandex/graphouse Доступны deb пакеты. Документацию постепенно дополняем. Будем рады любым замечаниям и предложениям.

Скажите сервера 1 CPU и 2gb RAM это очень плохо для запросов на select sum в таблицы с 100 млн записей каждую минуту и около 1000-2000 вставок в секунду ? прочитал что RAM должно быть столько же сколько ГБ данных (я так понял данные в памяти висят). кто что скажет по этому поводу?

Зависит от кардинальности выражения группировки, сама аггрегатная функция суммы требует O(1) памяти

Зависит от кардинальности выражения группировки, сама аггрегатная функция суммы требует O(1) памяти

а может подскажите как распределить нагрузку. я вот создам наверное еще один instance 1 cpu 2gb ram и будет два сервера между которыми нагрузка будет распределятся. я так понимаю надо всего 3 сервера - принимающий Distributed и два с mergetree с одинаковыми данными и репликацией с первого узла с mergetree на второй узел mergetree ?

Привет @AndreevDm ! Круто! А не подскажешь, чем вы проверки делаете?

Какие именно проверки?

Alertmanager какой..

...Что шлет email когда все плохо)

У нас всё своё

А вы на Graphouse остановитесь или и ее выложите? ))

Ничего такого выкладывать не планируем

У нас в тестинге достаточно часто вырубаются машины по питанию и появилась мысль перманентно (например, в /etc/default/clickhouse) выставлять флажок flags/force_restore_data, чтобы в случае падения машина без вмешательства эксплуатации удаляла из ZK информацию о потеряных кусках Но возникли также разумные опасения, к чему может привезти подобная "оптимизация", @milovidov_an? Разумно ли так делать?

Да, в случае частых выключений это Ок. Ещё можно поднять лимиты, на которые он ругается при запуске. Они задаются в секции <merge_tree>, варианты см. в MergeTreeSettings.h

загрузил меньшим файлом в меньше чем 1 гб (5 млн строк) - файл загрузился из сообщения tcmalloc: large alloc 1073750016 bytes == 0x486ec000 @ - следует что большой размер7 т.к. они реально больше 1гб. но где это ограничение задается?

Если у вас есть возможность выложить минимальный вариант файла, на котором проявляется проблема, то я смогу это изучить.

Привет. Мы выложили в OpenSource Graphouse - компонент, который позволяет использовать ClickHouse как хранилище метрик для Графита. Graphouse содержит: 1. TCP cервер для приема метрик 2. HTTP API для поиска метрик и получения данных (с питонячим модулем для graphite-web) 3. HTTP API для управления деревом метрик. Лежит тут - https://github.com/yandex/graphouse Доступны deb пакеты. Документацию постепенно дополняем. Будем рады любым замечаниям и предложениям.

Ну это же нереально круто!

Если у вас есть возможность выложить минимальный вариант файла, на котором проявляется проблема, то я смогу это изучить.

порезал файлик на чанки по 10 млн и файлик загрузился. может база весит в памяти оперативной? то есть загрузил часть данных сделал пару запросов. а на следующий день уже не могу загрузить такой же объем данных. возможно либо результаты запросов остались в памяти либо сама база как-то в памяти висит?

Скажите сервера 1 CPU и 2gb RAM это очень плохо для запросов на select sum в таблицы с 100 млн записей каждую минуту и около 1000-2000 вставок в секунду ? прочитал что RAM должно быть столько же сколько ГБ данных (я так понял данные в памяти висят). кто что скажет по этому поводу?

Данные не обязаны помещаться в память. (Для примера, на наших серверах обычно 128 GB оперативки и 10..60 TB сжатых данных.) Но 2 GB - это очень мало. Для хоть сколько-нибудь широких таблиц и запросов с промежуточными данными большой кардинальности будут OOM-ы.

а может подскажите как распределить нагрузку. я вот создам наверное еще один instance 1 cpu 2gb ram и будет два сервера между которыми нагрузка будет распределятся. я так понимаю надо всего 3 сервера - принимающий Distributed и два с mergetree с одинаковыми данными и репликацией с первого узла с mergetree на второй узел mergetree ?

Вы можете использовать однородную схему кластера: все серверы могут принимать запросы и выполнять их распределённо. То есть, делать отдельный "принимающий" сервер не обязательно - можно на всех серверах создать одинаковые Distributed таблицы.

порезал файлик на чанки по 10 млн и файлик загрузился. может база весит в памяти оперативной? то есть загрузил часть данных сделал пару запросов. а на следующий день уже не могу загрузить такой же объем данных. возможно либо результаты запросов остались в памяти либо сама база как-то в памяти висит?

Да, так работают аллокаторы. Какая-то часть памяти не отдаётся системе, а используется для последующих аллокаций.

Привет. Мы выложили в OpenSource Graphouse - компонент, который позволяет использовать ClickHouse как хранилище метрик для Графита. Graphouse содержит: 1. TCP cервер для приема метрик 2. HTTP API для поиска метрик и получения данных (с питонячим модулем для graphite-web) 3. HTTP API для управления деревом метрик. Лежит тут - https://github.com/yandex/graphouse Доступны deb пакеты. Документацию постепенно дополняем. Будем рады любым замечаниям и предложениям.

Поздравляю! Насколько я помню, есть намерение выложить ещё две полезные штуки :)

Данные не обязаны помещаться в память. (Для примера, на наших серверах обычно 128 GB оперативки и 10..60 TB сжатых данных.) Но 2 GB - это очень мало. Для хоть сколько-нибудь широких таблиц и запросов с промежуточными данными большой кардинальности будут OOM-ы.

1 cpu 2 gb ram я так понял не потянут кх верно? раньше был 2 cpu 4 gb было норм, сейчас уменьшил instance и получил жесткую нагрузку во время выгрузки данных из кх для бэкапа. load average подскакивает до 2.5

А зачем такие слабые машины? Лучше меньше машин, по посерьёзнее.

А зачем такие слабые машины? Лучше меньше машин, по посерьёзнее.

возможно. решили просто попробовать вытянет ли. и он тянет нормально, но когда начинает выгружать данные из 100 млн таблиц с компрессией то average растте критически. думал сделать ограничение cpu для процесса. На самом делел тут проблема лишь в бэкапе. Алексей а скажите пожалуйста при однородной схеме кластера на какой сервер слать запрос? или не важно? он перенаправит на другой сервер запрос и вернет результат на первый?

> возможно. решили просто попробовать вытянет ли. и он тянет нормально, но когда начинает выгружать данные из 100 млн таблиц с компрессией то average растте критически. думал сделать ограничение cpu для процесса. На самом делел тут проблема лишь в бэкапе. Для одного запроса ClickHouse использует по-умолчанию не больше CPU ядер, чем есть на машине. LA может быть большим, например, из-за того, что система упирается в диски. ClickHouse хочет прочитать что-то с диска. При этом в системе работают другие программы, которые тоже периодически что-то читают, и им приходится тоже ждать. Так получается больше потоков, которые ждут диска и растёт LA. Вы можете легко это проверить, запустив iostat -dmx 1

> Алексей а скажите пожалуйста при однородной схеме кластера на какой сервер слать запрос? или не важно? он перенаправит на другой сервер запрос и вернет результат на первый? Можно отправлять запрос на любой сервер, он выполнит его распределённо и вернёт результат (впрочем, в случае наличия одного шарда - выполнит его у себя). Выбирать следует любой живой сервер, возможно с приоритетами в зависимости от расположения в сети. Вы можете сделать логику на стороне клиента, которая просто выбирает первый попавшийся живой сервер по кругу, соединяясь с небольшим таймаутом. Или можете использовать HAProxy.

> Алексей а скажите пожалуйста при однородной схеме кластера на какой сервер слать запрос? или не важно? он перенаправит на другой сервер запрос и вернет результат на первый? Можно отправлять запрос на любой сервер, он выполнит его распределённо и вернёт результат (впрочем, в случае наличия одного шарда - выполнит его у себя). Выбирать следует любой живой сервер, возможно с приоритетами в зависимости от расположения в сети. Вы можете сделать логику на стороне клиента, которая просто выбирает первый попавшийся живой сервер по кругу, соединяясь с небольшим таймаутом. Или можете использовать HAProxy.

А что значит живой? живой тот кто быстро по таймауту вернул результат? иначе дергаем следующий?

Достаточно проверять возможность соединения с сервером за небольшой таймаут, если соединение ещё не установлено. Это покрывает почти все кейсы (хотя и не все). Таймаут на результат не подходит. Запросы бывают разные, с разным временем выполнения.

Достаточно проверять возможность соединения с сервером за небольшой таймаут, если соединение ещё не установлено. Это покрывает почти все кейсы (хотя и не все). Таймаут на результат не подходит. Запросы бывают разные, с разным временем выполнения.

я понял огромное спасибо) скажите где можно глянуть пример по построеннию однородной схемы кластера ?

Есть немного здесь: https://clickhouse.yandex/tutorial.html Но без пошаговой инструкции.

@milovidov_an http://devzen.ru/episode-0135/ это одна из тем слушателей. слушать с 01:42:44

Спасибо! Вчера послушал. Человек говорит странное мнение. Как можно подумать, что ClickHouse подходит "только для int-ов", когда самый популярный кейс - это clickstream, где всякие URL, Referer и тому подобное.

и правда странное :)

добрый вечер, никто не сталкивался с Read timed out равным 30 секундам на jdbc? хачется его увеличить

Вы можете использовать однородную схему кластера: все серверы могут принимать запросы и выполнять их распределённо. То есть, делать отдельный "принимающий" сервер не обязательно - можно на всех серверах создать одинаковые Distributed таблицы.

Может мой вопрос покажется глупым, но я все же задам. если основываться на таймаут то я так понял тут только репликация нужна между серверами чтобы данные всегда были идентичны? зачем тогда Distributed таблицы ? или они для репликаций и нужны?

есть глупый вопрос, есть буфер таблица traffic_buffer, есть таблица, в которую данные пушатся для сохранения на диск - traffic. Хочется сделать селект данныех только из буфер таблицы, чтобы не было выборки из таблицы, которая уже на диске.

судя по документации, select * from traffic_buffer делает выборку из буфер таблицы и из той, что уже сохранена на диск. А мне вот надо именно внутренности буфера.

Может мой вопрос покажется глупым, но я все же задам. если основываться на таймаут то я так понял тут только репликация нужна между серверами чтобы данные всегда были идентичны? зачем тогда Distributed таблицы ? или они для репликаций и нужны?

Distributed таблица нужна при наличии в кластере более одного шарда. Шарды - части кластера, содержащие разные части всех данных. Шардирование нужно, если данные не помещаются на один сервер.

судя по документации, select * from traffic_buffer делает выборку из буфер таблицы и из той, что уже сохранена на диск. А мне вот надо именно внутренности буфера.

Такой возможности нет.

:(

очень-очень жаль :(

Спасибо за ответ!

Distributed таблица нужна при наличии в кластере более одного шарда. Шарды - части кластера, содержащие разные части всех данных. Шардирование нужно, если данные не помещаются на один сервер.

а если шардирование не предусматривается? т.к. mergeTree как я понял сам разбивает данные по месяцам что вполне приемливо для нас. единственная цель которую мы преследуем это распределение нагрузки между серверами. я так понимаю два сервера с одинаковыми данными, но нагрузка распределена между ними и вставки и выборки максимально быстрые. может что нибудь посоветуете?

Если множество столбцов таблицы Buffer не совпадает с множеством столбцов подчинённой таблицы, то будут вставлено подмножество столбцов, которое присутствует в обеих таблицах. а если добавить поле которое будет присутствовать только в буферизированной таблице и по нему делать where ?

Спасибо за ответ!

Эту возможность можно добавить - с помощью виртуальных столбцов. Для примера смотрите использование столбца _part в StorageMergeTree.

Если множество столбцов таблицы Buffer не совпадает с множеством столбцов подчинённой таблицы, то будут вставлено подмножество столбцов, которое присутствует в обеих таблицах. а если добавить поле которое будет присутствовать только в буферизированной таблице и по нему делать where ?

Тогда запрос кинет исключение, потому что не увидит этого поля в основной таблице.

а если шардирование не предусматривается? т.к. mergeTree как я понял сам разбивает данные по месяцам что вполне приемливо для нас. единственная цель которую мы преследуем это распределение нагрузки между серверами. я так понимаю два сервера с одинаковыми данными, но нагрузка распределена между ними и вставки и выборки максимально быстрые. может что нибудь посоветуете?

Если шардирование не используется, то и Distributed таблицы создавать не надо.

Если шардирование не используется, то и Distributed таблицы создавать не надо.

тогда как распределить нагрузку ? я рассуждаю на уровне mysql. может в кх это по другмоу работает, если да, то как?

Если шардирование не используется, то и Distributed таблицы создавать не надо.

https://habrahabr.ru/company/centosadmin/blog/265593/ я об этом

На стороне клиента, который ходит на ваш кластер из одного шарда и многих реплик, вы можете воспользоваться одним из трёх вариантов: 1. Выбирать живую реплику в клиентском коде. 2. Установить HAProxy и ходить в него. 3. Установить пустой clickhouse-server и создать на нём Distributed таблицу, которая смотрит на кластер. Ходить в него.

добрый вечер, никто не сталкивался с Read timed out равным 30 секундам на jdbc? хачется его увеличить

"default.socket_timeout": "120000" для #zeppelin

На стороне клиента, который ходит на ваш кластер из одного шарда и многих реплик, вы можете воспользоваться одним из трёх вариантов: 1. Выбирать живую реплику в клиентском коде. 2. Установить HAProxy и ходить в него. 3. Установить пустой clickhouse-server и создать на нём Distributed таблицу, которая смотрит на кластер. Ходить в него.

мне это надо переварить) я так понимаю смысл балансировки в нахождении более быстрого узла в класстере и обращению к нему?

Обычно просто для отказоустойчивости и распределения нагрузки.

но репликация должны быть двухстороняя ?

если говорить о однородной схеме класстера

В ClickHouse репликация всегда multi-master.

вопрос по плагину Гарфаны для CH. А как добиться, чтобы оно работало, когда у меня CH на 127.0.0.1, а в гарфану я хожу проксируя ее через nginx с http auth?

я выбираю proxy режим, но при попытке теста соединения меня выбивает и требует пароль от узла, на котором у меня доступна графана.

InfluxDB подключен точь-в-точь по такой же схеме, но при этом пашет ОК.

Такое ощущение, то ли он пытается использовать мой http auth пароль для того, чтобы влезть в CH либо что-то еще.

Я могу ошибаться но галочка proxy в grafana в таком случае не нужна

не, у меня что инфлакс что кликхаус - на 127.0.0.1

Графана выставлена на публичный айпи и закрыта http auth. То есть инфлакс ходит в режиме прокси.

Пытаюсь добиться точь-в-точь такого же поведения с CH

http://ip_proxy:порт_clickhouse + Basic Auth c логиным и паролем от CH

а если пароль на CH дефалтный / без пароля?

меня еще смущает "There is a small feature - ClickHouse treats HTTP Basic Authentication credentials as a database user and will try to run queries using its name."

Так не пробовал но по умолчанию у пользователя default в пароля нет

Если не вводить пользователя используется пользователь default

вот так вот оно ведет себя в отладке хрома

Www-Authenticate:Basic realm="ClickHouse server HTTP API"

http://ip:8123/ что выдает в отладке

угу, судя по всему как-то данные от моего логина в Графану закрытого http auth просачиваются как реквизиты для коннекта к кликхаусу

скорее всего надо настраивать.

Просто если два basic

Bad Gateway :)

то один затрет второй

профит

ну при выборках с CH мне вообще атворизация не нужна, все с одних реквизитов лезут

Это из описания clickhouse datasource c grafana.com "ClickHouse treats HTTP Basic Authentication credentials as a database user and will try to run queries using its name."

Видимо так как ты хочешь не получиться сделать

или создать такого же юзера в базе, лол.

Ну это что то больно извращенно и не факт что работать будет

мне всегда казалось что в графане можно переопределить user/password в проксе.

как-нить вот так http://default:@127.0.0.1:8123 ?

например так

неа, нихт.

ну либо извратиться с авторизацией.

я думаю можно в нгинксе типа так

http://shairosenfeld.blogspot.ru/2011/03/authorization-header-in-nginx-for.html

ну либо почитать подобное.

неа, нихт.

как минимум в графитном datasource'е можно ткнуть галку basic auth

я буду такое делать но не сейчас. Просто пару раз наталкивался на подобное