если ос будет "iOS", там все равно будет 70 символов занято

если у вас строки короче 70, то они и так меньеш будут занимать.

это не 70 символов

это 70 байт

в доке так описано по крайне мере)

про ос верное замечание

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

подключил драйвер пишу скриптик импорта из mysql в clickhouse вот и посмотрим. кстати пишут больше 100 insert в секунду низя?

ну вы вставляйте побольше сразу. 10-100к строк например

это 70 байт

точно, пардон

ну вы вставляйте побольше сразу. 10-100к строк например

а это реально 100к строк в секунду ?

ну если не по модему на сервер шлете

я в плане того выдержит ли clickhouse такую пачку и обработает ли за секунду ?

проверьте, а?)

Производительность при вставке данных. Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду. Что если вставлять более 1K строк чаще чем раз в секунду (большими инсертами). Как это будет сказываться на производительности? Оптимально ли это? Рекомендации указанные в руководстве относятся к инстансу/базе/таблице?

Батчи можно сделать больше. Например, 100k строк в секунду. В зависимости от данных, возможно до нескольких миллионов строк в секунду. Но увеличивать частоту вставок не стоит. Рекомендация относится к одной таблице. Но при наличии большого количества серверов, возможна слишком большая нагрузка на ZooKeeper, и это ограничивает частоту вставок на весь кластер.

я то проверю но я расчитывал на 100 записей в секунду предел ) блин ребят спасибо что отвечаете это так круто что я попал на этот канал и вы помогаете)) мы уже 2-3 месяца занимаемся какой-то херней) уже и кроном в кеш пишем чтобы статистику показывать сразу и начали агрегировать данные, потом стали дописывать только новое, а записей все больше требования все выше крон все дольше выполняется мы уже все посидели))) а тут clickhouse )

А вот у меня вопрос еще: кто пользуется кафкой как буфером, вы как сконфигурировали консьюмеры? Интересует auto.offset.reset и конфигурации, связанные с размерами сообщений, может есть какие-то практики для конфигурации связки кафка-кликхаус или интересные кейсы. И сразу второй вопрос: если выполнять параллельно несколько инсертов, то какой предел, после которого производительность вставки на кластер перестанет увеличиваться? Имею в виду количество параллельно работающих инсертов в одну реплицируемую таблицу.

ребят может мой вопрос покажется очень простым)) в mysql у некоторых записей есть значения null - clickhouse отказывается такое хавать)) что ему отправлять ? например если это число то наверное 0 ? тупо приведение null к типу int даст 0. а со строкой как быть?

значение по умолчанию для String это пустая строка, если вас это устраивает - можете вставлять пустую строку. есть тип данных Nullable(T), который поддерживает значение NULL, но работа над его поддержкой в сервере еще не завершена.

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

[ClickHouseDB\DatabaseException] Cannot parse expression of type FixedString(70) here: ,,0,0,'')

все не пинайте это я походу просто не то пишу)

УРА! работает

total_time: 0.344

10 строк 0.344 вставлялось ? эмм

500 записей вставилось за "total_time" => 1.312

это нормальный результат для MergeTree engine? 500 insert послал в clickhouse

500инсертов по одной строке?

неа всем махом

а скок строк на запрос?

сделал запрос в табличку mysql взял данные трансформировал для преобразования типов и нужных полей положил в массив. кинул в массив на insert

в каком формате вставляли?

500 строк

в текстовом

то есть отправлял массив данных

ну их много текстовых. CSV, Tabseparated, Values

массив вида ['1','2','2',....], ['1','2','2',....], ['1','2','2',....], ...

ээм

я работаю через драйвер php

там небольшой клиент + обертка orm

может они оверхед добавляют? я б не сказал что это нормально

как я понял он шлет через curl запрос multiquery

попробуйте clickhouse-clientом или напишите просто курловый запрос и POSTом в TSV данные фиганите

"url" => "http://...:8123/?extremes=0&readonly=0&max_execution_time=10&enable_http_compression=0&database=statistics" "content_type" => "text/plain; charset=UTF-8"

вот куда он шлет и с какими параметрами

можете эти 500 строк запихнуть в файл типа CSV/TSV (или в переменную просто) и одним запросом с "query=INSERT INTO table (...) FORMAT CSV" в query string и 500 строками данных в формате CSV в POSTе

или cat data.csv | clickhouse-client --query "INSERT INTO .. (..) FORMAT CSV"

слать файлик вместо строки?

нене, его содержимое

хотелось бы в рамках драйвера который использую

$file_data_names = [ '/tmp/clickHouseDB_test.1.data', '/tmp/clickHouseDB_test.2.data', '/tmp/clickHouseDB_test.3.data', '/tmp/clickHouseDB_test.4.data', '/tmp/clickHouseDB_test.5.data', ]; // insert all files $stat = $db->insertBatchFiles( 'summing_url_views', $file_data_names, ['event_time', 'site_key', 'site_id', 'views', 'v_00', 'v_55'] );

предлагают такое решение

"Parallelizing massive inserts from CSV file"

попробуйте) но я б напрямую попробовал для сравнения

оно полюбому будет быстрее т.к. выполняется локально

а тут запрос на сервер занимает какое-то время

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

по скрину выше видно что пока подключился пока отправил данные

я как раз таки отправляю из локально компа на удаленный

а если зайду на машину и там выполню время подключения и отправки не актуально т.к. я уже на сервере и напрямую делаю запрос

может комперсия gzip поможет?

ну тогда может из-за сети, конечно, так долго

может) enable_http_compression и соотв заголовок в хттп запрос тогда

в репозитории кх можно найти тест хттп сжатия, можно в качестве примера заюзать

в драйвере есть уже сжатие

сча попробую

ну у нас все удаленные машины в одном кластере

одна сеть

там скорость будет бешенная

это я с локальной машины шлю результат не тот

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

Всем привет! Если вы на CodeFest в Новосибирске приходите к 14:30 на импровизированную встречу.

Или ищите нас в кулуарах.

500 записей вставилось за "total_time" => 1.312

Чет мало. У тебя наверное insert на каждую запись. А лучше батчами, т.е. ты в одном insert передаешь множество строк. В таком режиме у меня 232млн записей льются за 2м40с.

Чет мало. У тебя наверное insert на каждую запись. А лучше батчами, т.е. ты в одном insert передаешь множество строк. В таком режиме у меня 232млн записей льются за 2м40с.

внутри сети получился результат около 400 тыс в секунду. по вашим результатам выходит 1.5 млн в секунду. как так? я делаю батчем

Чет мало. У тебя наверное insert на каждую запись. А лучше батчами, т.е. ты в одном insert передаешь множество строк. В таком режиме у меня 232млн записей льются за 2м40с.

может вы csv шлете с компресией ? я шлю как строку с множеством записей

@all может кто подскажет какой самый быстрый способ вставки строкой или через csv file

вы clickhouse-client c curl'ом попробовали уже?)

вы clickhouse-client c curl'ом попробовали уже?)

в 6 утра лег исправил ошибку в своем импорте выполнил локально результаты были не очень. потом залил на машину которая в сети с машиной клик хаус стоит и результат пачка 50 тыс. записей = 0.21 сек

вы clickhouse-client c curl'ом попробовали уже?)

есть статейка на хабре 10 млн записей импортнули за 4 секунды что равно 2 500 000 записей в секунду это результат очень классный, но не пойму как они добились этого. может через csv надо импорт делать. вначале собирать все в файлик потом файлик кидать в clickhouse с компресией

*они делали через csv. но разве разница есть отправлять запрос вида INSERT INTO table (value),(value),(value), ... (fields) или в csv

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

может вы csv шлете с компресией ? я шлю как строку с множеством записей

Я упустил тот момент что вы шлете по сети. У меня так вставка идёт локально.

Я упустил тот момент что вы шлете по сети. У меня так вставка идёт локально.

ну у нас отдельный сервер на нем целый движок собирает данные и записывает. локально просто не можем

Да я понимаю

А еще это же сильно зависит от количества столбцов.

у нас их около 40

Да я понимаю

большая часть int значения. пару полей string

у меня 16 колонок. Общий вес 232млн строк в CSV примерно 30-40гб

у меня 16 колонок. Общий вес 232млн строк в CSV примерно 30-40гб

ну у нас столько данных в секунду не бывает. пока около 5-50 записей в секунду. но дальше будет больше. важно сделать замер максимального количесвто вставок в секунду чтобы знать пределы системы

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

еще такой вопрос. примари кей приоритетнее для каких полей выставлять? по которым GROUP и WHERE IN ?

https://groups.google.com/forum/#!searchin/clickhouse/%D0%B8%D0%BD%D0%B4%D0%B5%D0%BA%D1%81%7Csort:relevance/clickhouse/eUrsP30VtSU/p4-pxgdXAgAJ

еще такой вопрос. примари кей приоритетнее для каких полей выставлять? по которым GROUP и WHERE IN ?

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