Всем привет, подскажите, почему может не удаляться таблица ? это

обычная таблица, полученная в рез-те create table .. as select, не мат. вью и с мат. вью она никак не связана, весит она всего 156 мб, конфиги кликхауса никто не трогал - почемуто имеенно эту таблицу не удается удалить

какая-то магия, у кого-нибудь еще такое случалось ?

это древний КХ какой-то?

ClickHouse 20.8.19.4

Баг какой нибудь. Вряд-ли мерж ее блокирует или мутация. Проверьте system.mutations where not is_done

ага, посмотрел, у нас system.mutations пустая таблица

Ну рeстарт

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

Ch перегрузить

а ок понял, спс, я в пн девопс попрошу рестартнуть кх тогда)

а можно у вас уточнить плз касаемо Altinity? хотелось бы проконсультироваться по вопросу: в компании где я работаю, игровой проект, кликхаус используется как основная БД и мы столкнулись с проблемами касаемо того, как хранить наши данные с учетом того, когда в свое время компания перешла на CH - никто не задумывался о масштабируемости и в итоге мы его сейчас используем очень странно - все данные в одной таблице с 50 физ. колонками, но с 27000 алиасов, что чревато тем, что слишком много джойнов в запросах приходится использовать и данные хранятся неэффективно - зачастую дата и числа в виде стринги и еще куча проблем включая то, что нет нормальной документации и ее с такой системой нормально и не сделать. подскажите плз, правильно ли с данным вопросом обращаться к вам в Altinity? И если да, то с кем можно поговорить насчет организации консультации ? буду премного благодарен)

Лучше наверное перейти на обычную БД

это как вы так определили?)

вы имеете ввиду создать промежуточное dwh по методологии и оттуда витрины собирать в кликхаус ? или совсем перейти на другую БД ? вообще с кликхауса уходить не собираемся, он нас устраивает, просто используем мы его неправильно)

Думаю по > кликхаус используется как основная БД Все таки удел кх аналитика, а не OLTP Впрочем вопрос, что вкладывается в понятие основная БД

основная БД - имею ввиду что промежуточных баз данных нет и у нас никто никогда dwh не проектировал и нет детального слоя

> подскажите плз, правильно ли с данным вопросом обращаться к вам в Altinity? И если да, то с кем можно поговорить насчет организации консультации ? буду премного благодарен) В целом это к нам, но разовых платных консультаций у нас нет. https://altinity.com/24x7-support/ https://altinity.com/free-consultation/

Данные в одной таблице - это как раз весьма по-кликхаусовски. Обилие алиасов - довольно странно, но почему бы и нет. А вот почему при этом много джойнов, мне, честно сказать, не понятно. Приведите упрощенный пример, если можно.

Возможно в каких-то случаях спасли бы CTE вместо джойнов @Aleksey_Veselov

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

Не совсем понятно почему нельзя одним запросом достать все действия пользователя. У вас должны быть обязательные колонки user_id/timestamp/event_name для всех событий, а дальше под каждое событие свои колонки могут быть. Можете одним запросом всё что надо выбирать

общие колонки только 3 - event, event_time, event_date - юзер айди для каждого ивента лежит в своей физ. колонке) абсурд но так и есть

ну я бы первым делом это поправил добавить колонку которая по ивенту вычисляет откуда брать нужный id user_id default multiIf(event = ‘event1’, user_col_1, event = ‘event12, user_col_2, …) потом уже можно поправить запись и убрать старые колонки ну и запросы на чтение сделать нормальными

ээ зачем тут КХ ? вам либо K/V (cassandra, foundationdb), либо documentdb типа монги нужны

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

КХ ужасно медленно делает точечные запросы, потому что он заточен под обработку огромных массивов, типа запрос минимально должен запроцессисть 1 - 10 млн. строк, КХ быстрее всех делает groupby и умеет делать это distributed, по вашему описанию вам это все не нужно

distributed мы используем - у нас два шарда, 6 тб данных, некоторые запросы действительно очень тяжелые (по-крайней мере так я о них думаю) если брать данные больше чем за последние 30 дней. Например часто выбираемые ивенты при взятии 30 дней выходят в 26 млн-10 млн строк, и мы редко в запросе используем один селект, в среднем 3 селекта из основной 6-терабайтной таблицы + джойны друг сдругом + аггрегация. Используются зачастую данные в запросах за 1-2 месяца . или это на самом деле небольшие запросы и их реально в другой бд не медленнее получать - например если брать те базы данных, которые вы порекоммендовали ?

а зачем "Например часто выбираемые ивенты при взятии 30 дней" ? Почему вам надо ивенты за 30 дней ?

ну зачастую в дешах выбирается около 30 дней - для мониторинга, для выборки юзеров добавленных в тот или иной эксп и т.д.

Т.е. КХ это не основная бд, а просто бд для внутренней аналитики, тогда понятно. Вам тогда надо просто дождаться фичи "хранениия полу-структурированных данных" в 2022 году и тупо сделать все проще и без алиасов и все залетает.

да она для внутренней аналитики, под "основной" я подразумевал что нет другой промежуточной бд - данные напрямую летят в кликхаус через какой-то написанный руками девопс микросервис

а не подскажете где можно прочитать про данную фичу ?

а еще не подскажете плз - всетаки описанные мной запросы стоит относить к точечным запросам ? адекватен ли в нашем случае все-таки кликхаус ?

https://github.com/ClickHouse/ClickHouse/issues/23516 (в целом она не про json , не обращайте внимание на json)

спасибо прочитал, да это будет удобнее работы с алиасами

Примерно (очень примерно) понятно. Один путь - использовать JSON. Это довольно логично и соответствует разнородности хранимых данных. Часть проблем вы таким способом решите (хотя бы информация о структуре адеквантная и она рядом с данными), но, видимо, по производительности будет хуже, несмотря на обилие средств для работы с JSON в CH. Ну или Map. Есть несколько текстов про хранение слабо структурированных данных, например https://kb.altinity.com/altinity-kb-schema-design/best-schema-for-storing-many-metrics-registered-from-the-single-source/ Это выглядит скорее движением назад и "продать" может быть сложно, но, возможно, "назад" - это правильное направление в вашем случае. Другой путь - небольшие расширения: добавить еще немного колонок, чтобы решить проблемы с типами, разделить на две-три-четыре таблицы, если все же есть осмысленные группы событий.

Спс, ну да хранить джсоны не оч охота пусть и гибко, т.к. тогда скорость запросов наверное будет вообще не очень. А добавить новые колонки кажется не лучшей идеей потому что по ним не будет сортировки (им. ввиду блок order by при создании таблицы) и значит выборка по ним будет медленной Недавно я как раз добавил банальный новый столбец default now() чтоб видеть гэп между событиями и их записью в кх, в итоге по этому новому столбцу выборка прям плохо работает. А изменить ключи сортировки и партиционирования в уликхаусе в созданной таблице уже не можем

Про медленную выборку не очень понимаю. Потому что сортировка работает только в том порядке, который указан в ORDER BY, т.е. поиск по второму и третьему полям (но без первого) будет полным перебором или близко к тому. Это означает, что у ваших данных присутствует упорядоченность по небольшому числу полей, и вот именно эти поля нужно оставить как колонки, а все остальное спрятать в JSON. Наверное. Могу посоветовать больше экспериментировать, это всегда интересно, а иногда еще и полезно ;)

А я про второй путь, который вы описали имел ввиду) ну т.е. если в текущую 6тб таблицу добавить новые колонки чтобы решить проблемы с типами то по жтим новым колонкам выборка будет медленной. Сейчас у нас просто в order_by все 50 физ колонок таблицы, и ввборка по любой новой будет значительно хуже) а так да, я хочу создать тестовую dwh из нашей в виде нескольких таблиц и взять период в месяц и далее затетстить и псмотреть минусы. Но пока не понимаю как лучше это дело создать - на питоне запарюсь ведь надо огромную кучу преобразований выполнить для каждого ивента, вот пытаюсь кх с dbt подружить но пока не удается, чтобы упростить весь этот процесс) так что я пытаюсь в целом экспериментировать)

В моем понимании, присутствие некоторой колонки в ORDER BY сорок девятой (или даже четвертой) по счету, никаким образом не ускоряет выборку по этой колонке.

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

Да, это же не N индексов, а один по N колонкам. Поэтому можно еще раз перечитать те варианты, которые я перечислял выше ;)

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

Зависит от кардинальности колонок, если uuid стоит первым в order by, то дальше уже не важно)