движка?
да, и под капотом будет все запросы с FINAL выполнять
хаха, а вот и нет https://github.com/ClickHouse/ClickHouse/blob/aff7bc3e3120c6eb844c4a789aaad68ebac7e50f/src/Storages/PostgreSQL/StorageMaterializedPostgreSQL.cpp#L389
https://clickhouse.com/docs/en/engines/database-engines/materialized-mysql/#virtual-columns Да, действительно. Вообще странно, тк _sign и _version колонки обычно нужны для VersionedCollapsingMergeTree
получается, удаление в текущей реализации не поддерживается?
Честно не скажу, емнип никто из наших клиентов ими не пользуется. Для меня эти штуки выглядят немного сомнительными в плане реализации. Особенно учитывая, что MaterializeMySQL не поддерживается core тимой ClickHouse, а MaterializePostgreSQL поддерживается, получается такое странное разделение.
Я вот тут думаю, а почему сделали так, а не как, к примеру, движок Kafka? По сути можно было бы какие либо поля с постгре оборачивать в LowCardinality и ключ сортировки задавать прямо в кх, давая больше возможностей
Некоторые кафку и используют (с debezium) (как раз такие среди наших клиентов есть) Сделали так, потому что в случае с кафкой нужно дополнительно поднимать эт самую кафку и дебезиум.
Будет использоваться do_not_merge_across_partitions_select_final ?
Ну вот я думаю что это сейчас единственный более-менее вариант
Думаю должно. (если установите сеттинг этот)
И насколько сложно это поднимать/поддерживать по вашему опыту? Есть мысль для монги такое же сделать, чтобы не перезаливать большие объемы постоянно
Кафку поддерживать и так же kafka connect, на котором дебезиум работает.
Обсуждают сегодня