я подтянул Кафку, потыкал ее, вроде бы ОК, но вот вариант с буфер таблицей нравится больше, не хочется ради батчинга тащить целый демон

но Алексей не рекомендует :(

я любитель сделать свое решения

пробовал писать в ch сервис с 1.5k rps - вышло паршиво без батч-буфера никак

а buffer таблица не помогает?

не пробовал

должна помочь

будет время - попробую

спасибо за наводку

что то кажется что limit by не работает. Либо я его не так готовлю. Клиент выдает синтаксическую ошибку.

Версия свежая?

Версия взята по apt-get update && apt-get install

Кажется, ответ на вопрос Алексея — скорее вывод чего-то вроде SELECT value FROM system.build_options WHERE name='VERSION_FULL';

Также есть SELECT version()

:-) просто как буду у ПК так предоставлю)

Версия свежая?

─version()─┐ │ 1.1.54164

─version()─┐ │ 1.1.54164

Да, это последняя версия. Значит не так пишете LIMIT BY. Можете показать?

Да, это последняя версия. Значит не так пишете LIMIT BY. Можете показать?

select * from my_metrics limit by 1; Syntax error: failed at position 32: select * from my_metrics group by user limit user by 1; Syntax error: failed at position 46: Expected number

Да, это последняя версия. Значит не так пишете LIMIT BY. Можете показать?

по идее limit by должен идти после group. я пробовал по разному)) но всегда выражение о простом лимите в error

select * from my_metrics limit by 1; Syntax error: failed at position 32: select * from my_metrics group by user limit user by 1; Syntax error: failed at position 46: Expected number

Надо писать select * from my_metrics limit 1 by user;

Всем привет Вот у меня такой вопрос назрел (я еще только знакомлюсь близко с CH): Есть толстый dev сервант на котором накопилось какое-то (терабайтное) количество данных. По какой методике/алгоритму лучше всего их перетащить на новую инсталлцию, уже кластерную?

Всем привет. Скажите, как организована балансировка запросов? И есть ли она? Или лучше делать что-то поверх, в стиле haproxy?

Всем привет Вот у меня такой вопрос назрел (я еще только знакомлюсь близко с CH): Есть толстый dev сервант на котором накопилось какое-то (терабайтное) количество данных. По какой методике/алгоритму лучше всего их перетащить на новую инсталлцию, уже кластерную?

если у вас нету 2х места на этом хосте - я бы сделал пайп select | insert через clickhouse-cli. если есть - создал бы реплицированную таблицу с кластером и засадил бы данные туда

если у вас нету 2х места на этом хосте - я бы сделал пайп select | insert через clickhouse-cli. если есть - создал бы реплицированную таблицу с кластером и засадил бы данные туда

Место не проблема , скорее при пайпе будет скорость страдать

Но вариант

Всем привет. Скажите, как организована балансировка запросов? И есть ли она? Или лучше делать что-то поверх, в стиле haproxy?

я думаю что общее количество соединений может исчисляться десятками. но в целом странно иметь много клиентов к аналитической базе. если больше - можно спрятать за haproxy. но лучше все конечно мерять

Место не проблема , скорее при пайпе будет скорость страдать

тогда да, делаете нормальную конфигурацию кластера, replicated/distributed локальную таблицу и заливаете

я думаю что общее количество соединений может исчисляться десятками. но в целом странно иметь много клиентов к аналитической базе. если больше - можно спрятать за haproxy. но лучше все конечно мерять

Да у нас просто выходит некий гибрид, аналитической с фронтендовой. Большой сторедж с данными к которым обращается большое(потенциально) количество клиентов(фронтенд, аналитики, алгоритмы).

select * from my_metrics limit by 1; Syntax error: failed at position 32: select * from my_metrics group by user limit user by 1; Syntax error: failed at position 46: Expected number

потому что выражение LIMIT N BY KEY. я на этой неделе добавил это в документацию

А еще скажите, где лежит самая актуальная документация? А то на https://clickhouse.yandex/reference_ru.html нет упоминания про sumIf, хотел поправить, сунулся в гит, а там вроде как вообще иная дока.

насколько я знаю на сайте лежит как раз мастер, например вот мое изменение https://clickhouse.yandex/reference_en.html#LIMIT N BY modifier

Я про русскую)

в англ тоже нет сейчас. выберете удобное место и сделайте PR

в гите эти же файлы - reference_

Вот тут вообще нет упоминания "Комбинатор -If. Условные агрегатные функции" https://github.com/yandex/ClickHouse/blob/master/doc/reference_ru.html а на сайте есть: https://clickhouse.yandex/reference_ru.html#Комбинатор -If. Условные агрегатные функции вот собственно и вопрос) Куда делать PR?

line 6540

ветка мастер

в англ тоже нет сейчас. выберете удобное место и сделайте PR

нашел

А, видимо мой косяк. Гитхаб в вебе говорит что всего строк 7759,а показывает только 5731

Еще вот вопрос. Когда выполняется запрос, слева появляются разные стрелочки. Что они означают?

я думаю это для того чтобы психологически запрос выстрее казался))

Интересно что логика порядка отображения не очевидна) неужели там действительно rand на выбор стоит)) Гляну потом в исходниках

мне всегда казалось что она по часовой крутится, но не суть важно)

Еще такой вопрос. max_memory_usage - Максимальное количество потребляемой памяти при выполнении запроса на одном сервере. Если у меня результат запроса занимает больше чем есть памяти на сервере то кроме расширения памяти мне ничего не поможет?

да, это есть в документации https://clickhouse.yandex/reference_en.html#ClickHouse features that can be considered disadvantages

и сорри, я обычно адресую к англ доке

у вас меньше 8 гб на сервере?

нет, у меня просто аналитики которые иногда любят select * ;(

ну это не настоящие аналитики. сначала палкой надо бить, потом топором

человек же физически не будет читать 10к строк

Да я так, скорее заранее от шишек защищаюсь. Чтоб знать что можно что нельзя)

я бы на эту тему прочитал про квоты юзеров. правда сам я это не настраивал

А какой алгоритм отправки запросов на другие сервера? Допустим у меня есть 3 сервера с репликой. Я отправляю запрос с 2мя агрегатными функциями. Он будет выполнен только на одном или парарллельно на 2х? Пытаюсь понять как CH масштабируется.

таблица replicated или distributed?

я подозреваю что 2е агрегатные функции никогда не будут запущены параллельно, потому что паралеллизация идет по данным. (либо партициям, либо сэмплингу)

ага, т.е. мне нужны в данном случае distributed?

запрос с 2мя агг функциями имеет в виду select uniq(userid), sumIf(event_count), что-то в этом духе?

ага

Вложенных ведь на сколько я понял нет.

если таблицы только replicated, то запрос будет выполняться полностью на одном сервере. но если у вас 3 реплики, лоад от нескольких запросов будет распределяться. т.е. каждый из третий запросов предположительно уйдет на свой сервер

если у вас distributed таблица, и вы скажем выполняете расчет за 6 месяцев данных, то каждому серверу достанется по 2 месяца.

Ага, т.е. один инстанс сам может распределить запросы по репликам. Это круто.

я не разработчик. но мне кажется что это сильно зависит от нагрузки, характера запросов и прочего. но проще всего начать просто с 3х реплик. поверх всегда можно создать distributed.

а если в документации нет чего, то welcome дописывать

Да, я только вникаю в CH и пока помню вопросы на которые не нашел сразу ответа буду пулить в доки.

вы наверно это читали уже https://clickhouse.yandex/tutorial.html?

да

с этого и начал.

Но вообще скорость конечно поражает. Что по сравнению с PG, что со спарком. Хотя академически их наверное не правильно сравнивать.

ну да, везде байты по разному хранятся. хотя где-то сравнивают http://tech.marksblogg.com/benchmarks.html

вопрос кстати к аудитории. кому-нибудь нужен spark-clickhouse коннектор?

Нам)

Очень думаю будет нужен.

зачем?

Вот так вот прям список аргументов не смогу наверное выложить. Но сейчас вся инфраструктура на spark/cassandra/Postgres. Возможно не все получится перевести на CH.

Как минимум первое время

ну у нас допустим был elastic-spark коннектор до этого. но когда переехали на CH - стал просто 1 запрос по rest. коннектор нужен если вы хотите создавать произвольные memory/log таблицы в clickhouse во время работы спарка. а так jdbc драйвера должно хватать. я просто смотрел реализацию snowflake connector, для кликхауса можно создать что-то подобное, но у меня юзкейсов нет

кстати, язык - scala?

Да, язык scala. На счёт запроса по rest не понял

Вы с парк данные забираете через rest?

до этого данные выгребались с эластика в спарк и там проводилась аггрегация. когда это переехало с кликхаус - стал только один запрос с кучей group by и агг функциями. поэтому можно делать это напрямую

у нас просто есть scala клиент к КХ для запросов + реализацией reactive streams, но все не доходят руки тесты дописать, отвязанные от нашей доменной области, чтобы заопенсорсить

Из под какого пользователя на шадрах выполняются запросы? Кажется это readonly. Или я ошибаюсь?

Default, но можно явно задать в конфиге

Указывается вот так <replica> <host>HOST</host> <port>9000</port> <user>user</user> <password>passwd</password> </replica>

Вот так

не так давно писал что у меня КХ падал при вставке большого количества столбцов и строк.. потестил на компе 4 ядра core i5, 32 гига оперативки и ssd..действительно не падает) ~2300 колонок,все в ключ добавлены в MergeTree(FlightDate, (..вот сюда..),8192) в таблицу забито 1млн строк..немного потестил адовый селект с where в котором около 200 условий кушает ~700мб памяти, отдает за 400-600мс если в where 10-20 условий,то 40-140мс,60-80мб памяти.. сравнивать особо не с чем,но для моих задач за глаза!) остается такой вопрос.. при вставке данных CH временами писал что скушал 16Гб памяти для обработки insert,но при select'ах больше гига ему вроде бы не нужно... можно ли сделать вставку на одном компе и всю базу файлами перенести на виртуалку в облако с маленьким объемом памяти? не понадобится ли ему много оперативки при загрузке такой БД? выполнять нужно только селекты..изменять данные не придется

не так давно писал что у меня КХ падал при вставке большого количества столбцов и строк.. потестил на компе 4 ядра core i5, 32 гига оперативки и ssd..действительно не падает) ~2300 колонок,все в ключ добавлены в MergeTree(FlightDate, (..вот сюда..),8192) в таблицу забито 1млн строк..немного потестил адовый селект с where в котором около 200 условий кушает ~700мб памяти, отдает за 400-600мс если в where 10-20 условий,то 40-140мс,60-80мб памяти.. сравнивать особо не с чем,но для моих задач за глаза!) остается такой вопрос.. при вставке данных CH временами писал что скушал 16Гб памяти для обработки insert,но при select'ах больше гига ему вроде бы не нужно... можно ли сделать вставку на одном компе и всю базу файлами перенести на виртуалку в облако с маленьким объемом памяти? не понадобится ли ему много оперативки при загрузке такой БД? выполнять нужно только селекты..изменять данные не придется

А каков общий вес таблицы?

GUI http://guiclickhouse.smi2.ru/sql пишет что около 3.9Гб

даже меньше.. 3.09Гб