11 вечера ?

это да ?

в итоге получается SELECT date, runningAccumulate(state) FROM (SELECT date, countState() AS state FROM table GROUP BY date ORDER BY date)

круто! спасибо огромное! а то весь мозг сломал себе уже)

в CH можно вычислить моду?

Привет. Где можно больше прочитать про сжатие данных в ClickHouse? Например, у меня есть колонка, в которой храниться unix timestamp в миллисекундах, при вставке значение монотонно увеличивается. Может ли ClickHouse его эффективно сжать? Как?

любой алгоритм компрессии может

за счет сжатия повторяющихся частей

в CH можно вычислить моду?

С помощью GROUP BY + ORDER BY её можно вычислить везде

@kshvakov понятно, думал вдруг есть более интереснее решение

Это понятно. Вопросы в другом. 1. Как узнать что он применяется? Как это увидеть? Как узнать степень сжатия? 2. Есть ли возможность указать специфический алгоритм? "Любой алгоритм компрессии" будет не так эффективен в этом случае, как специфический на delta encoding.

компрессия указывается в конфиге zstd за счет FSE сожмет не особо хуже всех этих поделок с delta encoding, а гемора будет намного меньше кмк

http://www.vldb.org/pvldb/vol8/p1816-teller.pdf Эта "поделка" от Facebook'а (авторов zstd, к слову) сжимает timestamp'ы гораздо лучше, и без "гемора".

я думал, речь идет о собственном выборе более удобной точки отсчета

http://www.vldb.org/pvldb/vol8/p1816-teller.pdf Эта "поделка" от Facebook'а (авторов zstd, к слову) сжимает timestamp'ы гораздо лучше, и без "гемора".

Ты про гориллу?

да, это про неё пейпер

ну и Facebook - это не авторы zstd, а примазавшиеся

Да, есть даже простые реализации на го

Которые наверное не сложно на плюсы переписать

компрессия указывается в конфиге zstd за счет FSE сожмет не особо хуже всех этих поделок с delta encoding, а гемора будет намного меньше кмк

В 3 раза хуже

писал zstd бешеный француз Yan Collet (который до этого написал lz4)

https://github.com/dgryski/go-tsz

ну и Facebook - это не авторы zstd, а примазавшиеся

https://github.com/facebook/zstd – основной коммитер и есть Ян. По всем внешним признакам, это Facebook

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

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

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

У меня именно так

не уверен, что ей не сплохеет, если таймстамп ВНЕЗАПНО уменьшится по сравнению с текущим (это надо статью внимательно читать)

Сжатие пострадает, но данные не поломаются

Ну и сжимать-то можно (и, наверное, нужно) позже, при слиянии и сортировке

> Как узнать что он применяется? Как это увидеть? Как узнать степень сжатия? Вот этот вопрос остался. Я посмотрел все метрики, но как посчитать текущую степень сжатия таблицы или куска так и не понял

Доброе утро! Сколько должно быть в среднем блоков в фоне слияния

у меня 74 это нормально?

не уверен, что ей не сплохеет, если таймстамп ВНЕЗАПНО уменьшится по сравнению с текущим (это надо статью внимательно читать)

Сжатие будет деградировать, в худшем случаи вроде даже оверхед будет некоторый

я б посоветовал почитать реализацию на Го, она маленькая, простая

и работает

оно кстати работает и для float64 и для пар uint64/float64, uint32/float64

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

Ребят, по поводу replacing merge tree вопрос. Если делать апдейт по одной строке, то я так полагаю эта операция будет крайне дешевая для КХ т.к. фактически партиция в которой строка лежит не меняется?

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

Ребят, по поводу replacing merge tree вопрос. Если делать апдейт по одной строке, то я так полагаю эта операция будет крайне дешевая для КХ т.к. фактически партиция в которой строка лежит не меняется?

Делать инсерт по одной строке крайне нерекомендуется. Минимум по 1к

Делать инсерт по одной строке крайне нерекомендуется. Минимум по 1к

Речь идет не о MergeTree, а именно о ReplacingMergeTree? Или разницы нет? Т.е. даже на апдейт по хорошему собирать например 1к строк и закидывать?

Просто не факт, что у меня будет такой поток данных на апдейт, я при всем желании больше 1к строк не выжму )

Да и строк у меня там будет не очень много

Речь идет не о MergeTree, а именно о ReplacingMergeTree? Или разницы нет? Т.е. даже на апдейт по хорошему собирать например 1к строк и закидывать?

Так это же одно семейство движков. А по поводу вставки по одной строке - пробуйте, экспериментируйте

Речь идет не о MergeTree, а именно о ReplacingMergeTree? Или разницы нет? Т.е. даже на апдейт по хорошему собирать например 1к строк и закидывать?

чем больше батч тем проще жить базе

мне кажется нужно только думать не в масштабах строк, а в масштабах "количество INSERT'ов в секунду"

а сколько строк - да сколько получится за это время

если я правильно понимаю, то проблема не в малом числе строк, а в большом количестве инсертов

если я правильно понимаю, то проблема не в малом числе строк, а в большом количестве инсертов

угу

мы решили у себя этой тулзой: https://github.com/nikepan/clickhouse-bulk

а точнее в слиянии большого количества кусков

и как я понимаю, фактически 1 инсерт запрос делает 1 кусок

поэтому я выше и предложил подходить к вопросу как "инсертов в секунду"

а не "инсерты батчами по N строк"

Ладно, подумаю как батчить все это добро. Просто по этим данным будет очень много агрегации проводиться в дальнейшем, ни mysql ни postgres с этим не справятся ) Данные нужны быстро, а данные из серии "общее время в системе" и пр., которое считается в фоне другими процессами

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

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

https://github.com/yandex/ClickHouse/issues/838

https://github.com/yandex/ClickHouse/issues/838

ага, я там даже в какой-то момент коммент оставлял

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

было раз, попробуй сделать один инсерт, потом почему-то репликация начинает работать

Не очень понял... Как это поможет стянуть определение таблицы с другой ноды?

Я имею в виду — есть ли способ получить определение таблицы с одной из других нод, чтобы не создавать её руками.

а, это вроде как невозможно

мы через salt + liquebase накатываем

Ну у нас сейчас схема на s3 лежит и после alter-ов её надо не забывать менять, ищем более вменяемый способ :)

Я имею в виду — есть ли способ получить определение таблицы с одной из других нод, чтобы не создавать её руками.

show create table <table_name>;

И еще посмотрите в https://clickhouse.yandex/docs/en/single/index.html#distributed-ddl-queries-on-cluster-section

Ну с distributed насколько я понимаю нужно всё равно иметь local таблицу, если нода была в кластере и умерла, а после поднялась на замену пустая, то разве distributed закинет на неё все DDL исполнявшиеся?

Как можно "полечить" ошибку ? 2017.08.22 12:38:37.150005 [ 19 ] <Error> executeQuery: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Assertion violation: !_path.empty() in file "/home/robot-metrika-test/jenkins/workspace/clickhouse-packages-build/sources/contrib/libpoco/Foundation/src/File_UNIX.cpp", line 370, e.what() = Assertion violation (from 192.168.198.9:47588) (in query: INSERT INTO events

Show create table судя по всему хорошее решение, он возвращает схему с учётом alter-ов, насколько я вижу. (Хотя в документации сказано, что возвращает query, которым была создАНА таблица)

Ошибка Assertion violation: !_path.empty() in file пока возникает только если запись идет с уделенной машины из другого ДЦ, локальные воркеры пишут (есть подозрение что началось все после обновление до последней версии). Это все немного печально, т.к. данные не доставляются

С какой и до какой версии вы обновлялись?

локальные воркеры это в смысле запущенные на локалхосте?

c 54245 до 54276

да, те что на локалхост

Добрый день. Версия клика 1.1.54276. Упал сервер с ошибкой 2017.08.22 13:15:18.167509 [ 161 ] <Error> BaseDaemon: (from thread 148) Terminate called without an active exception 2017.08.22 13:15:18.167526 [ 161 ] <Error> BaseDaemon: ######################################## 2017.08.22 13:15:18.167543 [ 161 ] <Error> BaseDaemon: (from thread 148) Received signal Aborted (6). 2017.08.22 13:15:18.381555 [ 161 ] <Error> BaseDaemon: 0. /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38) [0x7f8912317428] 2017.08.22 13:15:18.381569 [ 161 ] <Error> BaseDaemon: 1. /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7f891231902a] 2017.08.22 13:15:18.381576 [ 161 ] <Error> BaseDaemon: 2. clickhouse-server() [0x11cdd5d] 2017.08.22 13:15:18.381600 [ 161 ] <Error> BaseDaemon: 3. clickhouse-server(__cxxabiv1::__terminate(void (*)())+0x6) [0x37b17d6] 2017.08.22 13:15:18.381607 [ 161 ] <Error> BaseDaemon: 4. clickhouse-server() [0x37b1821] 2017.08.22 13:15:18.381617 [ 161 ] <Error> BaseDaemon: 5. clickhouse-server(ThreadPool::ThreadPool(unsigned long)+0x637) [0x300a487] 2017.08.22 13:15:18.381642 [ 161 ] <Error> BaseDaemon: 6. clickhouse-server(DB::MergingAggregatedMemoryEfficientBlockInputStream::MergingAggregatedMemoryEfficientBlockInputStream(std::vector<std::shared_ptr<DB::IBlockInputStream>, std::allocator<std::shared_ptr<DB::IBlockInputStream> > >, DB::Aggregator::Params const&, bool, unsigned long, unsigned long)+0xe58) [0x2f080a8] 2017.08.22 13:15:18.381653 [ 161 ] <Error> BaseDaemon: 7. clickhouse-server(DB::InterpreterSelectQuery::executeMergeAggregated(bool, bool)+0x174) [0x2e7e364] 2017.08.22 13:15:18.381663 [ 161 ] <Error> BaseDaemon: 8. clickhouse-server(DB::InterpreterSelectQuery::executeSingleQuery()+0x1a66) [0x2e81266] 2017.08.22 13:15:18.381671 [ 161 ] <Error> BaseDaemon: 9. clickhouse-server(DB::InterpreterSelectQuery::executeWithoutUnion()+0x58) [0x2e819e8] 2017.08.22 13:15:18.381679 [ 161 ] <Error> BaseDaemon: 10. clickhouse-server(DB::InterpreterSelectQuery::executeFetchColumns()+0x16dc) [0x2e839ec] 2017.08.22 13:15:18.381687 [ 161 ] <Error> BaseDaemon: 11. clickhouse-server(DB::InterpreterSelectQuery::executeSingleQuery()+0x32) [0x2e7f832] 2017.08.22 13:15:18.381695 [ 161 ] <Error> BaseDaemon: 12. clickhouse-server(DB::InterpreterSelectQuery::executeWithoutUnion()+0x1c5) [0x2e81b55] 2017.08.22 13:15:18.381703 [ 161 ] <Error> BaseDaemon: 13. clickhouse-server(DB::InterpreterSelectQuery::execute()+0x31) [0x2e81bb1] 2017.08.22 13:15:18.381710 [ 161 ] <Error> BaseDaemon: 14. clickhouse-server() [0x29c099c] 2017.08.22 13:15:18.381726 [ 161 ] <Error> BaseDaemon: 15. 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&)>)+0x1eb) [0x29c1b8b] 2017.08.22 13:15:18.381740 [ 161 ] <Error> BaseDaemon: 16. clickhouse-server(DB::HTTPHandler::processQuery(Poco::Net::HTTPServerRequest&, HTMLForm&, Poco::Net::HTTPServerResponse&, DB::HTTPHandler::Output&)+0x1efc) [0x10f856c] 2017.08.22 13:15:18.381750 [ 161 ] <Error> BaseDaemon: 17. clickhouse-server(DB::HTTPHandler::handleRequest(Poco::Net::HTTPServerRequest&, Poco::Net::HTTPServerResponse&)+0x32b) [0x10fa61b] 2017.08.22 13:15:18.381758 [ 161 ] <Error> BaseDaemon: 18. clickhouse-server(Poco::Net::HTTPServerConnection::run()+0x2fe) [0x3421eee] 2017.08.22 13:15:18.381766 [ 161 ] <Error> BaseDaemon: 19. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x3416fff] 2017.08.22 13:15:18.381774 [ 161 ] <Error> BaseDaemon: 20. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x13b) [0x341d43b] 2017.08.22 13:15:18.381785 [ 161 ] <Error> BaseDaemon: 21. clickhouse-server(Poco::PooledThread::run()+0xb7) [0x3688287] 2017.08.22 13:15:18.381792 [ 161 ] <Error> BaseDaemon: 22. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x36542c5] 2017.08.22 13:15:18.381804 [ 161 ] <Error> BaseDaemon: 23. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f8912dc76ba]

При этом на кластере (5 шард) был запущен запрос, который съел 80% памяти на сервере, где упал сервер. Свободной памяти было еще 40 гиг. Я верно понимаю что это упал из за фейла при мердже? Сужу по MergingAggregatedMemoryEfficientBlockInputStream

Как с этим в теории можно бороться? Сейчас высталены лимиты по max_threads чуть больше кол-ва ядер. Лимиты по памяти на запрос, выставлены в рамках чуть меньше объема оперативки

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

но повторюсь, что память до конца не выело

Так же, после обновления на новую версию

перестали компилиться запросы

Пример 2017.08.22 13:40:09.525391 [ 28 ] <Error> Compiler: Code: 0, e.displayText() = DB::Exception: Cannot compile code: LD_LIBRARY_PATH=/usr/share/clickhouse/bin/ /usr/share/clickhouse/bin/clang -B /usr/share/clickhouse/bin/ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_GLIB CXX_USE_CXX11_ABI=1 -pipe -msse4.1 -msse4.2 -mpopcnt -std=gnu++1z -fno-omit-frame-pointer -Wall -Wnon-virtual-dtor -Werror -O3 -DNDEBUG -x c++ -march=native -shared -fPIC -fvisibility=hidden -fno-implement-in lines -isystem /usr/share/clickhouse/headers/usr/local/include/ -isystem /usr/share/clickhouse/headers/usr/include/ -isystem /usr/share/clickhouse/headers/usr/include/c++/*/ -isystem /usr/share/clickhouse/heade rs/usr/include/x86_64-linux-gnu/ -isystem /usr/share/clickhouse/headers/usr/include/x86_64-linux-gnu/c++/*/ -isystem /usr/share/clickhouse/headers/usr/local/lib/clang/*/include/ -I /usr/share/clickhouse/headers/ dbms/src/ -I /usr/share/clickhouse/headers/contrib/libcityhash/include/ -I /usr/share/clickhouse/headers/contrib/libdouble-conversion -I /usr/share/clickhouse/headers/contrib/libpoco/Foundation/include/ -I /usr/ share/clickhouse/headers/contrib/libboost/boost_1_62_0/ -I /usr/share/clickhouse/headers/libs/libcommon/include/ -include /usr/share/clickhouse/headers/dbms/src/Interpreters/SpecializedAggregator.h -o /opt/click house/build//15056633568159347706_6876590312518736700.so.tmp /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp 2>&1 || echo Exit code: $? /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:5:70: error: expected unqualified-id decltype(AggregatedDataVariants::key64)::element_type, TypeList<DB::(anonymous namespace)::GroupArrayGeneralListImpl<DB::(anonymous namespace)::NodeGeneral, false»? ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:5:71: error: use of undeclared identifier 'anonymous' decltype(AggregatedDataVariants::key64)::element_type, TypeList<DB::(anonymous namespace)::GroupArrayGeneralListImpl<DB::(anonymous namespace)::NodeGeneral, false»? ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:5:167: error: expected a type decltype(AggregatedDataVariants::key64)::element_type, TypeList<DB::(anonymous namespace)::GroupArrayGeneralListImpl<DB::(anonymous namespace)::NodeGeneral, false»? ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:7:2: error: unknown type name 'AggregateColumns' AggregateColumns &, const Sizes &, StringRefs &, bool, AggregateDataPtr) const; ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:4:27: error: expected unqualified-id template void Aggregator::executeSpecialized< ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:22:71: error: expected unqualified-id decltype(AggregatedDataVariants::key64)::element_type, TypeList<DB::(anonymous namespace)::GroupArrayGeneralListImpl<DB::(anonymous namespace)::NodeGeneral, false»? ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:22:72: error: use of undeclared identifier 'anonymous' decltype(AggregatedDataVariants::key64)::element_type, TypeList<DB::(anonymous namespace)::GroupArrayGeneralListImpl<DB::(anonymous namespace)::NodeGeneral, false»? ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:22:168: error: expected a type

decltype(AggregatedDataVariants::key64)::element_type, TypeList<DB::(anonymous namespace)::GroupArrayGeneralListImpl<DB::(anonymous namespace)::NodeGeneral, false»? ^ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:23:3: error: type-id cannot have a name method, arena, rows, key_columns, aggregate_columns, key_sizes, keys, no_more_keys, overflow_row); ^~~~~~ /opt/clickhouse/build//15056633568159347706_6876590312518736700.cpp:23:9: error: expected ')' method, arena, rows, key_columns, aggregate_columns, key_sizes, keys, no_more_ ...

Небольшая просьба - стены текста лучше в чат не кидать ?Лучше создайте issue

Это да, но если будет очередное падение тогда можно отловить условие воспроизведения. И на основе создать баг. Сейчас это просто стектрейс, который может даст подсказку куда рыть. Например, что при обновлении нужно также обновить gcc или устнановить новую версию... или если упал клик при мердже, когда было недостаточно памяти, то уменьшить потребление памяти в запросах и установить квоты. Цель была в этом. Но по стектрейсу идей нет?

судя по стектрейсу создаётся тредпул со слишком большим количеством потоков

В общем, удаленный воркер писал у нас в Distributed таблицу чтоб данные размазать, переключили на обычную ошибка с Assertion violation: !_path.empty() in file пропала

судя по стектрейсу создаётся тредпул со слишком большим количеством потоков

О, это может быть. В целом, Max Treads можно выставлять больше кол-ва ядер?

иногда кликхаус возвращает 404 без объяснения причин на вполне, казалось бы, валидный запрос версия 1.1.54276

к примеру

select target_host, metric_name from lalala where job_id=1499707 group by target_host, metric_name order by target_host, metric_name FORMAT JSONCompact

not found (404) что?

чего он не нашел?