Ребята, доброго дня. Подскажите пожалуйста, можно ли такую схему шардирования и репликации организовать: https://groups.google.com/forum/#!topic/clickhouse/-t2JTu_Du9I

Коллеги, а на что стоит смотреть в первую очередь, когда CH кушает всю оперативку при очень не большой нагрузке. С чего стоит начать?

Посмотреть SHOW PROCESSLIST. Посмотреть SELECT * FROM system.merges. Включить log_queries в профиле default в users.xml и посмотреть system.query_log. - там есть столбец про память. Путём отключения части нагрузки определить, какие именно запросы влияют на большое потребление оперативки. Кстати, сколько оперативки и в какое значение выставлено max_memory_usage (по-умолачнию - 10 GB). Под подозрением в первую очередь запросы с GROUP BY большой кардинальности, запросы с большим ORDER BY, IN, JOIN, DISTINCT...

В SQL диалект Clickhouse не планируется добавить оконные и аналитические функции? Оч не хватает.

Добрый день.

Опять про broken pipe...

А точно ли реплики решают проблему?

<?xml version="1.0"?> <yandex> <clickhouse_remote_servers> <cluster1> <shard> <internal_replication>false</internal_replication> <replica> <host>s1r1</host> <port>9000</port> </replica> <replica> <host>s1r2</host> <port>9000</port> </replica> </shard> <shard> <internal_replication>false</internal_replication> <replica> <host>s2r1</host> <port>9000</port> </replica> <replica> <host>s2r2</host> <port>9000</port> </replica> </shard> </cluster1> </clickhouse_remote_servers> </yandex>

То есть 2 шарда из двух реплик

И хапнули 2017.06.26 09:19:56.748482 [ 46 ] <Error> advert_views.Distributed.DirectoryMonitor: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (10.21.16.93:9000), e.what() = DB::NetException, Stack trace: ...

Мне вроде как помогло обновление :)

Такой проблемы не встречал

Нам тоже не помогло, балансируем по нодам сами.

так помогло или "тоже не помогло"?

так помогло или "тоже не помогло"?

Если вопрос ко мне, то нам не помогло. Пришлось переходить на балансировку между нодами на уровне приложения. Со дня на день вроде фикс должен в репах появиться.

ну выже вроде как про обновление была речь

я и подумал, что оно вышло

но одному помогло, другому "тоже не"

Может выше обновились из testing?

как я понял в stable переходит только после установки и обкатке в yandex?

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

Печалька

Broken pipe только на одну ноду, а раком встает весь кластер.

Broken pipe только на одну ноду, а раком встает весь кластер.

А как на весь кластер аффектит? Оно ж только при записи в distributed ломается

Сейчас есть проблема, что при объёме данных больше 10 ТБ в месяц, куски плохо мержатся, из-за выставленных настроек по-умолчанию. Если это ваш случай, то можно прописать в config.xml в секции merge_tree, max_bytes_to_merge_at_max_space_in_pool побольше (по-умолчанию - 100 ГБ, можно увеличить до 500 ГБ, например).

Нужно ли перегружать сервер при изменении этой конфигурации?

Ребят, limit же выдирает в любом случае данные из конечного результата. Почему бы не реализовать в мета-данных ответа общее кол-во строк в результате работа запроса? Т.е. например делается запрос с использованием лимита, а в statistic добавляется total_rows - 100 например?

Ребят, limit же выдирает в любом случае данные из конечного результата. Почему бы не реализовать в мета-данных ответа общее кол-во строк в результате работа запроса? Т.е. например делается запрос с использованием лимита, а в statistic добавляется total_rows - 100 например?

Не думаю что из конечного результата, это было бы страенно

Ну например запрос вида select * from table order by column limit 10, 10 как отработает? Я не думаю, что там какая то хитрая логика с лимитами

Ну например запрос вида select * from table order by column limit 10, 10 как отработает? Я не думаю, что там какая то хитрая логика с лимитами

В таком случае должен конечный результат лимитировать

Я так полагаю, что и select * from table limit 10, 10 тоже по конечному результату отработает

Я так полагаю, что и select * from table limit 10, 10 тоже по конечному результату отработает

В этом случае не должен, т.к. не зхаданы условия к результату. Должен останосить на первых 10 найденных

Но CH же читаем данные блоками, а не строками? Или при наличии лимита размер блока меняется? )

В общем вот реальный запрос, на нем видна разница

SELECT COUNT(*) FROM rt_interaction_log ┌───COUNT()─┐ │ 666939651 │ └───────────┘

SELECT * FROM rt_interaction_log WHERE command = 1 LIMIT 10 ... 10 rows in set. Elapsed: 4.120 sec. Processed 65.54 thousand rows, 8.73 MB (15.91 thousand rows/s., 2.12 MB/s.)

SELECT * FROM rt_interaction_log WHERE command = 1 ORDER BY sequence DESC LIMIT 10 ... 10 rows in set. Elapsed: 22.984 sec. Processed 487.16 million rows, 70.63 GB (21.20 million rows/s., 3.07 GB/s.)

Да, судя по всему логика тут хитрая (

Парни, никто не сталкивался с проблемой - Illegal columns ColumnString and ColumnConst<UInt16> of arguments of function greaterOrEquals

?

Делаю выборку string поля после результирующего join

Делаю выборку string поля после результирующего join

Где-то идёт сравнение строки и числа https://clickhouse.yandex/docs/ru/functions/comparison_functions.html?highlight=greaterorequals

http://joxi.ru/V2VEkayt0K5Egm

Ребят, limit же выдирает в любом случае данные из конечного результата. Почему бы не реализовать в мета-данных ответа общее кол-во строк в результате работа запроса? Т.е. например делается запрос с использованием лимита, а в statistic добавляется total_rows - 100 например?

вы про rows_before_limit_at_least ?

Да

Не знал что такое уже есть! )

Где-то идёт сравнение строки и числа https://clickhouse.yandex/docs/ru/functions/comparison_functions.html?highlight=greaterorequals

Спасибо. Помогло

еще один go-шный коннектор для кликхаус. https://github.com/mailru/go-clickhouse

еще один go-шный коннектор для кликхаус. https://github.com/mailru/go-clickhouse

тю, а смысл? если есть коннектор с нативным протоколом

он не совмести с query билдером (mailru/dbr), потому что поддерживает только statements

tabseparated медленный, что его все тащат в "коннекторы". рядом же есть прекрасный rowbinary

в rowbinary нету информации о типах и именах колонок

если будет rowbinarywithNamesAndTypes добавлю его

как же нет?

insert a,b,c,d format rowbinary и поехали

мы на него перевели вставку у нас и из top вообще аккумулирующий демон пропал

а когда читаешь ?

в спецификации нету ничего про то что там приходят информация о типах и именах колонок

и как ее парсить ?

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

а когда читаешь ?

У меня хорошего ответа нет, но наверное поможет хороший запросопостроитель, который знает типы данных

По именам колоной или по явной спецификации типов

а если добавить формат RowBinaryWithNamesAndTypes ?

это могло бы помощь решить данную проблему?

Можно даже формат не менять. Добавить дополнительный http-заголовок в ответе

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

а в документации написанно что нативный лучше не использовать самостоятельно :)

это уже не так

в английском чатике проскакивала идея о поддержке MySQL протокола, но тут тоже есть ряд сложностей, например помимо протокола желательно бы добавить ряд комманд для совместимости (например begin/commit/rollback) чтоб работали существующие драйвера, вкрутить туда поддержку prepare/execute чтоб на стороне CH (по mysql протоколу) собирать батч и писать все одним блоком и т.д.

А нет какой-нибудь голосовалки, типа какую фичу ждут больше всего? Мне например больше всего "мешает" ограниченый синтаксис JOIN-ов и "плохой" проброс условий WHERE в JOIN

Привет! Возник вопрос про недерминированность groupArray. В документации сказано "Значения в массив могут быть добавлены в любом (недетерминированном)", но если у меня будет 2 groupArray в одном селекте, относительно друг друга они порядок сохраняют или тоже не гарантированно? Здравый смысл говорит, что будут соответствовать, но параноя не дремлет. :) Пример: SELECT Date, groupArray(one) AS ones, groupArray(two) AS twos, GROUP BY Date

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

после увеличения max_bytes_to_merge_at_max_space_in_pool стало потреблятся слишком много памяти

Посмотреть SHOW PROCESSLIST. Посмотреть SELECT * FROM system.merges. Включить log_queries в профиле default в users.xml и посмотреть system.query_log. - там есть столбец про память. Путём отключения части нагрузки определить, какие именно запросы влияют на большое потребление оперативки. Кстати, сколько оперативки и в какое значение выставлено max_memory_usage (по-умолачнию - 10 GB). Под подозрением в первую очередь запросы с GROUP BY большой кардинальности, запросы с большим ORDER BY, IN, JOIN, DISTINCT...

Спасибо Алексей!

В последнюю версию DBeaver добавили встроенный обновляемый jdbc драйвер КХ

Привет! Возник вопрос про недерминированность groupArray. В документации сказано "Значения в массив могут быть добавлены в любом (недетерминированном)", но если у меня будет 2 groupArray в одном селекте, относительно друг друга они порядок сохраняют или тоже не гарантированно? Здравый смысл говорит, что будут соответствовать, но параноя не дремлет. :) Пример: SELECT Date, groupArray(one) AS ones, groupArray(two) AS twos, GROUP BY Date

Порядок должен сохраняться. Недетерминированность возникает при различном порядке чтения кусков, но это не нарушает порядок относительно друг друга

Порядок должен сохраняться. Недетерминированность возникает при различном порядке чтения кусков, но это не нарушает порядок относительно друг друга

Спасибо!

А можно ли как-нибудь select-ом получить все key-value entry из словаря (или подмножество по условию)? Или только через дублирование содержимого словаря в таблице?

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

Круто

Уравниваю опять производительность с диска: КХ: 1700мс, кдб: 72мс (с диска). Запрос аналогичный. Выше был.

Причем такое ощущение, что 99% времени занимает пересчет константы в правой части in

вроде не пересчитывается SELECT number IN ( SELECT toUInt64(sleep(1)) ) AS x FROM system.numbers LIMIT 10 ┌─x─┐ │ 1 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ └───┘ 10 rows in set. Elapsed: 1.002 sec.

вроде не пересчитывается SELECT number IN ( SELECT toUInt64(sleep(1)) ) AS x FROM system.numbers LIMIT 10 ┌─x─┐ │ 1 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ └───┘ 10 rows in set. Elapsed: 1.002 sec.

У меня там select arrayjoin, сейчас покажу.

вроде не пересчитывается SELECT number IN ( SELECT toUInt64(sleep(1)) ) AS x FROM system.numbers LIMIT 10 ┌─x─┐ │ 1 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ │ 0 │ └───┘ 10 rows in set. Elapsed: 1.002 sec.

Я другого объяснения не нахожу.