Одним батчем ?

Если по HTTP заливать то он все равно на блоки разобъет и не будет ваш миллиард писать целиком, если через нативный протокол то вы, скорее всего, по памяти раньше вывалитесь чем блок такого размера сформируете

в ClickHouse столько не вставить за секунду

А в чем проблема?

Надо посмотреть этот момент

За сколько зальется миллиард

Одним батчем да не пролезет. Но у вас же лимит не один блок в секунду произвольного размера

А в чем проблема?

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

Одним батчем да не пролезет. Но у вас же лимит не один блок в секунду произвольного размера

Да, и вот в этом месте как раз можно легко наступить на то что он не будет успевать мержить

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

Ну я заливаю гигабайтами данные. За минуту скапливается порядка 3.5 гигов в несжатом виде и едет в Clickhouse, но через clickhouse-client

И все ок...там примерно 3 миллиона строк за минуту

Привет, подскажите, пожалуйста, можно ли как-то не вручную создать в запросе массив из констант определённой длины, что-то типо функции range(N), просто в доке ничего подобного не нашёл?

поиском по чату

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

Да, и вот в этом месте как раз можно легко наступить на то что он не будет успевать мержить

Да в мержи я наступил на 35кк. В этом месте нужно балансировать с размером блока и сортировкой на стороне паблишера. Например сортированные блоки размером 10кк уже не доставляют проблем с маржами на скорости 5 блоков в секунду

Да в мержи я наступил на 35кк. В этом месте нужно балансировать с размером блока и сортировкой на стороне паблишера. Например сортированные блоки размером 10кк уже не доставляют проблем с маржами на скорости 5 блоков в секунду

Таблица широкая?

Спасибо, нашёл!)

32 байта не сжатых данных на каждую строку

32 байта не сжатых данных на каждую строку

Да, таких данных можно постораться натолкать

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

для битовых операций есть только функции, операторы & и | не работают?

Добрый день, а что мешает делает преобразования прямо в приложении? Опять же движок log рассчитан на не более 1м записей.

в приложении конечно тоже можно, но 1. не хочется переизобретать функции типа порезать строку на вложенные массивы 2. например, хочется чтобы хеши сходились. то есть чтобы хранить например CityHash64(какая-то строка) и при этом в запросе делать where my_hashed_value=CityHash64(value)

Всем привет! Есть json структура, которая разниться в зависимости от event_type, насколько это адекватный способ хранения, подскажите плз. CREATE TABLE default.courses_events ( EventDate Date, EventTime DateTime, SessionId UInt64, TaskId String, EventType String, Offset UInt64, Attrs Nested( Key String, Value String) ) ENGINE = MergeTree(EventDate, SessionId, 8192);

т.е. конкретно интересует адекватность Attrs key->value, удобно ли потом будет аггрегировать из такой структуры

или лучше разложить в линейную?

вообще бесмысленно и можно в отдельные колонки положить

Вам точно кх нужен? Записей будет больше 10млн? У постгресса очень хорошие функции по работе с джсон.

Вам точно кх нужен? Записей будет больше 10млн? У постгресса очень хорошие функции по работе с джсон.

да, там тонны данных будет

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

вообще бесмысленно и можно в отдельные колонки положить

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

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

Аааа. Ок, тогда могу ещё посоветовать посмотреть на visitParamsExtract функции, мы так запихивали в кх просто строковый джсон а в определении таблицы колонки извлекались из json, очень удобно было.

Аааа. Ок, тогда могу ещё посоветовать посмотреть на visitParamsExtract функции, мы так запихивали в кх просто строковый джсон а в определении таблицы колонки извлекались из json, очень удобно было.

в этом месте поподробней, это похоже мне очень подходит

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

в этом месте поподробней, это похоже мне очень подходит

Сейчас найду определение таблицы

Буду признателен, спасибо.

В таком духе: CREATE TABLE IF NOT EXISTS events ( raw String, .... visitor FixedString(16) MATERIALIZED UUIDStringToNum(visitParamExtractString(raw, 'visitor')), )Ну и так далее со всеми колонками, MATERIALIZED значит что он соханит их действительно как колонки.

ок, спасибо!

Только посмотрите мануал по JSON функциям

Там есть маленькие особенности которые нужно иметь ввиду

https://clickhouse.yandex/docs/ru/functions/json_functions/

Скажите, а seed для rand() не поддерживатся?

Добрый день. Не подскажите как в данной БД получить последнее вставленное значение?

Добрый день. Не подскажите как в данной БД получить последнее вставленное значение?

SELECT * from mytbl ORDER BY ts DESC LIMIT 1, где таймстемп ваше поле с временем?

нет, тут хотят аналог last_insert_id()

которого нет

Ага, его тут нет. Ну по крайней мере это решило проблему его поиска)

SELECT * from mytbl ORDER BY ts DESC LIMIT 1, где таймстемп ваше поле с временем?

Спасибо, попробую.

я видел что в планах на первый квартал 2018 года был UPDATE. Есть новости какие?

я видел что в планах на первый квартал 2018 года был UPDATE. Есть новости какие?

Вот тут кое что есть https://github.com/yandex/ClickHouse/tree/mergetree-mutations2

За сколько зальется миллиард

Секунд за 20+ вполне может быть без шаманства. Я писал в районе 20 колонок (инты, даты, строки) в ширину хттп-клиентом до 500к в секунду, причём почти что на commodity hardware.

можно попробовать залить в редис 1 млрд строк по 8 байт

это 8 гб

и кинуть в кх)

Смысл проводить замеры на даных которые и близко к реальным не стояли?

там шел разговор от миллиарде

без такого извращения миллиард не передать

просто даже пропускная способность оперативки не даст

Прошу прощения, но что может быть не так в такой команде "curl 'http://localhost:8123?query=SELECT * from meteo.test'"?

Прошу прощения, но что может быть не так в такой команде "curl 'http://localhost:8123?query=SELECT * from meteo.test'"?

В query нужно пробелы экранировать

query не строка

Заменил пробелы на плюсы

Заменил пробелы на плюсы

https://stackoverflow.com/questions/32980081/curl-command-line-encoding-of-query-parameters-for-an-http-put

+пут убрать

С часок назад отправил клику alter на drop partition '197001' (мелкая, явно с левыми данными), разметом в мегабайт Вот уже 4к секунд ни ответа ни привета

На KILL QUERY реакции нет, pending

Как пропушить ?

посмотрите не используется ли эта партиция каким-то другим запросом

Ну уже должна была бы дойти очередь

Даже если было бы залочено

Странно, что и не отменяется

SHOW PROCESSLIST посмотрите

и не отменится

Секунд за 20+ вполне может быть без шаманства. Я писал в районе 20 колонок (инты, даты, строки) в ширину хттп-клиентом до 500к в секунду, причём почти что на commodity hardware.

Почему-то умножил на 20, а не на 2000 :D. Да, займёт больше 20 секунд, определённо)

Господа, подскажите, пожалуйста. Имеется следующая таблица: ┬─UTM_SOURCE────────┬─UTM_TERM───────┐ │ www.google.com.ua │ (not provided) │ │ www.google.com.ua │ (not provided) │ │ (direct) │ (none) │ │ fb │ (none) │ │ (direct) │ (none) │ │ www.google.com.ua │ (not provided) │ │ www.google.com.ua │ (not provided) │ │ www.google.com.ua │ (not provided) │ │ www.google.com.ua │ (not provided) │ └───────────────────┴────────────────┘ Нужно свести её к следующей (т.е. посчитать число последовательностей): ┬─UTM_SOURCE────────┬─UTM_TERM───────┬──────COUNT─┐ │ www.google.com.ua │ (not provided) │ 2 │ │ (direct) │ (none) │ 1 │ │ fb │ (none) │ 1 │ │ (direct) │ (none) │ 1 │ │ www.google.com.ua │ (not provided) │ 4 │ └───────────────────┴────────────────┴────────────┘ Понимаю, что упускаю что-то. Ткните носом, пожалуйста.

Товарищи, а из-за чего такое может приключаться? 2018.04.19 15:54:33.501697 [ 77 ] <Error> BaseDaemon: ######################################## 2018.04.19 15:54:33.501746 [ 77 ] <Error> BaseDaemon: (from thread 39) Received signal Segmentation fault (11). 2018.04.19 15:54:33.501757 [ 77 ] <Error> BaseDaemon: Address: NULL pointer. 2018.04.19 15:54:33.505088 [ 77 ] <Error> BaseDaemon: 1. clickhouse-server(DB::ColumnNullable::ColumnNullable(std::shared_ptr<DB::IColumn>, std::shared_ptr<DB::IColumn>)+0x76) [0x2999026] 2018.04.19 15:54:33.505098 [ 77 ] <Error> BaseDaemon: 2. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x34b2e45] 2018.04.19 15:54:33.505109 [ 77 ] <Error> BaseDaemon: 3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7ff77fe586ba] 2018.04.19 15:54:33.505116 [ 77 ] <Error> BaseDaemon: 4. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ff77f4793dd]

Товарищи, а из-за чего такое может приключаться? 2018.04.19 15:54:33.501697 [ 77 ] <Error> BaseDaemon: ######################################## 2018.04.19 15:54:33.501746 [ 77 ] <Error> BaseDaemon: (from thread 39) Received signal Segmentation fault (11). 2018.04.19 15:54:33.501757 [ 77 ] <Error> BaseDaemon: Address: NULL pointer. 2018.04.19 15:54:33.505088 [ 77 ] <Error> BaseDaemon: 1. clickhouse-server(DB::ColumnNullable::ColumnNullable(std::shared_ptr<DB::IColumn>, std::shared_ptr<DB::IColumn>)+0x76) [0x2999026] 2018.04.19 15:54:33.505098 [ 77 ] <Error> BaseDaemon: 2. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x34b2e45] 2018.04.19 15:54:33.505109 [ 77 ] <Error> BaseDaemon: 3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7ff77fe586ba] 2018.04.19 15:54:33.505116 [ 77 ] <Error> BaseDaemon: 4. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ff77f4793dd]

А можете показать что в 39 трэде происходило перед этим? ( grep -F '[ 39 ]' )

минутку

минутку

И версия у вас какая?

2018.04.19 15:39:06.067805 [ 39 ] <Error> virtual DB::WriteBufferFromHTTPServerResponse::~WriteBufferFromHTTPServerResponse(): Code: 24, e.displayText() = DB::Exception: Cannot write to ostream, e.what() = DB::Exception, Stack trace: 2018.04.19 15:43:15.488163 [ 39 ] <Error> virtual DB::WriteBufferFromHTTPServerResponse::~WriteBufferFromHTTPServerResponse(): Code: 24, e.displayText() = DB::Exception: Cannot write to ostream, e.what()

clickhouse-server-base/now 1.1.54236

С часок назад отправил клику alter на drop partition '197001' (мелкая, явно с левыми данными), разметом в мегабайт Вот уже 4к секунд ни ответа ни привета

Имеет посмотреть system.replication_queue для таблицы на обоих репликах. Там DROP_PARTITION будет записан как строка c type=DROP_RANGE. Там же должно быть написано сколько раз он пытался выполниться, и выполнялся ли вобще (может до него еще очередь не дошла).

вопрос по производительности ODBC драйвера, сейчас драйвер, на мой взгляд работает достаточно медленно, 9 млн записей он тянет минут 20 в то время как вертика справляется за минуту. Я подозреваю что это из-за того что он работает через HTTP. Есть ли планы по оптимизации драйвера?

2018.04.19 15:39:06.067805 [ 39 ] <Error> virtual DB::WriteBufferFromHTTPServerResponse::~WriteBufferFromHTTPServerResponse(): Code: 24, e.displayText() = DB::Exception: Cannot write to ostream, e.what() = DB::Exception, Stack trace: 2018.04.19 15:43:15.488163 [ 39 ] <Error> virtual DB::WriteBufferFromHTTPServerResponse::~WriteBufferFromHTTPServerResponse(): Code: 24, e.displayText() = DB::Exception: Cannot write to ostream, e.what()

Это слишком рано, интересует обычный (не Error) лог в районе 2018.04.19 15:54:33. Ну и версия довольно старая. В новых такой проблемы не должно быть, т.к. похоже проблема в Nullable-типах, которые активно фиксились с тех пор.

bilous@storage:~$ clickhouse-client ClickHouse client version 1.1.54378. Connecting to localhost:9000. Connected to ClickHouse server version 1.1.54378. storage ? select 1+1-1; SELECT (1 + 1) - 1 Aborted bilous@storage:~$

Имеет посмотреть system.replication_queue для таблицы на обоих репликах. Там DROP_PARTITION будет записан как строка c type=DROP_RANGE. Там же должно быть написано сколько раз он пытался выполниться, и выполнялся ли вобще (может до него еще очередь не дошла).

репликации нет

Это слишком рано, интересует обычный (не Error) лог в районе 2018.04.19 15:54:33. Ну и версия довольно старая. В новых такой проблемы не должно быть, т.к. похоже проблема в Nullable-типах, которые активно фиксились с тех пор.

2018.04.19 15:54:32.624649 [ 39 ] <Information> executeQuery: Read 1617 rows, 154.88 KiB in 0.222 sec., 7276 rows/sec., 696.99 KiB/sec. 2018.04.19 15:54:32.629303 [ 39 ] <Information> HTTPHandler: Done processing query 2018.04.19 15:54:32.828864 [ 39 ] <Information> executeQuery: Read 1617 rows, 154.88 KiB in 0.157 sec., 10319 rows/sec., 988.48 KiB/sec. 2018.04.19 15:54:32.834874 [ 39 ] <Information> HTTPHandler: Done processing query 2018.04.19 15:54:33.368325 [ 39 ] <Information> executeQuery: Read 1617 rows, 154.88 KiB in 0.274 sec., 5902 rows/sec., 565.32 KiB/sec. 2018.04.19 15:54:33.405938 [ 39 ] <Information> HTTPHandler: Done processing query 2018.04.19 15:59:12.215371 [ 39 ] <Information> executeQuery: Read 1617 rows, 154.88 KiB in 1.234 sec., 1310 rows/sec., 125.52 KiB/sec. 2018.04.19 15:59:12.216275 [ 39 ] <Information> HTTPHandler: Done processing query

Вообще обновление версии сервера (тем более, с такой старой) - это безопасный процесс ?

Вообще обновление версии сервера (тем более, с такой старой) - это безопасный процесс ?

Если репликации нет, то вобще можно не парится)

Вопрос про тип Int64/UInt64 в формате JSON: http://joxi.ru/p27n9NOi0GY6Zm?d=1

Вопрос про тип Int64/UInt64 в формате JSON: http://joxi.ru/p27n9NOi0GY6Zm?d=1

int64 может не влезть в JS Number

Вопрос про тип Int64/UInt64 в формате JSON: http://joxi.ru/p27n9NOi0GY6Zm?d=1

output_format_json_quote_64bit_integers = 0

bilous@storage:~$ clickhouse-client ClickHouse client version 1.1.54378. Connecting to localhost:9000. Connected to ClickHouse server version 1.1.54378. storage ? select 1+1-1; SELECT (1 + 1) - 1 Aborted bilous@storage:~$

Привет) У тебя SSE4 на машинке есть?

Если репликации нет, то вобще можно не парится)

спасибо

output_format_json_quote_64bit_integers = 0

Спасибо! ?