Одноядерный

Это не так )

Ну как хотите, вам же страдать

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

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

а вот подскажите, есть ряд данных, отсортированных по убыванию, мне нужно ответить на вопрос – "сколько элементов нужно чтобы набрать 95% от суммы", это что-то вроде topK, только оно бы выглядело что-то типа topKwithQuantile(0.95)(...) или если бы topK(..)(...) возвращал бы еще дополнительно массив процентов.

можно конечно отсечь хвосты HAVING CNT/SUMM>1.5, но может быть есть еще варианты

Всем привет. Где-то видел, что есть возможность почистить содежимое колонок в определнные партициях. У нас сейчас задача, для событий старше N месяцев, грохнуть 2 колонки, которые занимают очень много места. Пересоздавать таблицу не вариант(объем 2ТБ). В доке что-то найти не могу=(

https://groups.google.com/d/msg/clickhouse/kkZEtkTpjPg/D5gAn6j_AAAJ Нашел сообщение Алексея, в котором он рассказывал об этом. Удалось ли реализовать в итоге?

Всем привет. Где-то видел, что есть возможность почистить содежимое колонок в определнные партициях. У нас сейчас задача, для событий старше N месяцев, грохнуть 2 колонки, которые занимают очень много места. Пересоздавать таблицу не вариант(объем 2ТБ). В доке что-то найти не могу=(

Добавить новые колонки, перелить в них нужные данные, переименовать?

Привет, где почитать-послушать можно про тюнинг производительности в разрезе настройки количество коннешенов итд

Всем привет. Где-то видел, что есть возможность почистить содежимое колонок в определнные партициях. У нас сейчас задача, для событий старше N месяцев, грохнуть 2 колонки, которые занимают очень много места. Пересоздавать таблицу не вариант(объем 2ТБ). В доке что-то найти не могу=(

Есть ALTER TABLE T DROP COLUMN C IN PARTITION part_name

Это получается недокументированная фича?

Прадон, не drop, а CLEAR

Да, нет в документации

Пример ALTER TABLE Reports CLEAR COLUMN EventTime IN PARTITION 201804

а точно in? или from partition?

И еще вопрос, наскольько это стабильно?

Не страшно на боевую табличку натравливать?

Привет, где почитать-послушать можно про тюнинг производительности в разрезе настройки количество коннешенов итд

Соединений нужно держать по возможности меньше. По "тюнингу" там сильно крутить нечего, они и так пытается все заиспользовать

И еще вопрос, наскольько это стабильно?

Стабильно, мы с этим живем, есть одно "НО" - после CLEAR для SummingMergeTree для этой партиции не работают мержи, если критично то можно сделать DETACH/ATTACH, чуть позже поправлю или это сделает кто-то из Яндекс, мы об этом говорили

а точно in? или from partition?

Точно, вот тут есть пример https://github.com/kshvakov/ClickHouse-CPP-Meetup#summingmergetree

Стабильно, мы с этим живем, есть одно "НО" - после CLEAR для SummingMergeTree для этой партиции не работают мержи, если критично то можно сделать DETACH/ATTACH, чуть позже поправлю или это сделает кто-то из Яндекс, мы об этом говорили

Мы summing не используем, так что все ок:) Спасибо!

Еще, после CLEAR он физически удаляет ее с диска и отдает то что было прописано в DEFAULT, поэтому если там было что-то вроде DEFAULT now() - всегда будет новое значение от выражения функции

Подскажите, пожалуйста, как установить ClickHouse на MacOS? Использовал инструкцию по https://clickhouse.yandex/docs/en/development/build_osx/ Около часа все компилировалось из исходников, а что дальше делать не понимаю. Список файлов в директории после компиляции: .clang-format .editorconfig .git .gitattributes .github .gitignore .gitlab-ci.yml .gitmodules .travis.yml .vimrc AUTHORS CHANGELOG.md CHANGELOG_RU.md CMakeLists.txt CONTRIBUTING.md LICENSE MacOS.md README.md build cmake contrib copy_headers.sh dbms debian docker docker-compose.yml docs format.sh format_sources libs release release_lib.sh utils website

build/dbms/src/Server/clickhouse-client build/dbms/src/Server/clickhouse-server

Подскажите, пожалуйста, как установить ClickHouse на MacOS? Использовал инструкцию по https://clickhouse.yandex/docs/en/development/build_osx/ Около часа все компилировалось из исходников, а что дальше делать не понимаю. Список файлов в директории после компиляции: .clang-format .editorconfig .git .gitattributes .github .gitignore .gitlab-ci.yml .gitmodules .travis.yml .vimrc AUTHORS CHANGELOG.md CHANGELOG_RU.md CMakeLists.txt CONTRIBUTING.md LICENSE MacOS.md README.md build cmake contrib copy_headers.sh dbms debian docker docker-compose.yml docs format.sh format_sources libs release release_lib.sh utils website

есть вот такой репозиторий https://github.com/arduanov/homebrew-clickhouse

Подскажите, пожалуйста, как установить ClickHouse на MacOS? Использовал инструкцию по https://clickhouse.yandex/docs/en/development/build_osx/ Около часа все компилировалось из исходников, а что дальше делать не понимаю. Список файлов в директории после компиляции: .clang-format .editorconfig .git .gitattributes .github .gitignore .gitlab-ci.yml .gitmodules .travis.yml .vimrc AUTHORS CHANGELOG.md CHANGELOG_RU.md CMakeLists.txt CONTRIBUTING.md LICENSE MacOS.md README.md build cmake contrib copy_headers.sh dbms debian docker docker-compose.yml docs format.sh format_sources libs release release_lib.sh utils website

А вам его нужно просто установить или вы его хотите именно собирать под MacOS? Если просто поставить то, на данный момент, лучшим решением будет Docker.

стандартный докер из docker hub нередко падает на маке

по кр мере у меня

а какие есть подводные камни использования таблицы как словаря вместо многоэтажных USING?

стандартный докер из docker hub нередко падает на маке

Может быть, у меня последний год работал достаточно стабильно

а какие есть подводные камни использования таблицы как словаря вместо многоэтажных USING?

В словаре может, внезапно, не оказаться данных

потому что они еще не доехали?

потому что они еще не доехали?

Да, может быть такое.

стандартный докер из docker hub нередко падает на маке

как бы скорее всего это проблема их (ребят из докера) сборки линукса, потому что я с дефолтным образом не видел проблем

потому что они еще не доехали?

Можно использовать cache размещение и он будет бегать за теми что нет в памяти, но этот способ не очень эффективен

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

вообще если бы еще был механизм описания словарей из клиента, а не из файлика – это было бы тотал перфекшн

насколько я помню такая задача была

Может быть, у меня последний год работал достаточно стабильно

сколько памяти отводили под докер?

Друзья, всем привет! Подскажите, пожалуйста, может кто сталкивался. Есть кластер, 8 нод - 4 щарды по 2 реплике в шарде. Переливали данные из старого кликхаус кластера в новый. У кластера внутренняя выделенная сетка. В общем при записи накопилось куча данных в table_name_distributed - были таймауты по вставке в другие ноды. Сейчас судя по логам кликхаус пытается их переотправить, но периодически умирает с Timeout: 2018.05.21 11:15:05.981436 [ 98 ] <Error> ping_event_distributed.Distributed.DirectoryMonitor: Code: 209, e.displayText() = DB::NetException: Timeout exceeded while writing to socket (172.16.0.105:9000), e.what() = DB::NetException, Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x15) [0x84eb065] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x21) [0x2ccbe01] 2. /usr/bin/clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x827) [0x85169b7] 3. /usr/bin/clickhouse-server() [0x851adf1] 4. /usr/bin/clickhouse-server(DB::Connection::sendPreparedData(DB::ReadBuffer&, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x548) [0x7f582d8] 5. /usr/bin/clickhouse-server(DB::RemoteBlockOutputStream::writePrepared(DB::ReadBuffer&, unsigned long)+0x3d) [0x803ad6d] 6. /usr/bin/clickhouse-server(DB::StorageDistributedDirectoryMonitor::processFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0xf0) [0x7e6d3f0] 7. /usr/bin/clickhouse-server(DB::StorageDistributedDirectoryMonitor::findFiles()+0x16f) [0x7e6ed3f] 8. /usr/bin/clickhouse-server(DB::StorageDistributedDirectoryMonitor::run()+0x94) [0x7e6f324] 9. /usr/bin/clickhouse-server() [0x8dd397e] 10. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76b9) [0x7ff04a35d6b9] 11. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6c) [0x7ff049b8641c] На ноде 172.16.0.105 не вижу никаких проблем, по dmesg и прчим нетстатам тоже все ок. Нагрузки нет, LA порядка 0.5 на 24 ядра. Есть мысли куда копнуть? Грешу на сеть, но что-то не вижу никаких явных проблем с ней ? Благодарю!

сколько памяти отводили под докер?

У меня все крутилось на стареньком Air с 4Gb памяти

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

Обновил кликхаус до 1.1.54381 и наступил на то, что запрос SELECT sum(data_compressed_bytes) AS data_compressed, sum(data_uncompressed_bytes) AS data_uncompressed FROM system.parts_columns WHERE active = 1; стал выдавать значения, не соответствующие действительности. Где-то этак на порядок.

Ну то есть, данных лежит 100Гб, а data_compressed - порядка полутора Тб.

Пока заменил таблицу на parts, но непонятно, это так и должно быть или я изначально не туда смотрел?

Доброго времени суток, после чтения чата так и не понял что лучше для высокой производительности : - 1 машина - 1 инстанс или - 1 машина - много инстансов

первое

Нет смысла во втором

Доброго времени суток, после чтения чата так и не понял что лучше для высокой производительности : - 1 машина - 1 инстанс или - 1 машина - много инстансов

Общий случай - КХ способен утилизировать все ресурсы машины. Частные случаи разные

Спасибо!

Друзья, всем привет! Подскажите, пожалуйста, может кто сталкивался. Есть кластер, 8 нод - 4 щарды по 2 реплике в шарде. Переливали данные из старого кликхаус кластера в новый. У кластера внутренняя выделенная сетка. В общем при записи накопилось куча данных в table_name_distributed - были таймауты по вставке в другие ноды. Сейчас судя по логам кликхаус пытается их переотправить, но периодически умирает с Timeout: 2018.05.21 11:15:05.981436 [ 98 ] <Error> ping_event_distributed.Distributed.DirectoryMonitor: Code: 209, e.displayText() = DB::NetException: Timeout exceeded while writing to socket (172.16.0.105:9000), e.what() = DB::NetException, Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x15) [0x84eb065] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x21) [0x2ccbe01] 2. /usr/bin/clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x827) [0x85169b7] 3. /usr/bin/clickhouse-server() [0x851adf1] 4. /usr/bin/clickhouse-server(DB::Connection::sendPreparedData(DB::ReadBuffer&, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x548) [0x7f582d8] 5. /usr/bin/clickhouse-server(DB::RemoteBlockOutputStream::writePrepared(DB::ReadBuffer&, unsigned long)+0x3d) [0x803ad6d] 6. /usr/bin/clickhouse-server(DB::StorageDistributedDirectoryMonitor::processFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0xf0) [0x7e6d3f0] 7. /usr/bin/clickhouse-server(DB::StorageDistributedDirectoryMonitor::findFiles()+0x16f) [0x7e6ed3f] 8. /usr/bin/clickhouse-server(DB::StorageDistributedDirectoryMonitor::run()+0x94) [0x7e6f324] 9. /usr/bin/clickhouse-server() [0x8dd397e] 10. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76b9) [0x7ff04a35d6b9] 11. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6c) [0x7ff049b8641c] На ноде 172.16.0.105 не вижу никаких проблем, по dmesg и прчим нетстатам тоже все ок. Нагрузки нет, LA порядка 0.5 на 24 ядра. Есть мысли куда копнуть? Грешу на сеть, но что-то не вижу никаких явных проблем с ней ? Благодарю!

А на другой ноде в это время вижу такой exception, что логично, кстати: 2018.05.21 11:55:47.268405 [ 142 ] <Error> executeQuery: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception (from 172.16.0.101:34918) Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x15) [0x84eb065] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x21) [0x2ccbe01] 2. /usr/bin/clickhouse-server(DB::CompressedReadBufferBase::readCompressedData(unsigned long&, unsigned long&)+0x8fd) [0x84f7e5d] 3. /usr/bin/clickhouse-server(DB::CompressedReadBuffer::nextImpl()+0x32) [0x84f7022] 4. /usr/bin/clickhouse-server() [0x7652d44] 5. /usr/bin/clickhouse-server(DB::NativeBlockInputStream::readData(DB::IDataType const&, DB::IColumn&, DB::ReadBuffer&, unsigned long, double)+0xf7) [0x75f7dd7] 6. /usr/bin/clickhouse-server(DB::NativeBlockInputStream::readImpl()+0x966) [0x75fae86] 7. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x259) [0x75f5c49] 8. /usr/bin/clickhouse-server(DB::TCPHandler::receiveData()+0x83) [0x2cda183] 9. /usr/bin/clickhouse-server(DB::TCPHandler::receivePacket()+0xcc) [0x2cdb67c] 10. /usr/bin/clickhouse-server(DB::TCPHandler::readData(DB::Settings const&)+0x1c2) [0x2cdbb42] 11. /usr/bin/clickhouse-server(DB::TCPHandler::processInsertQuery(DB::Settings const&)+0x205) [0x2cdbee5] 12. /usr/bin/clickhouse-server(DB::TCPHandler::runImpl()+0x476) [0x2cdc566] 13. /usr/bin/clickhouse-server(DB::TCPHandler::run()+0x2a) [0x2cdd3ba] 14. /usr/bin/clickhouse-server(Poco::Net::TCPServerConnection::start()+0xe) [0x86d53de] 15. /usr/bin/clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x169) [0x86d57b9] 16. /usr/bin/clickhouse-server(Poco::PooledThread::run()+0x76) [0x8776976] 17. /usr/bin/clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x37) [0x8772b87] 18. /usr/bin/clickhouse-server() [0x8dd397e] 19. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76b9) [0x7fb9157d06b9] 20. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6c) [0x7fb914ff941c] Прогнал сетку iperf'ом - вроде все ок, 830 mbit/sec выдает.. Есть идеи почему еще таймаут выскакивать может?

Посмотрите в ифконфиге ошибки на интерфейсе

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

Да, уже делал, с пингами все ок, как и с iperf'ом. На интерфейсе висит пара дропов, но они не увеличиваются при таймаутах в кликхаусе. Поставил watchdog туда же до кучи, других ошибок или ресетов нет. Буду наблдюдать.

Коллеги, подскажите, пожалуйста, что нужно сделать чтобы избежать такой ошибки: [160] ClickHouse exception, code: 160, host: groot-clickhouse.vcp.digitalaccess.ru, port: 80; Code: 160, e.displayText() = DB::Exception: Pattern application proves too difficult, exceeding max iterations (1000000), e.what() = DB::Exceptionпри использовании функций sequenceCount и sequenceMatch. Можно где-то увеличить кол-во итераций? или может что-то другое сделать..? при этом сами условия выглядят просто: sequenceCount('(?1).*(?2)(?t>=300).*(?3)')(datetime_server , ui_type='description' , ui_type='payment_form' , name = 'purchase' and object_id = 6 )и для одной строки по которой происходит круппировка никак не может набраться 1млн строк

Up!

Обновил кликхаус до 1.1.54381 и наступил на то, что запрос SELECT sum(data_compressed_bytes) AS data_compressed, sum(data_uncompressed_bytes) AS data_uncompressed FROM system.parts_columns WHERE active = 1; стал выдавать значения, не соответствующие действительности. Где-то этак на порядок.

Вам нужно использовать столбцы column_data_compressed_bytes и column_data_uncompressed_bytes. Просто data_compressed_bytes относится ко всему куску.

То есть пользовался багом :-) Ясно.

В parts_columns первые N столбцов продублированы из parts

Плюс ещё есть небольшой эффект, из-за которого например сумма column_data_compressed_bytes по всем столбцам куска не будет равна data_compressed_bytes этого куска - если столбец Nested, у всех подстолбцов общий столбец с размерами, соответственно он будет входить в размер каждого подстолбца и посчитается несколько раз.

То есть, если нужны именно размеры для всего куска, надо брать data_compressed_bytes

Всем привет. Может быть кто-то сталкивался, а может нет ) Проблема обсуждалась около года назад, но мы попробовали вновь и получили опять нехороший опыт. Может быть проскакивала какая-то волшебная настройка и мы пропустили. Суть проблемы. Есть таблица ReplicatedReplacingMergeTree, пытаемся сделать MV с ReplicatedAggregatingMergeTree, при использовании sumState,uniqState получаем задваивание показаний. Связано с чтением с каждой реплики скорее всего, отсюда и задвоение. Решение не нашли.

версия CH 1.1.54380

При использовании MV с AggregatingMergeTree никаких проблем. Всё как и должно быть.

Господа, есть ли best practices по резервному копированию с целью последующего восстановления после полного дизастера? А то у меня кх вырастает из виртуалок, которые бекапились целиком, и надо бы его бекапить так, чтоб не было мучительно больно. Пока вижу примерно такое: SHOW CREATE TABLE ... ALTER TABLE ... FREEZE ... и результат утащить на хранилище, прибрав за собой. После дизастера - восстановить кластер, создать таблицу и сделать ей ATTACH на взятое из хранилища. Есть что-то, что я упустил или всё так и есть?

Привет ! Вопрос такой, очень много ошибок про сеть, хотя сеть тестили и все нормально - мы могли упустить что-то важно в настройках из-за чего сеть не хватает или нужно ЕЩЕ внимательнее сеть между машинами проверять ? 2018.05.21 11:55:46.112519 [ 101581 ] <Error> executeQuery: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (10.7.16.109:38824), e.what() = DB::NetException (from 10.7.16.109:38824) (in query: SELECT report_date, domain, visits, users, direct, referral, social, search, paid, hits, hits / visits AS pages_per_visit, bounce_rate, time_on_site, rank FROM domain_metrics PREWHERE (report_date = '2018-03-01') AND (country_code = '') AND (did IN cityHash64('eleconomista.es'))), Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x15) [0x84eb065] 1. /usr/bin/clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x6bb) [0x851684b] 2. /usr/bin/clickhouse-server(DB::WriteBuffer::next()+0x25) [0x2cde045] 3. /usr/bin/clickhouse-server(DB::TCPHandler::processOrdinaryQuery()+0x494) [0x2cd9124] 4. /usr/bin/clickhouse-server(DB::TCPHandler::runImpl()+0x607) [0x2cdc6f7] 5. /usr/bin/clickhouse-server(DB::TCPHandler::run()+0x2a) [0x2cdd3ba] 6. /usr/bin/clickhouse-server(Poco::Net::TCPServerConnection::start()+0xe) [0x86d53de] 7. /usr/bin/clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x169) [0x86d57b9] 8. /usr/bin/clickhouse-server(Poco::PooledThread::run()+0x76) [0x8776976] 9. /usr/bin/clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x37) [0x8772b87] 10. /usr/bin/clickhouse-server() [0x8dd397e] 11. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76b9) [0x7f039d3bc6b9] 12. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6c) [0x7f039cbe541c]

Господа, есть ли best practices по резервному копированию с целью последующего восстановления после полного дизастера? А то у меня кх вырастает из виртуалок, которые бекапились целиком, и надо бы его бекапить так, чтоб не было мучительно больно. Пока вижу примерно такое: SHOW CREATE TABLE ... ALTER TABLE ... FREEZE ... и результат утащить на хранилище, прибрав за собой. После дизастера - восстановить кластер, создать таблицу и сделать ей ATTACH на взятое из хранилища. Есть что-то, что я упустил или всё так и есть?

Все так и есть, только вместо SHOW CREATE TABLE можно бекапить папку с метадаными

Всем привет. Может быть кто-то сталкивался, а может нет ) Проблема обсуждалась около года назад, но мы попробовали вновь и получили опять нехороший опыт. Может быть проскакивала какая-то волшебная настройка и мы пропустили. Суть проблемы. Есть таблица ReplicatedReplacingMergeTree, пытаемся сделать MV с ReplicatedAggregatingMergeTree, при использовании sumState,uniqState получаем задваивание показаний. Связано с чтением с каждой реплики скорее всего, отсюда и задвоение. Решение не нашли.

Есть где-нибудь пример как воспроизвести?

Благодарю, про то, что метаданные лежат в открытом виде забыл.

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

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

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

По-крайней мере, стоит посмотреть, сколько выполняется этот запрос в консоли

Привет ! Вопрос такой, очень много ошибок про сеть, хотя сеть тестили и все нормально - мы могли упустить что-то важно в настройках из-за чего сеть не хватает или нужно ЕЩЕ внимательнее сеть между машинами проверять ? 2018.05.21 11:55:46.112519 [ 101581 ] <Error> executeQuery: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (10.7.16.109:38824), e.what() = DB::NetException (from 10.7.16.109:38824) (in query: SELECT report_date, domain, visits, users, direct, referral, social, search, paid, hits, hits / visits AS pages_per_visit, bounce_rate, time_on_site, rank FROM domain_metrics PREWHERE (report_date = '2018-03-01') AND (country_code = '') AND (did IN cityHash64('eleconomista.es'))), Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x15) [0x84eb065] 1. /usr/bin/clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x6bb) [0x851684b] 2. /usr/bin/clickhouse-server(DB::WriteBuffer::next()+0x25) [0x2cde045] 3. /usr/bin/clickhouse-server(DB::TCPHandler::processOrdinaryQuery()+0x494) [0x2cd9124] 4. /usr/bin/clickhouse-server(DB::TCPHandler::runImpl()+0x607) [0x2cdc6f7] 5. /usr/bin/clickhouse-server(DB::TCPHandler::run()+0x2a) [0x2cdd3ba] 6. /usr/bin/clickhouse-server(Poco::Net::TCPServerConnection::start()+0xe) [0x86d53de] 7. /usr/bin/clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x169) [0x86d57b9] 8. /usr/bin/clickhouse-server(Poco::PooledThread::run()+0x76) [0x8776976] 9. /usr/bin/clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x37) [0x8772b87] 10. /usr/bin/clickhouse-server() [0x8dd397e] 11. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76b9) [0x7f039d3bc6b9] 12. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6c) [0x7f039cbe541c]

У вас сам запрос сколько раз выполнился правильно? Во время него машины не падают?

У вас сам запрос сколько раз выполнился правильно? Во время него машины не падают?

Машины в кластере падают, но в логах только ошибка про сеть

полторы минуты. возможно что-то с таймаутами tcp, прпадающими пакетами, неверным mtu и запретом icpm. ну или dns

Машины в кластере падают, но в логах только ошибка про сеть

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

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

Что почитать про падения и что посмотреть, сам не местный и не настоящий сварщик

Что почитать про падения и что посмотреть, сам не местный и не настоящий сварщик

Нужно смотреть логи не только на машине которая запрос инициировала, но и на тех кто его выполнял

max_network_bandwidth max_network_bandwidth_for_user max_network_bandwidth_for_all_users эти настройки влияют только на query, и с помощью них нельзя ограничить полосу пропускания для репликации? хочу новые реплики добавить в кластер, нужно 5T по сети отреплицировать.

max_network_bandwidth max_network_bandwidth_for_user max_network_bandwidth_for_all_users эти настройки влияют только на query, и с помощью них нельзя ограничить полосу пропускания для репликации? хочу новые реплики добавить в кластер, нужно 5T по сети отреплицировать.

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

Есть где-нибудь пример как воспроизвести?

Можете попробовать на примере моих таблиц и вью CREATE TABLE test_table ( game_id String, _date Date, game_type String, game_sub_type String, status String, table_id String, casino_id String, internal_player_id String, bets.stake_casino_currency Array(Float64), bets.payout_casino_currency Array(Float64)) \ ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/test_table_2018_05_21', '{replica}', _date) \ PARTITION BY toDate(_date) ORDER BY (casino_id, internal_player_id, game_id, table_id) SETTINGS index_granularity = 8192 CREATE MATERIALIZED VIEW test_view ( Date Date, casino_id String, player_id String, wager AggregateFunction(sum, Float64), payout AggregateFunction(sum, Float64), bet_count AggregateFunction(sum, UInt64), game_count AggregateFunction(uniq, String)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/test_view_2018_05_21', '{replica}', Date, (Date, casino_id, player_id), 8192) \ AS SELECT _date AS Date, casino_id, internal_player_id AS player_id, sumState(arraySum(bets.stake_casino_currency)) AS wager, sumState(arraySum(bets.payout_casino_currency)) AS payout, sumState(length(bets.stake_casino_currency)) AS bet_count, uniqState(game_id) AS game_count \ FROM test_table GROUP BY _date, casino_id, internal_player_id

Можете попробовать на примере моих таблиц и вью CREATE TABLE test_table ( game_id String, _date Date, game_type String, game_sub_type String, status String, table_id String, casino_id String, internal_player_id String, bets.stake_casino_currency Array(Float64), bets.payout_casino_currency Array(Float64)) \ ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/test_table_2018_05_21', '{replica}', _date) \ PARTITION BY toDate(_date) ORDER BY (casino_id, internal_player_id, game_id, table_id) SETTINGS index_granularity = 8192 CREATE MATERIALIZED VIEW test_view ( Date Date, casino_id String, player_id String, wager AggregateFunction(sum, Float64), payout AggregateFunction(sum, Float64), bet_count AggregateFunction(sum, UInt64), game_count AggregateFunction(uniq, String)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/test_view_2018_05_21', '{replica}', Date, (Date, casino_id, player_id), 8192) \ AS SELECT _date AS Date, casino_id, internal_player_id AS player_id, sumState(arraySum(bets.stake_casino_currency)) AS wager, sumState(arraySum(bets.payout_casino_currency)) AS payout, sumState(length(bets.stake_casino_currency)) AS bet_count, uniqState(game_id) AS game_count \ FROM test_table GROUP BY _date, casino_id, internal_player_id

У меня просто пишет при создании MV Received exception from server (version 1.1.54343): Code: 43. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: arraySum cannot add values of type Array(Float64). У вас есть что-то более читабельное?

может надо не arraySum, а sumArray?

а хотя sumState(arraySum), вроде ок.

У меня просто пишет при создании MV Received exception from server (version 1.1.54343): Code: 43. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: arraySum cannot add values of type Array(Float64). У вас есть что-то более читабельное?

при создании вью можно вообще без всего, он сам подставит нужные типы, я ещё после show create table забыл добавить ON CLUSTER CREATE MATERIALIZED VIEW test_view ON CLUSTER test \ ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/test_view/player_snapshot_2018_05_21', '{replica}', Date, (Date, casino_id, player_id), 8192) \ AS SELECT _date AS Date, casino_id, internal_player_id AS player_id, sumState(arraySum(bets.stake_casino_currency)) AS wager, sumState(arraySum(bets.payout_casino_currency)) AS payout, sumState(length(bets.stake_casino_currency)) AS bet_count, uniqState(game_id) AS game_count \ FROM test_table GROUP BY _date, casino_id, internal_player_id

Вот из этого коммита @kshvakov https://github.com/influxdata/telegraf/pull/3894/files#diff-0696c970913cf8e6aa523278cfdb70fb

Ссылочки не будет?

я правильно понимаю, что max_distributed_connections & distributed_connections_pool_size нужно не на ходу менять а перед созданием таблицы прописывать ?

я правильно понимаю, что max_distributed_connections & distributed_connections_pool_size нужно не на ходу менять а перед созданием таблицы прописывать ?

Нет, это параметры сервера, их можно всегда поменять (с его перезапуском)

Спасибо !

Скажите пожалуйста, а пользователю default можно безболезненно устаналивать пароль?

Ссылочки не будет?

Это вы мне? Там в сообщении приложен бинарник

Это вы мне? Там в сообщении приложен бинарник

Я увидел, что там была ссылка изначально)

Я увидел, что там была ссылка изначально)

https://github.com/ClickHouse-Ninja/telegraf/blob/610c583ec8d1ca58897d4f193226c9b04dbcdaba/plugins/inputs/clickhouse/README.md