Господа, а можно как-то примерно прикинуть, сколько по времени КХ будет делать optimize table ... final?

Добрый день, можно как-то скопировать готовые базы КХ на другую машину? Зукипера нет, реплик нет, просто тестовая база на одной машине

остановить КХ, скопировать data и metadata на другую машину, запустить КХ

остановить КХ, скопировать data и metadata на другую машину, запустить КХ

А пути в конфигах прописаны?

да

да

Понял, спасибо

В КХ есть возможность получить лог/отчёт/метрики по запросам и сожранными ими CPU time

И есть ли возможность каким либо способом в рамках явно заданного временного интервала, повторно не исполнять одинаковые запросы. Регистрировать их где-нибудь в системных таблицах КХ и результаты работы самого первого запроса отдавать остальным клиентам

Мы можем это сделать в редисе или где-нибудь ещё, но мы любим КХ и не любим тратить ресурсы

:)

Только анонсирована (вчера) вощможность получать метрики по реальному CPU и IO time по запросам.

Ооооо супер

Пока нет кэша запросов - придётся на своей стороне.

Деталей я не помню уже, помню что ни один инструмент по итогу не заработал. Может что-то с тех пор поменялось в кх или пентахо? Как настраивал? Были танцы с бубном?

были конечно, если руки дойдут то опубликую how-to

Подскажите, пожалуйста: 1. Лучше мощная машина или несколько средних нод для кластера? 2. Если лучше ноды, то можно ли без даунтайма докинуть еще нод в существующий кластер? 3. Увеличивается ли линейно скорость выполнения запроса с количеством нод пусть и со снижением производительности до полной синхронизации? (Можно ли просчитать стоимость железа исходя из объема данных и требуемых RPS). 4. Апгрейд на минорную версию сложная задача по сравнению с постгресом? 5. Есть ли готовые инструменты бэкапа или достаточно стянуть data и metadata? 6. Можно ли развернуть сначала в простом варианте без кафки и реплик и по мере необходимости докидывать ресурсы, либо лучше сразу организовать кластер?

1. Несколько средних лучше (быстрее), чем одна жирная, как правило. 2. Можно, перечитает на лету 3. Зависит от запроса, но за то же время в n раз данных параллельно считывается с диска больше, но есть накладки на получение их на мержащей ноде и на процессе мержа результата 4. Не пробовали даунгрейдить 5. Про готовое не слышал, есть варианты с FREEZE PARTITION, почитайте в доке 6. Не кафки, а зукипера, наверное, а вообще вам решать насколько доступны должны быть данные, если вы можете себе позволить восстанавливаться n времени из бэкапа/tsv/чего угодно, то можно и без реплик=) Кстати, кластер -- это не обязательно конфигурация с репликацией, можно просто несколько шардов и без нее, и зукипер не нужен

1. Несколько средних лучше (быстрее), чем одна жирная, как правило. 2. Можно, перечитает на лету 3. Зависит от запроса, но за то же время в n раз данных параллельно считывается с диска больше, но есть накладки на получение их на мержащей ноде и на процессе мержа результата 4. Не пробовали даунгрейдить 5. Про готовое не слышал, есть варианты с FREEZE PARTITION, почитайте в доке 6. Не кафки, а зукипера, наверное, а вообще вам решать насколько доступны должны быть данные, если вы можете себе позволить восстанавливаться n времени из бэкапа/tsv/чего угодно, то можно и без реплик=) Кстати, кластер -- это не обязательно конфигурация с репликацией, можно просто несколько шардов и без нее, и зукипер не нужен

Спасибо!

Поправил статью на википедии, думаю теперь должно быть ок. Почитайте / поправьте если что-то плохо получилось, или очепятки какие-то. https://ru.wikipedia.org/wiki/ClickHouse

Не увидел там в списке компаний Сми2 которые используют КХ :) может плохо искал

А еще ClickHouse используют в xHamster :)

И ща все сделают вид что воооооообще никогда о таких не слышали

добрый день, ситуация - есть сотни дампов из postgres, по несколько гигабайт каждый. каков наиболее эффективный способ залить это в КХ? По всей видимости эти дампы придется первоначально залить в postgres. Есть ли возможность прямого импорта данных из постгреса или придется промежуточно выгружать данные на диск в tsv?

добрый день, ситуация - есть сотни дампов из postgres, по несколько гигабайт каждый. каков наиболее эффективный способ залить это в КХ? По всей видимости эти дампы придется первоначально залить в postgres. Есть ли возможность прямого импорта данных из постгреса или придется промежуточно выгружать данные на диск в tsv?

емнип, в доке, где описаны тестовые наборы данных, есть справка как конвертить postgres дампы в KH

Добрый день, мне надо сделать SELECT DISTINCT по строке (примерно 1-5% записей дублируются остальные разные) чтоб из дубликатов выбрать последний, если я заведу ее в PK это сильно поможет? (есть дргугие условия SLECT'а которые уже в PK)

емнип, в доке, где описаны тестовые наборы данных, есть справка как конвертить postgres дампы в KH

спасибо, доки смотрел, но не догадался посмотреть в тестовых наборах)

емнип, в доке, где описаны тестовые наборы данных, есть справка как конвертить postgres дампы в KH

если речь про https://clickhouse.yandex/docs/ru/getting_started/example_datasets/nyc_taxi/#_1 то там перенос данных из pg в кх осуществляется через экспорт данных из pg в tsv на диск при этом, правда, упомянуто что "Импорт данных напрямую из Postgres также возможен с использованием COPY ... TO PROGRAM."

если речь про https://clickhouse.yandex/docs/ru/getting_started/example_datasets/nyc_taxi/#_1 то там перенос данных из pg в кх осуществляется через экспорт данных из pg в tsv на диск при этом, правда, упомянуто что "Импорт данных напрямую из Postgres также возможен с использованием COPY ... TO PROGRAM."

тут уж я пас, просто вспомнил момент из доки

но и это уже помогло, спасибо буду читать про copy ... to program

А еще ClickHouse используют в xHamster :)

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

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

А где можно почитать?

На тему?

Если веб клиент то это Tabix

А, ок

Если пхп клиент то это php-clickhouse

А если о внедрении нужно найти видео выступление

Сейчас попробую найти

А если о внедрении нужно найти видео выступление

Да вот это

Как запустить ClickHouse своими силами и выиграть джекпот https://habr.com/post/314558/

Вот

Видео пока не нашел (

Как запустить ClickHouse своими силами и выиграть джекпот https://habr.com/post/314558/

Спасибо, это читал

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

Это решается только через GROUP by uniqID ?

Может есть хитрая ф-ция в CH которая все круто сделает?

Всего групп - сотни миллионов и стремится к бесконечности, количество повторений в группе - десяток

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

https://clickhouse.yandex/docs/ru/query_language/select/#limit-n-by если вам нужна последняя по времени запись со всеми столбцами целиком (GROUP BY не нужен, но нужно будет сортировать) https://clickhouse.yandex/docs/ru/query_language/agg_functions/reference/#anylastx если вам нужно обработать только *одно* поле (тогда нужно будет делать GROUP BY uniqID)

https://clickhouse.yandex/docs/ru/query_language/select/#limit-n-by если вам нужна последняя по времени запись со всеми столбцами целиком (GROUP BY не нужен, но нужно будет сортировать) https://clickhouse.yandex/docs/ru/query_language/agg_functions/reference/#anylastx если вам нужно обработать только *одно* поле (тогда нужно будет делать GROUP BY uniqID)

Спасибо буду читать

Привет! Никто не замечал, что начиная где-то с версии 18.10.3 CollapsingMergeTree начал схлопывать записи совершенно рандомно? На параллельном необновлённом сервере с 18.6.0 с такими же данными такого нет. Таблица CollapsingMergeTree (date1, (string2, int3, int4), 8192, int5sign) — такое впечатление, что стал склеивать просто по string2 игнорируя всё остальное на свете.

В чейнджлоге только одно изменение про этот движок “поддежка пустых кусков после мержей в движках Summing, Collapsing and VersionedCollapsing”

Привет! Никто не замечал, что начиная где-то с версии 18.10.3 CollapsingMergeTree начал схлопывать записи совершенно рандомно? На параллельном необновлённом сервере с 18.6.0 с такими же данными такого нет. Таблица CollapsingMergeTree (date1, (string2, int3, int4), 8192, int5sign) — такое впечатление, что стал склеивать просто по string2 игнорируя всё остальное на свете.

В 18.10.3 такое не меняли, поэтому нужно больше подробностей для разбирательств.

Привет! Никто не замечал, что начиная где-то с версии 18.10.3 CollapsingMergeTree начал схлопывать записи совершенно рандомно? На параллельном необновлённом сервере с 18.6.0 с такими же данными такого нет. Таблица CollapsingMergeTree (date1, (string2, int3, int4), 8192, int5sign) — такое впечатление, что стал склеивать просто по string2 игнорируя всё остальное на свете.

Проверил на одном из серверов, где версия 18.10.3 и CollapsingMergeTree с составным ключом - нет заметной разницы в количестве строк в сутки после выкладки.

У нас после обновления где-то в районе версии 1.1.54390 Кликхаус падать с сегфолтами типа 2018.08.14 03:50:29.451454 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.451482 [ 223631 ] <Error> BaseDaemon: (from thread 223630) Received signal Segmentation fault (11). где-то раз в несколько дней, поэтому начали обновлять всё время до последних версий с каждым релизом, чтобы посмотреть — может пропадёт сегфолт. Баг с CollapsingMergeTree появился как раз в районе 13-го числа, когда вышла 18.10, затрагивает примерно 0.5% вставки. При вставки записи в составной ключ второй частью входит совершенно новый числовой id, но склеивается он почему-то с очень старыми записями (где понятное дело другой id). Сейчас откатились на 18.6, смотрим.

Пока чистили таблицы от этих кривых мёрджей (у нас можно заново данные получить из другой БД) методом INSERT INTO … SELECT * (битые из другой БД, нормальные так) — в логе появилась пара ошибок типа число строк со знаком “1” отличается больше чем на 1 от числа строк со знаком “-1”

По сегфолту кстати целиком могу лог выложить

По сегфолту кстати целиком могу лог выложить

Интересует стек трейс, который чуть ниже в логе.

2018.08.14 03:50:29.451454 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.451482 [ 223631 ] <Error> BaseDaemon: (from thread 223630) Received signal Segmentation fault (11). 2018.08.14 03:50:29.451488 [ 223631 ] <Error> BaseDaemon: Address: 0x50d8 2018.08.14 03:50:29.451492 [ 223631 ] <Error> BaseDaemon: Access: write. 2018.08.14 03:50:29.451498 [ 223631 ] <Error> BaseDaemon: Address not mapped to object. 2018.08.14 03:50:29.481747 [ 223631 ] <Error> BaseDaemon: 0. [0xbb070008] 2018.08.14 03:50:29.481783 [ 223631 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(DB::MemoryBlockInputStream::readImpl()+0x836) [0x4faa646] 2018.08.14 03:50:29.481795 [ 223631 ] <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.481805 [ 223631 ] <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::FilterBlockInputStream::readImpl()+0xa9) [0x51cfba9] 2018.08.14 03:50:29.481816 [ 223631 ] <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.481826 [ 223631 ] <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2e) [0x51cefde] 2018.08.14 03:50:29.481836 [ 223631 ] <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.481846 [ 223631 ] <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::PartialSortingBlockInputStream::readImpl()+0x2e) [0x520a7ce] 2018.08.14 03:50:29.481856 [ 223631 ] <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.481877 [ 223631 ] <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::l oop(unsigned long)+0x125) [0x4e81bc5] 2018.08.14 03:50:29.481895 [ 223631 ] <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>:: thread(MemoryTracker*, unsigned long)+0x219) [0x4e82479] 2018.08.14 03:50:29.481905 [ 223631 ] <Error> BaseDaemon: 11. /usr/bin/clickhouse-server() [0x938cc0f] 2018.08.14 03:50:29.481915 [ 223631 ] <Error> BaseDaemon: 12. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f8cfe0d4494] 2018.08.14 03:50:29.481937 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.481946 [ 223631 ] <Error> BaseDaemon: (from thread 223632) Received signal Segmentation fault (11). 2018.08.14 03:50:29.481953 [ 223631 ] <Error> BaseDaemon: Address: 0x30730 2018.08.14 03:50:29.481967 [ 223631 ] <Error> BaseDaemon: Access: read. 2018.08.14 03:50:29.481974 [ 223631 ] <Error> BaseDaemon: Address not mapped to object. 2018.08.14 03:50:29.505355 [ 223631 ] <Error> BaseDaemon: 0. [0xa690b002] 2018.08.14 03:50:29.505364 [ 223631 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(DB::MemoryBlockInputStream::readImpl()+0x836) [0x4faa646] 2018.08.14 03:50:29.505370 [ 223631 ] <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.505376 [ 223631 ] <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::FilterBlockInputStream::readImpl()+0xa9) [0x51cfba9] 2018.08.14 03:50:29.505381 [ 223631 ] <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.505386 [ 223631 ] <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2e) [0x51cefde] 2018.08.14 03:50:29.505392 [ 223631 ] <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.505397 [ 223631 ] <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::PartialSortingBlockInputStream::readImpl()+0x2e) [0x520a7ce] 2018.08.14 03:50:29.505402 [ 223631 ] <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::IProfiling

BlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.505410 [ 223631 ] <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::loop(unsigned long)+0x125) [0x4e81bc5] 2018.08.14 03:50:29.505418 [ 223631 ] <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x219) [0x4e82479] 2018.08.14 03:50:29.505422 [ 223631 ] <Error> BaseDaemon: 11. /usr/bin/clickhouse-server() [0x938cc0f] 2018.08.14 03:50:29.505427 [ 223631 ] <Error> BaseDaemon: 12. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f8cfe0d4494] 2018.08.14 03:50:29.505433 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.505439 [ 223631 ] <Error> BaseDaemon: (from thread 223633) Received signal Segmentation fault (11). 2018.08.14 03:50:29.505443 [ 223631 ] <Error> BaseDaemon: Address: 0x50d7 2018.08.14 03:50:29.505447 [ 223631 ] <Error> BaseDaemon: Access: write. 2018.08.14 03:50:29.505451 [ 223631 ] <Error> BaseDaemon: Address not mapped to object. 2018.08.14 03:50:29.528330 [ 223631 ] <Error> BaseDaemon: 0. [0x5210903f] 2018.08.14 03:50:29.528338 [ 223631 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(DB::MemoryBlockInputStream::readImpl()+0x836) [0x4faa646] 2018.08.14 03:50:29.528343 [ 223631 ] <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.528348 [ 223631 ] <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::FilterBlockInputStream::readImpl()+0xa9) [0x51cfba9] 2018.08.14 03:50:29.528353 [ 223631 ] <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.528358 [ 223631 ] <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2e) [0x51cefde] 2018.08.14 03:50:29.528364 [ 223631 ] <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.528369 [ 223631 ] <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::PartialSortingBlockInputStream::readImpl()+0x2e) [0x520a7ce] 2018.08.14 03:50:29.528374 [ 223631 ] <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.528386 [ 223631 ] <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::loop(unsigned long)+0x125) [0x4e81bc5] 2018.08.14 03:50:29.528396 [ 223631 ] <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x219) [0x4e82479] 2018.08.14 03:50:29.528402 [ 223631 ] <Error> BaseDaemon: 11. /usr/bin/clickhouse-server() [0x938cc0f] 2018.08.14 03:50:29.528406 [ 223631 ] <Error> BaseDaemon: 12. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f8cfe0d4494] 2018.08.14 03:50:29.528412 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.528418 [ 223631 ] <Error> BaseDaemon: (from thread 205) Received signal Segmentation fault (11). 2018.08.14 03:50:29.528422 [ 223631 ] <Error> BaseDaemon: Address: 0x1 2018.08.14 03:50:29.528426 [ 223631 ] <Error> BaseDaemon: Access: read. 2018.08.14 03:50:29.528430 [ 223631 ] <Error> BaseDaemon: Address not mapped to object. 2018.08.14 03:50:29.563819 [ 223631 ] <Error> BaseDaemon: 0. /usr/bin/clickhouse-server(tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::FreeList*, unsigned long, int)+0x11b) [0x5a698eb] 2018.08.14 03:50:29.563827 [ 223631 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(tcmalloc::ThreadCache::ListTooLong(tcmalloc::ThreadCache::FreeList*, unsigned long)+0x1c) [0x5a6998c] 2018.08.14 03:50:29.563833 [ 223631 ] <Error> Ba

seDaemon: 2. /usr/bin/clickhouse-server(tc_deletearray+0x369) [0x9406529] 2018.08.14 03:50:29.563838 [ 223631 ] <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::StorageMemory::drop()+0x1d1) [0x4fa6391] 2018.08.14 03:50:29.563850 [ 223631 ] <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::InterpreterDropQuery::executeToTable(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, DB::ASTDropQuery::Kind, bool, bool)+0x1102) [0x4e5ef02] 2018.08.14 03:50:29.563856 [ 223631 ] <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::InterpreterDropQuery::execute()+0x345) [0x4e61db5] 2018.08.14 03:50:29.563861 [ 223631 ] <Error> BaseDaemon: 6. /usr/bin/clickhouse-server() [0x4ef181b] 2018.08.14 03:50:29.563874 [ 223631 ] <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::executeQuery(DB::ReadBuffer&, DB::WriteBuffer&, bool, DB::Context&, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>)+0x116) [0x4ef29c6] 2018.08.14 03:50:29.563881 [ 223631 ] <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::HTTPHandler::processQuery(Poco::Net::HTTPServerRequest&, HTMLForm&, Poco::Net::HTTPServerResponse&, DB::HTTPHandler::Output&)+0x3147) [0x2dd2a37] 2018.08.14 03:50:29.563887 [ 223631 ] <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::HTTPHandler::handleRequest(Poco::Net::HTTPServerRequest&, Poco::Net::HTTPServerResponse&)+0x248) [0x2dd4b48] 2018.08.14 03:50:29.563893 [ 223631 ] <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(Poco::Net::HTTPServerConnection::run()+0x332) [0x58cce02] 2018.08.14 03:50:29.563898 [ 223631 ] <Error> BaseDaemon: 11. /usr/bin/clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x58c56af] 2018.08.14 03:50:29.563903 [ 223631 ] <Error> BaseDaemon: 12. /usr/bin/clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x16a) [0x58c5a8a] 2018.08.14 03:50:29.563909 [ 223631 ] <Error> BaseDaemon: 13. /usr/bin/clickhouse-server(Poco::PooledThread::run()+0x77) [0x5966e97] 2018.08.14 03:50:29.563915 [ 223631 ] <Error> BaseDaemon: 14. /usr/bin/clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x38) [0x5962d58] 2018.08.14 03:50:29.563919 [ 223631 ] <Error> BaseDaemon: 15. /usr/bin/clickhouse-server() [0x938cc0f] 2018.08.14 03:50:29.563924 [ 223631 ] <Error> BaseDaemon: 16. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f8cfe0d4494] 2018.08.14 03:50:29.563936 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.563942 [ 223631 ] <Error> BaseDaemon: (from thread 223634) Received signal Segmentation fault (11). 2018.08.14 03:50:29.563947 [ 223631 ] <Error> BaseDaemon: Address: 0x2db88f9 2018.08.14 03:50:29.563957 [ 223631 ] <Error> BaseDaemon: Access: write. 2018.08.14 03:50:29.563961 [ 223631 ] <Error> BaseDaemon: Attempted access has violated the permissions assigned to the memory area. 2018.08.14 03:50:29.563974 [ 223631 ] <Error> BaseDaemon: ######################################## 2018.08.14 03:50:29.563978 [ 223631 ] <Error> BaseDaemon: (from thread 223635) Received signal Illegal instruction (4). 2018.08.14 03:50:29.563983 [ 223631 ] <Error> BaseDaemon: Illegal operand. 2018.08.14 03:50:29.586460 [ 223631 ] <Error> BaseDaemon: 0. [0x74511000] 2018.08.14 03:50:29.586468 [ 223631 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(DB::MemoryBlockInputStream::readImpl()+0x836) [0x4faa646] 2018.08.14 03:50:29.586473 [ 223631 ] <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.586478 [ 223631 ] <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(DB::FilterBlockInputStream::readImpl()+0xa9) [0x51cfba9] 2018.08.14 03:50:29.586483 [ 223631 ] <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.586488 [ 223631 ] <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2e) [0x51cefde] 2018.08.14 03:50:2

9.586493 [ 223631 ] <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.586498 [ 223631 ] <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::PartialSortingBlockInputStream::readImpl()+0x2e) [0x520a7ce] 2018.08.14 03:50:29.586504 [ 223631 ] <Error> BaseDaemon: 8. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x4768cfa] 2018.08.14 03:50:29.586511 [ 223631 ] <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::loop(unsigned long)+0x125) [0x4e81bc5] 2018.08.14 03:50:29.586519 [ 223631 ] <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x219) [0x4e82479] 2018.08.14 03:50:29.586523 [ 223631 ] <Error> BaseDaemon: 11. /usr/bin/clickhouse-server() [0x938cc0f] 2018.08.14 03:50:29.586528 [ 223631 ] <Error> BaseDaemon: 12. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494) [0x7f8cfe0d4494]

Файлом если удобнее, иначе в несколько сообщений бьёт

По стек трейсу на первый взгляд непонятно, в чём проблема. Надо обсудить в личке, как отладить.

Добрый день, подскажите пожалуйста как оптимальнее вывести nested со структурой name/ value?? Чтобы в выводе был формат 1,1,1,1,1,[aaa:bbb,ccc:ddd], где aaa name bbb value

1,1,1,1,1 это значения из родительской таблицы

Ccc - name, ddd - value

Да вот это

нашел видео сегодня: https://www.youtube.com/watch?v=tf38TPvwjJ4&t=5s

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

Да, нужно использовать функцию argMax вместе с group by. Функцию anyLast использовать не советую, порядок строк в группах может быть недетерминированным.

Всем привет. Ищу разработчика, который сможет реализовать и запулить(и что бы приняли) функцию аналогичную функции lag в oracle. Мы когда-то делали на основе RunningDifferent, но не получилось реализовать для string, там как-то сложно получалось.

Всем привет. Ищу разработчика, который сможет реализовать и запулить(и что бы приняли) функцию аналогичную функции lag в oracle. Мы когда-то делали на основе RunningDifferent, но не получилось реализовать для string, там как-то сложно получалось.

Это можно сделать при помощи функции arrayMap.

добрый вечер, а можно ли в SummingTree использовать дату в WHERE, счетчики будут корректно показываться (без FINAL но с sum() и group by user_id)?

Да, можно. И where и prewhere.

Это можно сделать при помощи функции arrayMap.

Сделать можно и при помощи JOIN. Вопрос перфоманса и потребления оперативки. На табличке в несколько ТБ, arraymap\join заканчивается OOM.

Добрый вечер. Если честно так и не понял для чего нужен chproxy https://github.com/Vertamedia/chproxy Размазывает нагрузку на несколько нод кластера но все-равно через disturbed таблицу?

Добрый вечер. Если честно так и не понял для чего нужен chproxy https://github.com/Vertamedia/chproxy Размазывает нагрузку на несколько нод кластера но все-равно через disturbed таблицу?

Добрый! Мы постарались описать основные преимущества использования здесь - https://github.com/Vertamedia/chproxy#chproxy

Всем привет. Ищу разработчика, который сможет реализовать и запулить(и что бы приняли) функцию аналогичную функции lag в oracle. Мы когда-то делали на основе RunningDifferent, но не получилось реализовать для string, там как-то сложно получалось.

А так можно?

Попробую кратко описать юзкейсы: - равномерно распределять вставки по шардам кластера без использования дистрибьютед таблицы. chproxy каждый раз выбирает следующий наименее загруженный "живой" шард (least-loaded + round-robin) - равномерно распределять нагрузки при чтении из кластера - кешировать ответы от КХ (отлично подходит для систем визуализации вроде Grafana) - лимитировать доступ к кластеру по пользователям или адресам - контролировать кол-во одновременно выполняющихся запросов и максимальное время их выполнения - избежать перегрузки кластера при аномальном повышении кол-ва запросов путем выстроения их в очередь - автоматическая выписка https сертификатов

А так можно?

В смысле? Я ищу разработчика за деньги, конечно же. Который сможет реализовать и довести задачу до пул реквеста. По деньгам не обижу. :)

Попробую кратко описать юзкейсы: - равномерно распределять вставки по шардам кластера без использования дистрибьютед таблицы. chproxy каждый раз выбирает следующий наименее загруженный "живой" шард (least-loaded + round-robin) - равномерно распределять нагрузки при чтении из кластера - кешировать ответы от КХ (отлично подходит для систем визуализации вроде Grafana) - лимитировать доступ к кластеру по пользователям или адресам - контролировать кол-во одновременно выполняющихся запросов и максимальное время их выполнения - избежать перегрузки кластера при аномальном повышении кол-ва запросов путем выстроения их в очередь - автоматическая выписка https сертификатов

Спасибо

в чем фишка не использовать дистрибьютед таблицы ?

в чем фишка не использовать дистрибьютед таблицы ?

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

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

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

А еще ClickHouse используют в xHamster :)

Если об этом написано где-нибудь в таком месте, на которое можно сослаться из википедии (чат не подходит), то можно добавить :)

Не увидел там в списке компаний Сми2 которые используют КХ :) может плохо искал

Добавил.

Кто-то сталкивался с тем, что INSERT ... SELECT прочитывает примерно 30-40% исходной таблицы и вставляет около того, не выводя ошибок ?

Кто-то сталкивался с тем, что INSERT ... SELECT прочитывает примерно 30-40% исходной таблицы и вставляет около того, не выводя ошибок ?

Может быть какие-то лимиты срабатывают? Проверьте SELECT * FROM system.settings WHERE changed = 1

Может быть какие-то лимиты срабатывают? Проверьте SELECT * FROM system.settings WHERE changed = 1

Да, есть измененные: │ max_query_size │ 10485760 │ 1 │ │ use_uncompressed_cache │ 0 │ 1 │ │ background_pool_size │ 50 │ 1 │ │ │ background_schedule_pool_size │ 24 │ 1 │ │ │ load_balancing │ random │ 1 │ │ │ max_rows_to_read │ 600000000000 │ 1 │ │ │ max_execution_time │ 60 │ 1 │ │ │ timeout_overflow_mode │ break │ 1 │ │ │ max_ast_elements │ 1000000 │ 1 │ │ │ max_memory_usage │ 40000000000 │ 1 │

что может ограничивать? max_query_size ?