Обсуждаем ClickHouse
Количество подключений к TCP-серверу (клиенты с собственным интерфейсом), включая соединения распределенных запросов сервер-сервер
Читать полностью…конкретно с update перерасчитывать я так понял кх не умеет
Читать полностью…для этого мусора кх не нужен, хватит и постгреса обычного
Читать полностью…короче я хочу сделать расчет Байесовское среднее, тобишь рейтинг как в стиме, там есть обращение к глобальным статам (общее среднее по всем), не пойму кх поможет с этим или нет
Читать полностью…а как сделать чтоб агрегат учитывал удаления и обновления
Читать полностью…понятно что "не надо делать", мне нужно понять в принципе это возможно или нет
Читать полностью…добавлися system.processors_profile_log -- жрет как не в себя
https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-system-tables-eat-my-disk/
системные таблицы выросли, но не могли так ускорить забивание диска. Но! в системных таблицах пухнут парт логи. и начав смотреть события в них я заметил что
┌─event_type───┬──events─┬───total_rows─┬─avg_rows_per_part─┐
1. │ RemovePart │ 1024026 │ 125013901573 │ 122080.7885473611 │
2. │ DownloadPart │ 834783 │ 61929761588 │ 74186.65879396202 │
3. │ MergeParts │ 188618 │ 50359195609 │ 266990.4018121282 │
4. │ NewPart │ 2400 │ 21761543613 │ 9067309.83875 │
5. │ MovePart │ 229 │ 9228424111 │ 40298795.24454148 │
└──────────────┴─────────┴──────────────┴───────────────────┘ прод
┌─event_type──────┬──events─┬───total_rows─┬──avg_rows_per_part─┐
1. │ RemovePart │ 3310687 │ 456090167196 │ 137762.9981922181 │
2. │ NewPart │ 1344624 │ 54580422732 │ 40591.58748616714 │
3. │ DownloadPart │ 1275289 │ 109056300961 │ 85514.97030163358 │
4. │ MergeParts │ 697044 │ 147370045247 │ 211421.43859928497 │
5. │ MergePartsStart │ 691833 │ 0 │ 0 │
6. │ MovePart │ 262 │ 19396143835 │ 74031083.33969466 │
└─────────────────┴─────────┴──────────────┴────────────────────┘ стейдж
по части события NewPart - огромная разница
Всем привет!
Может кто-то сталкивался с похожей проблемой. При перезагрузке словаря через команду SYSTEM RELOAD DICTIONARY
на нодах начинают резко подлетать коннекты и в конечном итоге часть нод падает. Оставшиеся держаться ровно час и их отпускает. Словарь большой, порядка 50-60GB и находится под постоянной читающей нагрузкой. Не могу найти как обойти эту проблему. Может у кого-то есть идеи?
из того что нашли, это подозрение на неактивные парты - их всегда больше чем на проде для той же таблицы. и рост записи данных линеен. условно он вырос в N раз.
Читать полностью…может у вас что-то в системных таблицах? может быть в новой версии появилась новая таблица с логами, и она растет?
Читать полностью…В репозитерии несколько jar должно создаваться.
flink-sql-connector-clickhouse и flink-connector-clickhouse - чем отличаются? Нет ссыки на jar, кстати
Уж извини, добрый человек, но есть вопрос. После ./mvn clean package (Я на Убунте делал, На винде не собралось, надо 11 версию ставить) где искать .jar, в папке target нет!
Читать полностью…УХ вообще рекомендуется тем у кого нет другого выхода, уже все попробовал, и КХ last resort
Читать полностью…ну я думал крикрутить агрегации на лету, но вижу что-то прям всё одна проблема на проблеме
Читать полностью…у вас вообще все странно
NewPart avg_rows_per_part 9 067 309
NewPart avg_rows_per_part 40 591
вставляли по 9 млн строк
теперь по 40 тыс
у вас с инсертом проблема
хм... processors_profile_log не представлен... у меня в сис таблицах
Читать полностью…https://clickhouse.com/docs/materialized-view/refreshable-materialized-view
Читать полностью…как сделать перерасчет мат вьюхи с агрегатами AggregateFunction ?
Читать полностью…это за день или за минуту, период одинаковый?
смотрите в NewPart разбивке по таблице
async_insert ?
Да точно системные таблицы
SELECT
database,
formatReadableSize(sum(data_compressed_bytes) AS size) AS compressed,
formatReadableSize(sum(data_uncompressed_bytes) AS usize) AS uncompressed,
round(usize / size, 2) AS compr_rate,
sum(rows) AS rows,
count() AS part_count
FROM system.parts
WHERE (active = 1) AND (database LIKE '%') AND (table LIKE '%')
GROUP BY
database
ORDER BY size DESC;
Добрый день. после обновления с 24.8 до 25.3 стали наблюдать что после обновления появилась проблема: стал быстрее забиваться диск данными. скорость заполнения выросла линейно, при сравнении с продом (он 24.3) (и со стейджом версии 24.8) почти в два раза. Заметили такой момент: в части таблиц неактивных партов всегда больше чем на проде. не совсем понятно: это нормальное поведение для этой версии или все же нет? Можно ли считать нормальным возросшую скорость забивания данными для 25.3.12?
Читать полностью…А вы точно релизную ветку взяли, как в инструкции?
git checkout release-1.16
Я смотрю там в мастере отличия, модули отдельные выделены.
Если надо - могу в личку кинуть собранный по 1.16 jar
Мы используем те пакеты, что я вам скинул вначале - все работает
Читать полностью…https://fiddle.clickhouse.com/6f996725-6d75-4b64-aa00-73a9dbe41680
Читать полностью…