Можно класть по любому количеству строк. Для го есть нативная библиотека неплохая

количество в 1000 на один POST где-то в документации встретил... поищу. И всё равно - получившееся число передавалось ощутимо долго, вся процедура ETL (простите, не DBA - могу не к месту использовать этот термин) выбивается из лимита в 60 секунд

Рекомендации не менее 1000

оуч, попробую! Спасибо за уточнение

https://github.com/kshvakov/clickhouse/

То есть лучше 10 раз в секунду по 100000 строк, чем 100 раз по 10000

в параллели можно insert делать?

М... Никто не запрещает как бы :)

ребят, доброе утро. только начал экспериментировать с ch, прошу терпеливо направить: Нужно настроить перекладку записей из имеющейся продуктивной MS SQL базы в таблицу CH. На данный момент хочу делать это раз в минуту (за 60 секунд в источнике генерируется ~19к строк). После некоторого тюнинга запроса на MSSQL инстансе он выполняется за 15-30 секунд (приходится джойнить две толстые таблицы), в зависимости от загрузки сервера. 1 секунда уходит на складывание PIVOT-ом пары строк в одну вида [date],[timestamp_utc],[metric.1],[metric.2] всё это генерируется на стороне MSSQL сервера - windows server. Какие есть годные варианты, чтобы максимально быстро сложить результирующий CSV в таблицу CH? Пока успел попробовать только передавать через web-морду по 1000 строк curl-ом - ооочень медленно. Поглядел на Go либу - она вроде только через web работает.. Может, я невнимательно читал документацию и задачу записи через web-interface я мог бы распараллелить? Engine = MergeTree

То есть лучше 10 раз в секунду по 100000 строк, чем 100 раз по 10000

Вроде как лучше один раз в секунду по миллиону. Именно это написано в мануале

Но миллион в секунду - это нереальные же цифры

в параллели можно insert делать?

можно, но если в одну таблицу то будет медленно, вставка пачками (большими) обусловленна тем что CH потом эти куски данных сливает вместе с имеющимися, а это дорогая операция

Спасибо. Прихожу к выводу, что оптимальнее загрузкой данных в CH было бы заниматься на стороне самого CH - вовне останется только подключение к mssql инстансу за данными. Распарсить и скормить в таблицу легче/быстрее на сервере CH через clickhouse-client, например..

Аналогичная проблема. И пока не проверил, но надеюсь что buffer engine тут поможет. Так как не очень хочется внешние обвязки для буфера делать: + дополнительная часть + задержка данных

Evgeny, @inv2004: Кхм, не уверен, что касательно моей задачи вопрос в маленьких пачках данных. У меня сейчас жалкие 19к строк через web интерфейс передаётся 14+ минут, а это всего лишь данные источника за минуту. csv с этими данными - меньше 3Мб. Важное замечание, возможно - вместо curl приходится использовать cmdlet Powershell-а 'Invoke-RestMethod' - может, косяк производительности в нём? P.S.: @maxlapshin, lol... 1.000.000 строк в секунду да при моей текущей производительности...

Evgeny, @inv2004: Кхм, не уверен, что касательно моей задачи вопрос в маленьких пачках данных. У меня сейчас жалкие 19к строк через web интерфейс передаётся 14+ минут, а это всего лишь данные источника за минуту. csv с этими данными - меньше 3Мб. Важное замечание, возможно - вместо curl приходится использовать cmdlet Powershell-а 'Invoke-RestMethod' - может, косяк производительности в нём? P.S.: @maxlapshin, lol... 1.000.000 строк в секунду да при моей текущей производительности...

А что странного в миллионе строк в секунду? И тут надо еще понимать: 1) размер строки, сколько там колонок. Строка из 10 интов, и 100 стрингов -- это две большие разницы. 2) производительность дисковой подсистемы. В рамках одного сервера упирается обычно в диск 3) сколько серверов в кластере. Вставка при правильном дизайне масштабируется линейно Можно грубо прикинуть размер строки в байтах, поделить его примерно на 5 (компрессия), а еще лучше померить точнее, как жмет ваши данные КликХаус, и соотнести с write speed дисковой подсистемы. Это будет верхний предел, но КликХаус от него не сильно должен отступать при достаточно больших блоках

Я имел ввиду скорее на один сервер