SegFault, здравствуйте! :)

2017.08.07 12:20:02.827582 [ 2011721 ] <Error> BaseDaemon: ######################################## 2017.08.07 12:20:02.827603 [ 2011721 ] <Error> BaseDaemon: (from thread 57) Received signal Segmentation fault (11). 2017.08.07 12:20:02.827608 [ 2011721 ] <Error> BaseDaemon: Address: NULL pointer. 2017.08.07 12:20:02.835943 [ 2011721 ] <Error> BaseDaemon: 1. clickhouse-server(DB::Context::addExternalTable(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<DB::IStorage>)+0x22e) [0x298bd1e] 2017.08.07 12:20:02.835950 [ 2011721 ] <Error> BaseDaemon: 2. clickhouse-server(DB::TCPHandler::receiveData()+0x3ce) [0x10cb5fe] 2017.08.07 12:20:02.835955 [ 2011721 ] <Error> BaseDaemon: 3. clickhouse-server(DB::TCPHandler::receivePacket()+0x1e1) [0x10cb9f1] 2017.08.07 12:20:02.835961 [ 2011721 ] <Error> BaseDaemon: 4. clickhouse-server(DB::TCPHandler::readData(DB::Settings const&)+0x1a9) [0x10cbd79] 2017.08.07 12:20:02.835966 [ 2011721 ] <Error> BaseDaemon: 5. clickhouse-server(DB::TCPHandler::runImpl()+0x7ea) [0x10cca1a] 2017.08.07 12:20:02.835976 [ 2011721 ] <Error> BaseDaemon: 6. clickhouse-server(DB::TCPHandler::run()+0x2b) [0x10cd45b] 2017.08.07 12:20:02.835981 [ 2011721 ] <Error> BaseDaemon: 7. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x32c6a3f] 2017.08.07 12:20:02.835986 [ 2011721 ] <Error> BaseDaemon: 8. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x13b) [0x32cce7b] 2017.08.07 12:20:02.835991 [ 2011721 ] <Error> BaseDaemon: 9. clickhouse-server(Poco::PooledThread::run()+0xb7) [0x3537ee7] 2017.08.07 12:20:02.835996 [ 2011721 ] <Error> BaseDaemon: 10. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x3503f25] 2017.08.07 12:20:02.836001 [ 2011721 ] <Error> BaseDaemon: 11. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f40369d46ba]

Сделал DLL на создание реплицируемой таблицы и на двух нодах вот такая штука вылезла

Помог рестарт сервера

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

Тут точно сразу версию кх спросят

Причем у меня 8 серверов и всегда на разных такая фигня

Версия 1.1.54246

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

И вот опять такая петрушка :) CREATE TABLE statements_log ON CLUSTER statements AS r_statements_log ENGINE = Distributed(statements, cursometr, r_statements_log, rand()) И опять ноды отваливаются

Только теперь ошибка другая 2017.08.07 12:30:55.692625 [ 501 ] <Error> BaseDaemon: ######################################## 2017.08.07 12:30:55.692670 [ 501 ] <Error> BaseDaemon: (from thread 434) Received signal Segmentation fault (11). 2017.08.07 12:30:55.692869 [ 501 ] <Error> BaseDaemon: Address: 0x31 2017.08.07 12:30:55.705141 [ 501 ] <Error> BaseDaemon: 1. clickhouse-server(std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<DB::IStorage> >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<DB::IStorage> > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<DB::IStorage> > > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::shared_ptr<DB::IStorage> > >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0xa7) [0x229a6c7] 2017.08.07 12:30:55.705157 [ 501 ] <Error> BaseDaemon: 2. clickhouse-server(DB::ProcessList::addTemporaryTable(DB::ProcessListElement&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<DB::IStorage>)+0x264) [0x2942d74] 2017.08.07 12:30:55.705167 [ 501 ] <Error> BaseDaemon: 3. clickhouse-server(DB::Context::addExternalTable(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<DB::IStorage>)+0x22e) [0x298bd1e] 2017.08.07 12:30:55.705191 [ 501 ] <Error> BaseDaemon: 4. clickhouse-server(DB::TCPHandler::receiveData()+0x3ce) [0x10cb5fe] 2017.08.07 12:30:55.705197 [ 501 ] <Error> BaseDaemon: 5. clickhouse-server(DB::TCPHandler::receivePacket()+0x1e1) [0x10cb9f1] 2017.08.07 12:30:55.705203 [ 501 ] <Error> BaseDaemon: 6. clickhouse-server(DB::TCPHandler::readData(DB::Settings const&)+0x1a9) [0x10cbd79] 2017.08.07 12:30:55.705209 [ 501 ] <Error> BaseDaemon: 7. clickhouse-server(DB::TCPHandler::runImpl()+0x7ea) [0x10cca1a] 2017.08.07 12:30:55.705214 [ 501 ] <Error> BaseDaemon: 8. clickhouse-server(DB::TCPHandler::run()+0x2b) [0x10cd45b] 2017.08.07 12:30:55.705220 [ 501 ] <Error> BaseDaemon: 9. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x32c6a3f] 2017.08.07 12:30:55.705225 [ 501 ] <Error> BaseDaemon: 10. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x13b) [0x32cce7b] 2017.08.07 12:30:55.705229 [ 501 ] <Error> BaseDaemon: 11. clickhouse-server(Poco::PooledThread::run()+0xb7) [0x3537ee7] 2017.08.07 12:30:55.705236 [ 501 ] <Error> BaseDaemon: 12. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x3503f25] 2017.08.07 12:30:55.705240 [ 501 ] <Error> BaseDaemon: 13. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f6b1fb0a6ba]

А через apt обновляться безопасно? Вроде бы недавно была какая то проблема со сломанным пакетом

И вот опять такая петрушка :) CREATE TABLE statements_log ON CLUSTER statements AS r_statements_log ENGINE = Distributed(statements, cursometr, r_statements_log, rand()) И опять ноды отваливаются

Перед выполнением команды, не проверяли, есть ли на всех нодах таблица custometr?

Да, это продакшен кластер

Везде есть, причем после перезапуска сервера КХ на ноде запрос проходит, но отваливается на других нодах :) Рандомно причем и всегда только на двух нодах из разных шардов

Привет! Какой каноничный способ записи в питоне большого pandas.DataFrame в КХ? Просто разбивать на куски и отправлять post запросом?

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

не претендую, впрочем, на каноничность

Привет! Какой каноничный способ записи в питоне большого pandas.DataFrame в КХ? Просто разбивать на куски и отправлять post запросом?

Привет, я обычно разбиваю на куски по 10-100К строк и заливаю.

типа, df.to_csv(p.stdin)

проблема в заливке по http была в ужасной неэффективности перехода pandas -> python string

ни у кого подобного канала по hive нет?)

тоже +1 к hive каналу

может сделаем его тогда?)

http://ods.ai/

есть чатик датасаентологов

http://ods.ai/

это не то)

Ребята, а где можно увидеть что в кликхаусе добавили алиасы? какие-то новости есть где-то?

https://clickhouse.yandex/docs/ru/query_language/queries.html?highlight=%D0%B0%D0%BB%D0%B8%D0%B0%D1%81 тут только про столбец почему-то упоминание

добавили алиасы чего?

select * from table t;

clickhouse-scala-client released at sonatype https://oss.sonatype.org/content/repositories/public/com/crobox/

Изменения с версии 1.1.54236 до 1.1.54244 Новые возможности: * Распределённые DDL (например, CREATE TABLE ON CLUSTER) * Реплицируемый запрос ALTER TABLE CLEAR COLUMN IN PARTITION * Движок таблиц Dictionary (доступ к данным словаря в виде таблицы) * Движок баз данных Dictionary (в такой базе автоматически доступны Dictionary-таблицы для всех подключённых внешних словарей) * Возможность проверки необходимости обновления словаря путём отправки запроса в источник * Qualified имена столбцов * Квотирование идентификаторов двойными кавычками * Сессии в HTTP интерфейсе * Запрос OPTIMIZE Replicated таблицы теперь можно выполнять не только на лидере

Ребята, а где можно увидеть что в кликхаусе добавили алиасы? какие-то новости есть где-то?

вот новость

это называется "Qualified имена столбцов"

спасибо

dictionary engine/tables в документацию еще не попали?

А поверх дикшенари движка можно агрегации проводить? ) пробовал кто?

А при использовании движка Dictionary в качестве таблицы и последующие выборки данных из этой таблицы производят чтение из внешнего словаря каждый раз при запросе в таблицы? Или данные как то кешируются?

Кэшируются во всех случаях. Для flat, hashed словарей - читаются данные из оперативки. Для cached словарей - тоже, при чем, читается ровно то, что находится в кэше, а не все данные из источника.

Супер. Но все равно словарь может работать медленней чем "источник", если рассматривать MySQL в качестве источника.

Просто например простой запрос на avg по таблице в MySQL работает в 3 раза быстрее. Это связано с тем, что все таки данные в один поток из кеша читаются?

Одной из причин может быть проблема с промахами в кеше. Если кратко, запрос работает в 2 этапа: 1) собирает все ключи в текущем кеше и 2) делает запросы для пачки ключей. Если между этими этапами некоторые ключи выгрузились из кеша, произойдет повторное обращение м MySQL.

Одной из причин может быть проблема с промахами в кеше. Если кратко, запрос работает в 2 этапа: 1) собирает все ключи в текущем кеше и 2) делает запросы для пачки ключей. Если между этими этапами некоторые ключи выгрузились из кеша, произойдет повторное обращение м MySQL.

Не совсем понял про второй запрос. Например я делаю запрос select * from test (где test это словарь) и получается будет запрос в MySQL все равно происходить, что бы проверить все ли ключи на месте?

запрос к MySQL будет происходить, если в кеше перестали быть некоторые ключи. Если из кеша ничего не выгрузилось между 1) и 2), то запросов не будет

запрос к MySQL будет происходить, если в кеше перестали быть некоторые ключи. Если из кеша ничего не выгрузилось между 1) и 2), то запросов не будет

Ааа, так понятней )а чисто теоретически есть смысл использовать такие костыли для агрегации небольших таблиц в которых 2-5 миллионов строк и есть ли возможная деградация скорости выполнения запроса при увеличении размера словаря?

Деградация скорости, безусловно, возможна :) Чем больше словарь, тем чаще будут промахи в кеше. В целом, движок Dictionary изначально сделан для отладочных целей.

Просто у нас такой кейс, что факты приходится вычислять из сырых данных в силу определенной логики, после вычисления фактов уже делается агрегация по посчитанным фактам (строятся отчеты), а в силу того, что с апдейтами пока проблема в КХ, приходится использовать не совсем подходящие для этого инструменты. Вот я и подумал, смастерить костыль для агрегации внутри КХ, но данные брать из словарей :) Видимо это безсмысленно. Хотя, безусловно, я думаю запросы сложнее чем select avg(attempts) будут в КХ работать быстрее чем в MySQL.

Я думаю поиграться с ReplacingMergeTree в качестве таблицы с фактами (конечными) и после пересчета фактов уже записывать новые данные в таблицу. У нас сейчас не так много строк с посчитанными фактами, поэтому я думаю можно использовать FINAL, учитывая, что все таки 8 серверов в кластере.

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

Просто у нас такой кейс, что факты приходится вычислять из сырых данных в силу определенной логики, после вычисления фактов уже делается агрегация по посчитанным фактам (строятся отчеты), а в силу того, что с апдейтами пока проблема в КХ, приходится использовать не совсем подходящие для этого инструменты. Вот я и подумал, смастерить костыль для агрегации внутри КХ, но данные брать из словарей :) Видимо это безсмысленно. Хотя, безусловно, я думаю запросы сложнее чем select avg(attempts) будут в КХ работать быстрее чем в MySQL.

У нас сейчас есть похожая задача - возможность подключения внешних таблиц напрямую (CREATE TABLE ... ENGINE = MySQL или табличная функция: SELECT ... FROM mysql(...)). Эту задачу сейчас делает коллега из другого отдела ради эксперимента.

Блин, это было бы просто шикарно! Очень не хватает чего то, что позволило бы обнолять данные, т.к. именно возможности агрегации данных просто...просто нет слов :) И хочется именно КХ использоать для таких нужд.

У нас сейчас есть похожая задача - возможность подключения внешних таблиц напрямую (CREATE TABLE ... ENGINE = MySQL или табличная функция: SELECT ... FROM mysql(...)). Эту задачу сейчас делает коллега из другого отдела ради эксперимента.

Если все пройдет успешно, то было бы очень кстати иметь такую возможность под рукой :)

У нас сейчас есть похожая задача - возможность подключения внешних таблиц напрямую (CREATE TABLE ... ENGINE = MySQL или табличная функция: SELECT ... FROM mysql(...)). Эту задачу сейчас делает коллега из другого отдела ради эксперимента.

+1 vote!

И превратится clickhouse в spark где основное время занимает забор данных из хранилища )))

Обновил Tabix Build 17.08.1 [20170808] Fix: - Ошибки ERR_RESPONSE_HEADERS_TOO_BIG - Мерцание таблицы - Имя таблицы содержит точку - Заработал Export to TSV - Не oтрисовывались графики - Прочие мелочи

Доброе утро. При хранении строк очень эффективно иметь словарь и хранить значения в словаре а указатели в таблице КХ. Может кто объяснить почему так не сделано и может есть планы?

Доброе утро. При хранении строк очень эффективно иметь словарь и хранить значения в словаре а указатели в таблице КХ. Может кто объяснить почему так не сделано и может есть планы?

Это как раз таки есть

Интересно

Почему тогда при замене строк на целые и внешнем словаре использование диска сокращаетс в разы

должно не сильно изменится по идее

ERROR: S client not available

Сейчас при вставке в одну из талиц вот такая ошибка

причём вставка удачно проходит, вставляем в дистрибутед таблицу, а вот данные не появляются

не подскажете как исправить?

Ну прочитать идентификатор все таки дешевле, учитывая, что сжатие работает лучше, а данные словаря закешированы в оперативке

причём вставка удачно проходит, вставляем в дистрибутед таблицу, а вот данные не появляются

Данных нет на реплике или на шарде?

Судя по этой ошибке не видно ноду зк из кх, если я правильно понял

Проверьте статус ноды зк для начала

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

я проверял, там действительно её нет

в старом кластере это нода была, но КХ писал что типа нода существует. Мы решили грохнуть. Сейчас пишет что нет ноды. В принципе вернуть ноду не проблема, но как восстановить запись?

Т.е. по факту данные не пишутся сейчас никуда? Рестартить сервера не пробовали?

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

Если нода не заведена в кластер зк

не не, я не про реплику ZK, а ноду в ZK

путь /clickhouse/tables/{SHARD}/billy_securitylog/block_numbers/201708/block-*

Дак и я про нее. У вас кластер зк и эта нода была не в кластере?

cам то ZK в порядке

Сама по себе болталась?

Попрбуйте все таки убрать из конфига кх старую ноду зк, которая недоступна

не, что в старом кластере ZK что в новом было пять серверов ZK. Нода всмысле путь в ZK

Ааааа

вопрос именно как заставить КХ начать писать в такой ситуации. Причём у нас не одна табличка с репликами в них всё нормально пишется, а вот с этой беда какая то случилась

вопрос именно как заставить КХ начать писать в такой ситуации. Причём у нас не одна табличка с репликами в них всё нормально пишется, а вот с этой беда какая то случилась

Я с таким не сталкивался ( придется ждать ответа, либо эксперементировать )

Подскажите, а что за мониторинг ZK используете?

это самописный

но вроде в опенсорс скоро выложат

отлично бы было