Пожалуйста скажите что это за папка ?

это внутри дистрибьютед таблицы

никто не знает ?

А давно эта папка такого размера ? Может у вас левый шард в конфиге кластера раньше был?

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

выглядит как output папка для distributed таблицы c данными которые не попали в сервер

вы в кубере пытаетесь запустить ваш кластер?

да кластер работает кубере

папка конкретно где находится? полный путь покажите

внутри его .bin файлы есть .последняя дата изменения этой папки 27 сентября

внутри папки дистрибьютед таблицы

data/{database name}/{table name}/

ну у вас 69 гигов не скинутых .bin файлов в distributed таблице, в underlying таблицу в хост с названием chi-clickhouse-digitalks-0-0 это имя kubernetes service

этот файл есть у каждого шарда

расшарьте SHOW CREATE TABLE {database name}/{table name}

Orkhan Zeynalli
долго выполняется

можете на сервер зайти и посмотреть /var/lib/clickhouse/medatata/dmp/event_logs.sql ?

там DDL таблицы

SELECT create_table_query, hostName() h FROM cluster('all-sharded', system.tables) WHERE database='dmp' AND name=`event_logs_local

Локальные таблицы у меня MergeTree

CREATE TABLE dmp.event_logs_local (user_id UUID, pixel_id UUID, new_user UInt8, ip IPv4, time DateTime, headers String, browser String, browser_major String, os String, os_major String, device String, city String, city_id UInt64, country String, country_id UInt64, country_iso String, time_zone String, longitude Float64, latitude Float64, data String, page_url Nullable(String), view UInt8 DEFAULT 0) ENGINE = MergeTree PARTITION BY (pixel_id, toYYYYMMDD(time)) PRIMARY KEY cityHash64(user_id) ORDER BY cityHash64(user_id) SAMPLE BY cityHash64(user_id) SETTINGS index_granularity = 8192

>раньше было . я увеличил лимит до 3 тысяч PARTITION BY (pixel_id, toYYYYMMDD(time)) - кажется вам сюда стоит обратить внимание

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

каждая партиция - отдельная папка, в ней по 2 файла на каждую колонку, с таким мелким партиционириванием у вас будет миллиард маленьких файлов - сервер будет очень медленно стартовать - сжатие данных около нулевое получите - чтение будет тормозить, у вас по сути надо всегда random read делать чтобы что-то прочитать в какой-то момент у вас всё станет колом и вы не запустите сервер если не разбираетесь - самый популярный вариант PARTITION BY toYYYYMM(time) а какие запросы планируете делать?

происходит то что описываете вы . некоторые шарды стартуютса очень медленно . SELECT запросы тоже медленно выполняются если делать ALTER TABLE и менять PARTITION BY . тогда КХ будет заново партиционировать уже умеющие парты ? или это будет относиться к новым данным ?

есть одно что - количество pixel_id не очень много . максимум 200

нельзя поменять PARTITION BY, создаёте правильную таблицу, переливаете данные и меняете их местами

ну это не так плохо, а сколько дат уже есть?

от сентября до сегодняшного числа . 2021.09.01 - 2022.01.04

понятно это спасибо большое

уже много получается, ~25000 партиций, лучше до 1000 иметь(в зависимости от вашего железа может быть и меньше)

кривая схема данных (кривой PARTITION BY) и изменение константы вместо того чтобы понять что она значит... сейчас у вас будет никакая производительность в итоге судя по всему при вставке в distributed таблицу у вас ноды между собой не могут связаться для того чтобы в MergeTree таблицу данные передать... у вас с одной ноды на другую с default пользователем позволяет коннектиться? зайдите в контейнер kubectl exec -n clickhouse ... -- clickhouse-client

SELECT у меня чаще бывают именно с условием pixel_id и с датой

зайдите внутрь pod смотрите логи /var/log/clickhouse-server/clickhouse-server.log

так почему бы в ORDER BY не поставить pixel_id на первое место? зачем вам там cityHash64(user_id)? и зачем вам SAMPLE?

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

Это всё зделал предыдущий разраб . по user_id тоже делается выборка . как вы говорите это логично - буду попробовать заново создать таблицу перенести данные на него

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

Orkhan Zeynalli

сверьте структуру distributed и mergetree таблицы судя по всему она у вас не совпадает

исправил это

ну ждите теперь, пока у вас ваши 69 гигов не вставленной даты разъедутся