без репликации никуда

Ну то понятно, я вот думаю как себя словари поведут, у нас я настаиваю на словарях, и не много стремно. Чтобы не вылезло боком.

я бы вот не рискнул делать кх основной бд

слишком много заморочек

с транзакциями и т.д.

нужно делать самому транзакции на уровне приложения

+ удаления нету

не подходит вообще для основной бд

ну у нас пока в 100 гб укладывается кх

словари из мускуля, живут в памяти прекрасно: SELECT type, element_count FROM system.dictionaries ┌─type───┬─element_count─┐ │ Hashed │ 2939 │ │ Hashed │ 966854 │ │ Hashed │ 1611475 │ │ Hashed │ 70 │ │ Hashed │ 29613 │ │ Hashed │ 61948 │ │ Hashed │ 3093 │ │ Hashed │ 3599277 │ │ Hashed │ 318636 │ │ Hashed │ 64 │ │ Hashed │ 19428 │ │ Hashed │ 15570993 │ │ Hashed │ 1028 │ │ Hashed │ 320681 │ │ Hashed │ 2745141 │ └────────┴───────────────┘

Храните в оперативе? А сортировка по имени как?

храним в оперативке, по имени не сортируем

если нужна сортировка по имени

у нас в справочниках есть поле ord

в котором указана нужна сортировка

потом что постоянно просят костыль в виде "а вот этого всегда вверху"

Насколько плохо пушить старые по времени данные в кх?

и вот это поле, если надо добавляем

я бы вот не рискнул делать кх основной бд

КХ только для статистики, воркеры собирают данные(id шки в основном и числа) из mysql в дерномализованном виде и кладут в КХ, потом по этим данным строим отчеты

Насколько плохо пушить старые по времени данные в кх?

Всегда так делаю, не вижу ничего плохого

и вот это поле, если надо добавляем

Ясно. Ну у каждого свои велосипеды

я вообще update и delete жду

чтобы весь кх переделать

и синхронизацию

и справочники

возможно еще микросервис на жаве заменить на lua

если получится подключится

я вообще update и delete жду

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

у нас данные не так часто меняются

Всем доброго дня! Нарвался на КХ при изучении систем, которые могли бы потянуть большие объемы данных, но по описанию вижу, что для OLTP оно не годится. Сам я не разработчик, поэтому прошу помощи - подскажите на что можно посмотреть, если нужна высоконагруженная СУБД и обвязка? Заранее спасибо!

мб greenplum ?

но иногда надо

Насколько плохо пушить старые по времени данные в кх?

https://clickhouse.yandex/docs/ru/single/#_46

и делит очень нужен

даже пусть с переписыванием всего блока

+ чтобы при обновлении версии таблицу не дропать

а обновлять незаметно для пользователя

пусть оно там в фоне мержится

и делит очень нужен

А слопование не подходит?

иногда надо удалить целиком без остатка

пытались сделать replacedmergetable

вообще не фонтан

А мне нравится, куча таблиц, сразу после инсерта в скрипте делаю optimize table partition final, пока нареканий нет

а мне не помогает

вот сегодня

100к записей

делаю optimize table partition final

0 толку

всмысле 100к лишних записей

Ясно, а перезапись партиций. Типа если надо удалить, взять нужные данные из партиции, удалить и вставить снова

я хотел уже так делать

но это пока не критично

и можно дождатся update/delete

Ясно

пока данные за 20 минут переливаются

из постгреса в кх

можно дропать

Странно, у меня всегда хлопается одним запросом до последней записи, например в таблице где партиции по дню, ~2 млн строк за день, перезаливаю раз в час, хлопается сразу же

у меня партиции по стандартному ключу

Главное чтобы update/delete не влияли на скорость выборки

может если сделать по 1 дню, то лучше станет

мы готовы смирится с падением скорости на какойто промежут времени

когда выполняется update/delete

днем у нас мало записей приходит

все в основном ночью

У вас версия кх какая

вчера обновлялся

думал, мб баг где

а нет

не помогло

У меня 343, может не надо обновляться)))

и воспроизводится еще както странно

не всегда

делаю optimize table partition final

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

У вас точно данные с одним ключом не разьезжаются по шардам?

1 машина

места свободного чуть меньше чем сама бд занимает

Опа

Может в этом дело

но партиции то не больше гигобайта

места свободного чуть меньше чем сама бд занимает

это не важно, размер парта определяется параметром merge чего-то там.

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

Хорошая мысль про итоговый размер

на прошлой неделе у меня вообще дублей было столькоже, столько настоящих данных

просто х2

я изначально надеялся запихивать вообще все

при обновлении

и пусть оно там удалит старое

но чтото не пошло

Селекты с final убирают дубли, с ним медленно выходит?

медленно

почти в 5 раз

Ну да, у меня также

надо попробовать ключ по дням сделать

может легче станет

У меня когда своб.места остаётся мало, кх перестает мержить

ну я не думаю что ему 90 гб для мержа мало

если реально так, то можно еще сотку выпросить

правда возмущаются, когда ссд просишь

вы проверьте есть ли вообще что мержить select * from system.parts where table = и параметр max_bytes_to_merge_at_max_space_in_pool

ну я проверяю дубли сравнивая результат между final и не final запросом

дубликаты илиминируются при мерже партиций (в старых версиях КХ)