1 не обновлять или не использовать КХ
2 collapsing/replacing/aggregatingMT
3 insert-select в новую таблицу (так хоть старые данные будут целыми) или добавлять колонку.
4. отрицание
5. гнев
6. торг
7. депрессия
8. принятие
9. mutations (ALTER TABLE UPDATE/DELETE)
10. увольнение


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

или 11. pull request на апдейты-делиты

после 3 все пошло под откос

Операции ALTER UPDATE в КХ пока что нет. Если не ошибаюсь.

Если нужно что-то удалить/перезаписать в частных случаях и это не затруднительно делать руками — то merge tree хватит.
Если данные нужно систематически обновлять, то конечно нужно использовать движки.

https://clickhouse.tech/docs/en/sql-reference/statements/alter/delete/
https://clickhouse.tech/docs/en/sql-reference/statements/alter/update/
вы вот это имеете ввиду или что то другое?

неужели после этого надобность в движках ReplacingMergeTree и CollapsingMergeTree отпала?
и что тяжелее для субд будет, проапдейтить через ALTER TABLE UPDATE
или использование   этих движков?

Всем привет.
Подскажите, как бы проредить данные? Например есть таблица c дискретностью до 5 раз в секунду
ts (unix timestamp), value
1597081596.081 , 1
1597081596.192 , 0
1597081596.438 , 1
1597081596.678 , 0
1597081596.982 , 1
1597081597.082 , 1
1597081597.199 , 1
1597081597.371 , 0
1597081597.663 , 1
1597081597.958 , 1

Нужно оставить только по 3 значения в секунду. Желательно как-нибудь ровненько разделить по периоду.

Это же колоночная бд, у тебя и будет уникальная запись в ней, просто индекс будет ссылатся на не из нескольких строк таблицы

О, раз заговорили про партиции. Кто-нибудь сталкивался с проблемой дублирования записи из разных парт-ов при выборке через FINAL?
Вводная.  В КХ есть таблица на 100млн записей (10ГБ). Партицирование происходит по полю "дата создания".
Проблема. С недавнего времени у пользователей появилась возможность редактирования этого поля. Теперь при построении статистики одна и та же запись фигурирует в разных датах, потому что при селекте из FINAL данные мержатся внутри парт.
Если строить парты по другому полю, которое никогда не меняется, то выборка через FINAL происходит очень медленно когда этого поля нет в WHERE.

Я использую ReplaceMergeTree и читал про CollapseMergeTree, но не хотелось бы переходить на него - слишком много запросов пришлось бы переделывать. Может есть возможность решить это через подзапросы или каким-нибудь другим движком?

Господа, помогите разобраться:
есть колонка в таблице timestamp DateTime
я делаю селект из таблицы:

SELECT
       `timestamp`,
       toDateTime(`timestamp`, 'UTC') AS `utc`,
       toDateTime(`timestamp`, 'Asia/Hong_Kong') AS `china`,
       toDateTime(`timestamp`, 'Europe/Moscow') AS `moscow`
...

и получаю 4 одинаковые даты/время...
разве оно не должно конвертиться в указанную time zone?

это не dbgrip, это jdbc

вам на самом деле нужен toString , toDateTime тут неверно использовать

SELECT
       toDateTime('2000-01-01 00:00:00') timestamp,
       toString(`timestamp`, 'UTC') AS `utc`,
       toString(`timestamp`, 'Asia/Hong_Kong') AS `china`,
       toString(`timestamp`, 'Europe/Moscow') AS `moscow

да, с этим я разобрался... теперь пытаюсь понять почему на 2х серверах с одинаковыми конфигами SELECT timezone() возвращает разные результаты

да, с этим я разобрался... теперь пытаюсь понять почему на 2х серверах с одинаковыми конфигами SELECT timezone() возвращает разные результаты