А у вас зфс в линуксе или фрибсд?

фря

я не говорил что zfs надо дохера памяти. я сказал что столько данных можно просто запихать в память

Ну нет финансовой возможности везде все запихивать в память

ну речь не про всё. и тут не так и много. а память побьет любую fs

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

256 гигабайт должно хватить

(всем)

Добрый день. Как в КХ лучше хранить хэши, в FixedString или в бинарном виде?

Добрый день всем. Стоит волноваться по поводу роста slab reclaimable? За несколько дней, пока пробуем с боевой нагрузкой, только-только начала притормаживать сегодня.

Добрый день. Как в КХ лучше хранить хэши, в FixedString или в бинарном виде?

Какого рода хеши и как они будут использованы? Если они одноуровневые, тогда можно использовать https://clickhouse.yandex/docs/ru/functions/json_functions/

Какого рода хеши и как они будут использованы? Если они одноуровневые, тогда можно использовать https://clickhouse.yandex/docs/ru/functions/json_functions/

наверное те хеши, которые md5/sha1

наверное те хеши, которые md5/sha1

Если md5/sha1 - тогда тип строка, бинарного типа данных в КХ нет

Если md5/sha1 - тогда тип строка, бинарного типа данных в КХ нет

Он есть ) FixedString

А при желании и в String можно все что угодно положить

Добрый день. Как в КХ лучше хранить хэши, в FixedString или в бинарном виде?

Т.е., например, тот же md5 без hex'a? Да, можно положить его в FixedString(16)

Да хэши md5, спасибо положим FixedString

добрый день в роадмапе update и delete запланированы на 1 квартал. прям можно ждать или это пока только мечты? )

WITH (1, 2, 3) AS set SELECT number IN set FROM system.numbers LIMIT 10

А будет ли возможно писать так? >WITH (SELECT ...) AS set

А будет ли возможно писать так? >WITH (SELECT ...) AS set

Делать нужно, можно даже в "тупую" как постгрес, просто запрос в памяти материализовать, вообще CTE штука очень нужная

У меня несолкьо JOIN и в каждом один и тот же IN (...). Выполняется он столько раз, сколько JOIN'ов. При этом каждый подзапрос JOIN изолирован и не получается построить запрос таким образом, чтобы IN(...) выполнялся всего один раз. Попробовал оператор WITH, но оказалось, что он тоже не виден в подзапросах. Думал сделать через временные таблицы, которые были бы доступны во всех подзапросах, однако при создании временной таблицы не работает оператор IF NOT EXISTS, что усложняет реализацию такого варианта.

IF NOT EXISTS поправили, наверное в следующем релизе будет работать.

У меня несолкьо JOIN и в каждом один и тот же IN (...). Выполняется он столько раз, сколько JOIN'ов. При этом каждый подзапрос JOIN изолирован и не получается построить запрос таким образом, чтобы IN(...) выполнялся всего один раз. Попробовал оператор WITH, но оказалось, что он тоже не виден в подзапросах. Думал сделать через временные таблицы, которые были бы доступны во всех подзапросах, однако при создании временной таблицы не работает оператор IF NOT EXISTS, что усложняет реализацию такого варианта.

drop temporary table if exists работает нормально, можно дропать

drop temporary table if exists работает нормально, можно дропать

Спасибо!

Привет, подскажите, я делаю запрос (например select quantiles(0.0,0.5,1.0)(x) from table) , получаю одну ячейку в таблице, которая содержить массив. Можно ли как-то этот массив разбомбить на несколько ячеек?

_[0], _[1]

вот такое в голову приходит :) select q[0] as q00, q[1] as q05, q[2] as q10 from (select [1, 2, 3] as q) SELECT q[0] AS q00, q[1] AS q05, q[2] AS q10 FROM ( SELECT [1, 2, 3] AS q ) ┌─q00─┬─q05─┬─q10─┐ │ 0 │ 1 │ 2 │ └─────┴─────┴─────┘ 1 rows in set. Elapsed: 0.007 sec.

только что-то результат не удался, лол

индексы 1-based

неожиданно

ну собственно SELECT q[1] AS q00, q[2] AS q05, q[3] AS q10 FROM ( SELECT [1, 2, 3] AS q ) ┌─q00─┬─q05─┬─q10─┐ │ 1 │ 2 │ 3 │ └─────┴─────┴─────┘

Если md5/sha1 - тогда тип строка, бинарного типа данных в КХ нет

В ClickHouse типы данных и String и FixedString позволяют хранить любые бинарные данные - аналогично VARBINARY/BLOB, BINARY. Хэши надо хранить в FixedString, так как они имеют фиксированную длину. Записывать надо бинарные данные. (Некоторые записывают hex, но это не имеет смысла). Для примера, MD5 - FixedString(16), SHA256 - FixedString(32).

давайте попробуем

https://github.com/yandex/clickhouse-odbc/releases/tag/2018-03-21

ага, посмотрим

В кх как-то можно просто построить гистограмму? quantiles() функция есть, а функции cdf() нет?

Гистограмм нет. Давно хотим.

Гистограмм нет. Давно хотим.

блин, да, гистограмма как аггрегирующая функция было бы очень круто

https://github.com/yandex/clickhouse-odbc/releases/tag/2018-03-21

не помогло, на ноябрьском драйвере все ок, оба новых дают таймаут после 30 секунд

я напишу тикет пожалуй

Сообщество подскажите, пожалуйста, есть ли возможность сделать индекс по содержимому значению в массиве? На текущий момент вижу решением - разворачивать массив и записывать его в другую таблицу. Но при данном подходе база сильно разрастается. Возможно посоветуете другой подход?

а почему его просто в колонки не разложить ?

а почему его просто в колонки не разложить ?

Длина массива динамичная.

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

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

Благодарю за подробный ответ.

Тогда вопрос разработчикам CH, можно ли будет ожидать в новых версиях функционал по индексу значения массива?

но если у вас по элементам этого массива есть хорошая селективность и вы можете положить куда-то свзяь элементы массива -> какой-то id полезный с точки зрения основных данных, то может будет работать через подзапрос или два запроса.

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

Таблица древовидной структуры пользователя: CREATE TABLE IF NOT EXISTS STRUCTURE ( ID UInt32 ,TIDs Nested( TID UInt32 ,LEVEL UInt32 ,LINE UInt32 ) ,VALID Int8 ,TIMESTAMP UInt32 ,EventDate Date ) ENGINE=CollapsingMergeTree(EventDate,(ID),8192,VALID); 'ID' = Порядковый номер пользователя в структуре. 'TIDs.TID' = Каждый вышестоящий порядковый номер пользователя до самого основания дерева. 'TIDs.LEVEL' = Уровень глубины в котором находится ID по отношению к TID 'TIDs.LINE' = Указывает номер ответвления ID по отношению к TID 'VALID' = Boolian - служит для диактивации записи в случае перемещения пользователя в другую ветку Основные запросы приходятся по полю 'TIDs.TID' (вышестоящий пользователь от которого собирается статистика): -- Узнать количество структуры -- Прирост структуры за интервал времени -- Вычисление самых активных пользователей в структурах по уровню глубины и отдельному ответвлению

В данном случае при запросе с указанием 'TIDs.TID' происходит выборка по каждой строке в базе данных. На текущий момент использую развертывание по триггеру: CREATE MATERIALIZED VIEW IF NOT EXISTS STRUCTURE_DETAL ENGINE=CollapsingMergeTree(EventDate,(TID,LEVEL,ID,LINE),8192,VALID) AS SELECT TIDs.TID as TID ,TIDs.LEVEL as LEVEL ,ID ,TIDs.LINE as LINE ,VALID ,TIMESTAMP ,EventDate FROM STRUCTURE ARRAY JOIN TIDs

кажется в этом случае индексы по массивам будут не раньше чем просто появятся какие-то secondary индексы, но ваша текущая вьюха все равно будет быстрее, т.к. в ней все уже сортировано как надо.

боюсь, secondary indexes даже немного противоречат идее кликхауса, потому что он умеет читать только целыми блоками, и для чтения данных, которые не отсортированы в порядке возрастания PK все равно нужно будет прочитать чуть ли не всю таблицу.

Кто-то пробовал для хранения/вычисления дельт (временных интервалов между двумя событиями) использовать SummingMergeTree? И насколько это по феншую? Помню, неоднократно писали, что дельты лучше считать сразу и писать в КХ уже посчитанное, но что делать, если хочется на КХ возложить это? Я хочу записывать две записи: сначала юникстайм с минусом, затем юникстайм с плюсом. SummingMergeTree просуммирует это потом и в итоге у меня в колонке будет дельта.

Кто-то пробовал для хранения/вычисления дельт (временных интервалов между двумя событиями) использовать SummingMergeTree? И насколько это по феншую? Помню, неоднократно писали, что дельты лучше считать сразу и писать в КХ уже посчитанное, но что делать, если хочется на КХ возложить это? Я хочу записывать две записи: сначала юникстайм с минусом, затем юникстайм с плюсом. SummingMergeTree просуммирует это потом и в итоге у меня в колонке будет дельта.

Если вы и так заранее знаете что было и что стало что мешает у себя посчитать и сразу писать в КХ готовый результат при этом без усложнений с записью?

боюсь, secondary indexes даже немного противоречат идее кликхауса, потому что он умеет читать только целыми блоками, и для чтения данных, которые не отсортированы в порядке возрастания PK все равно нужно будет прочитать чуть ли не всю таблицу.

Там, наверное, больше сложностей не с тем что нужно прочитать всё т.к. чтоб и сейчас не всё читать есть файлы "засечек", а с тем что потеряется "локальность данных", и придется бегать по диску. По сути ПК останется кластерным индексом, а вторичные могут быть где-то рядом (как у MySQL), но да, при специфике КХ он будет читать чуть больше, но гранулярность индекса можно настраивать и сейчас, Cloudflare этим успешно пользуется (вообще этим для ускорения можно пользоваться).

А Яндекс планирует натравить jespen test suite на кликхаус?)

день добрый

использую ClickHouse 1.1.54343 и команда select sumMap([],[]) ведет себя несколько не предсказуемо

У меня клиент после выполнения не может подключиться к КХ до его перезапуска. Это у меня так или у всех или надо обновиться?

Что в логе сервера ?

<Error> BaseDaemon: ########################################

а потом Couldn't start replication: DB::Exception, DB::Exception

на все реплики

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

select sumMap([],[]) это и есть весь запрос полный текст ошибки —--- [ 124 ] <Error> BaseDaemon: ######################################## [ 124 ] <Error> BaseDaemon: (from thread 30) Received signal Segmentation fault (11). [ 124 ] <Error> BaseDaemon: Address: NULL pointer. [ 124 ] <Error> BaseDaemon: 0. clickhouse-server(DB::ExpressionAnalyzer::analyzeAggregation()+0x5e9) [0x2ef5729] [ 124 ] <Error> BaseDaemon: 1. clickhouse-server(DB::ExpressionAnalyzer::init()+0x325) [0x2ef8275] [ 124 ] <Error> BaseDaemon: 2. clickhouse-server(DB::ExpressionAnalyzer::ExpressionAnalyzer(std::shared_ptr<DB::IAST> const&, DB::Context const&, std::shared_ptr<DB::IStorage> const&, DB::NamesAndTypesList const&, unsigned long, bool)+0x42f) [0x2ef87bf] [ 124 ] <Error> BaseDaemon: 3. clickhouse-server(DB::InterpreterSelectQuery::basicInit(std::shared_ptr<DB::IBlockInputStream> const&)+0xc0) [0x2b40550] [ 124 ] <Error> BaseDaemon: 4. clickhouse-server(DB::InterpreterSelectQuery::init(std::shared_ptr<DB::IBlockInputStream> const&, std::vector<std::string, std::allocator<std::string> > const&)+0x81) [0x2b3fb91] [ 124 ] <Error> BaseDaemon: 5. clickhouse-server(DB::InterpreterSelectQuery::InterpreterSelectQuery(std::shared_ptr<DB::IAST> const&, DB::Context const&, DB::QueryProcessingStage::Enum, unsigned long, std::shared_ptr<DB::IBlockInputStream>)+0x190) [0x2b40080] [ 124 ] <Error> BaseDaemon: 6. clickhouse-server(DB::InterpreterFactory::get(std::shared_ptr<DB::IAST>&, DB::Context&, DB::QueryProcessingStage::Enum)+0x8a) [0x2f02e9a] [ 124 ] <Error> BaseDaemon: 7. clickhouse-server() [0x2bd1bbd] [ 124 ] <Error> BaseDaemon: 8. clickhouse-server(DB::executeQuery(DB::ReadBuffer&, DB::WriteBuffer&, bool, DB::Context&, std::function<void (std::string const&)>)+0x1e3) [0x2bd2763] [ 124 ] <Error> BaseDaemon: 9. clickhouse-server(DB::HTTPHandler::processQuery(Poco::Net::HTTPServerRequest&, HTMLForm&, Poco::Net::HTTPServerResponse&, DB::HTTPHandler::Output&)+0x2b23) [0x1335783] [ 124 ] <Error> BaseDaemon: 10. clickhouse-server(DB::HTTPHandler::handleRequest(Poco::Net::HTTPServerRequest&, Poco::Net::HTTPServerResponse&)+0x377) [0x1337b07] [ 124 ] <Error> BaseDaemon: 11. clickhouse-server(Poco::Net::HTTPServerConnection::run()+0x2a2) [0x3526822] [ 124 ] <Error> BaseDaemon: 12. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x352275f] [ 124 ] <Error> BaseDaemon: 13. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x110) [0x3522dc0] [ 124 ] <Error> BaseDaemon: 14. clickhouse-server(Poco::PooledThread::run()+0x77) [0x339cfd7] [ 124 ] <Error> BaseDaemon: 15. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x38) [0x339a738] [ 124 ] <Error> BaseDaemon: 16. clickhouse-server() [0x35cecbf] [ 124 ] <Error> BaseDaemon: 17. /lib64/libpthread.so.0(+0x7e25) [0x7efe16975e25] [ 29 ] <Error> BaseDaemon: ######################################## [ 29 ] <Error> BaseDaemon: (from thread 28) Received signal Segmentation fault (11). [ 29 ] <Error> BaseDaemon: Address: NULL pointer. [ 29 ] <Error> BaseDaemon: 0. clickhouse-server(DB::ExpressionAnalyzer::analyzeAggregation()+0x5e9) [0x2ef5729] [ 29 ] <Error> BaseDaemon: 1. clickhouse-server(DB::ExpressionAnalyzer::init()+0x325) [0x2ef8275] [ 29 ] <Error> BaseDaemon: 2. clickhouse-server(DB::ExpressionAnalyzer::ExpressionAnalyzer(std::shared_ptr<DB::IAST> const&, DB::Context const&, std::shared_ptr<DB::IStorage> const&, DB::NamesAndTypesList const&, unsigned long, bool)+0x42f) [0x2ef87bf] [ 29 ] <Error> BaseDaemon: 3. clickhouse-server(DB::InterpreterSelectQuery::basicInit(std::shared_ptr<DB::IBlockInputStream> const&)+0xc0) [0x2b40550] [ 29 ] <Error> BaseDaemon: 4. clickhouse-server(DB::InterpreterSelectQuery::init(std::shared_ptr<DB::IBlockInputStream> const&, std::vector<std::string, std::allocator<std::string> > const&)+0x81) [0x2b3fb91] [ 29 ] <Error> BaseDaemon: 5. clickhouse-server(DB::InterpreterSelectQuery::InterpreterSelectQuery(std::shared_ptr<DB::IAST> const&, DB::Context const&, DB::QueryProcessingStage::Enum, unsigned long, std::shared_ptr<DB::IBlockInputStream>)+0x190) [0x2b40080]

[ 29 ] <Error> BaseDaemon: 6. clickhouse-server(DB::InterpreterFactory::get(std::shared_ptr<DB::IAST>&, DB::Context&, DB::QueryProcessingStage::Enum)+0x8a) [0x2f02e9a] [ 29 ] <Error> BaseDaemon: 7. clickhouse-server() [0x2bd1bbd] [ 29 ] <Error> BaseDaemon: 8. clickhouse-server(DB::executeQuery(DB::ReadBuffer&, DB::WriteBuffer&, bool, DB::Context&, std::function<void (std::string const&)>)+0x1e3) [0x2bd2763] [ 29 ] <Error> BaseDaemon: 9. clickhouse-server(DB::HTTPHandler::processQuery(Poco::Net::HTTPServerRequest&, HTMLForm&, Poco::Net::HTTPServerResponse&, DB::HTTPHandler::Output&)+0x2b23) [0x1335783] [ 29 ] <Error> BaseDaemon: 10. clickhouse-server(DB::HTTPHandler::handleRequest(Poco::Net::HTTPServerRequest&, Poco::Net::HTTPServerResponse&)+0x377) [0x1337b07] [ 29 ] <Error> BaseDaemon: 11. clickhouse-server(Poco::Net::HTTPServerConnection::run()+0x2a2) [0x3526822] [ 29 ] <Error> BaseDaemon: 12. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x352275f] [ 29 ] <Error> BaseDaemon: 13. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x110) [0x3522dc0] [ 29 ] <Error> BaseDaemon: 14. clickhouse-server(Poco::PooledThread::run()+0x77) [0x339cfd7] [ 29 ] <Error> BaseDaemon: 15. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x38) [0x339a738] [ 29 ] <Error> BaseDaemon: 16. clickhouse-server() [0x35cecbf] [ 29 ] <Error> BaseDaemon: 17. /lib64/libpthread.so.0(+0x7e25) [0x7fbb59ba6e25] [ 5 ] <Error> (StorageReplicatedMergeTree, RestartingThread): Couldn't start replication: DB::Exception, DB::Exception: Replica, stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x3317996] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0x131a3df] 2. clickhouse-server(DB::ReplicatedMergeTreeRestartingThread::activateReplica()+0x17e9) [0x2d4e639] 3. clickhouse-server(DB::ReplicatedMergeTreeRestartingThread::tryStartup()+0x24) [0x2d4e7c4] 4. clickhouse-server(DB::ReplicatedMergeTreeRestartingThread::run()+0xef) [0x2d4f45f] 5. clickhouse-server() [0x35cecbf] 6. /lib64/libpthread.so.0(+0x7e25) [0x7f4b7b738e25] —-

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

Если вы и так заранее знаете что было и что стало что мешает у себя посчитать и сразу писать в КХ готовый результат при этом без усложнений с записью?

Чтобы заранее знать - первый таймстамп придётся где-то хранить. А этого особо не хочется (хотя, логично, что это самый производительный вариант). А тут - в КХ записал и всё остальное он сам. Но есть беспокойство, что на стороне КХ будет лишняя нагрузка.

Чтобы заранее знать - первый таймстамп придётся где-то хранить. А этого особо не хочется (хотя, логично, что это самый производительный вариант). А тут - в КХ записал и всё остальное он сам. Но есть беспокойство, что на стороне КХ будет лишняя нагрузка.

Зачем тогда что-то с минусом писать? Берите runningDifference https://clickhouse.yandex/docs/en/single/#runningdifferencex будет работать как в InfluxDB если пишите какой-то счетчик который со временем увеличивается, например количество запросов к БД

Хочется, чтобы ещё и по объёму/количеству записей оптимально было :) В идеале - одна запись для каждого события.

Так-то понятно, что брать можно обычныйMergeTree и понеслась.

Хочется, чтобы ещё и по объёму/количеству записей оптимально было :) В идеале - одна запись для каждого события.

Тогда так и пишите, одно событие - одна запись и с помощью Summing потом схлопните или так и оставите, как удобнее/нужнее

Надо посчитать нарастающий итог, и я что-то не соображу, можно ли в КХ это запросом сделать? Элементарно: таблица из Date и Amount, посчитать нарастающий итог по Amount. Ткните носом в нужную функцию, плиз, если пропустил.

Зачем тогда что-то с минусом писать? Берите runningDifference https://clickhouse.yandex/docs/en/single/#runningdifferencex будет работать как в InfluxDB если пишите какой-то счетчик который со временем увеличивается, например количество запросов к БД

так вот же она

Это разница между соседними, а не нарастающий итог.

Это разница между соседними, а не нарастающий итог.

Есть еще runningAccumulate, можно в чатике поискать как пользоваться

Надо посчитать нарастающий итог, и я что-то не соображу, можно ли в КХ это запросом сделать? Элементарно: таблица из Date и Amount, посчитать нарастающий итог по Amount. Ткните носом в нужную функцию, плиз, если пропустил.

попробуйте - runningAccumulate https://github.com/yandex/ClickHouse/issues/1469

Прекрасно, это то что надо! Работает. Спасибо!

У меня клиент после выполнения не может подключиться к КХ до его перезапуска. Это у меня так или у всех или надо обновиться?

бага есть и в последней версии.

Всем привет! Не планируется ли что-то вроде range_complex_key_hashed словаря?

Коллеги нужна помощь. Есть бинарный дамп, его нужно развернуть в кликхаусе. Проблема в том, что структуры таблицы нет, а заказчик говорит, что можно и без него.

помогите

бинарный дамп в каком формате?

.dump

.dump

А с чего хоть его дампили ?

тоже с кликхауса

а как дампили? =) есть запрос?

нет к сожалению

тоже с кликхауса

Тогда` cat dump | clickhouse client —query "INSERT INTO table FORMAT Native" `

Тогда` cat dump | clickhouse client —query "INSERT INTO table FORMAT Native" `

а какую таблицу указывать если нет данных о структуре