????? https://www.hetzner.com/news/traffic-limit/
какой у вас год?

Диск в стоке SSD 120, но можно любой попросить

Единственный минус что они в BGP не умеют

Только могут со своей AS за анонсить одну сеть на один сервер

Позавчера буквально смотрел, натыкался. Сейчас поищу

Всем привет! Разбираемся с Clickhouse, находим следующее - ClickHouse merges data part in an unknown moment of time which we can not predict (речь об CollapsingMergeTree). Можно как то это контролировать, вызывать тогда и только тогда, когда нам это нужно, без этого not predict? Спасибо!

У меня такое приходится делать из-за того что меняется прошлое и сжатие.

В одном куске сжатие x16, а без оптимизации сильно меньше.

Поэтому OPTIMIZE TABLE изменчивое.прошлое PARTITION toYYYYMM(today() - toIntervalMonth(1)) воимя сжатия

Спасибо! Можем мы вообще не так понимаем как нашу задачу решить на Клике (так как первый раз его используем). Так что будем рады совету!
Расклад такой - у нас есть данные о продажах. В день к нам приходят миллионы записей, мы по ним потом считаем статистику всякую. Проблема в том, что к нам периодически приходят корректировки по этим записям, по которым мы должны либо удалить часть записей либо поменять атрибуты. Причем эти корректировки приходят много позже оригинальных записей. Раз в сутки мы хотим иметь возможность снять снепшот таблицы с последними версиями всех записей. Подходит ли нам Клик? И если да, то как лучше сделать механизм обновления данных?
Еще раз спасибо! (Не удаляйте, нам больше некуда идти).

миллионы в день это немного, тупо перезаливайте всю таблицу целиком.

У вас 3 варианта:
1. Перезалив части информации с кратковременным отсутствием части данных в таблице
2. Использование соответствующего табличного движка с поддержкой версионирования
3. ALTER TABLE <name> REPLACE PARTITION ...

Минусы:
1. минус онлайн отчётность
2. плюс накладные расходы на версии
3. минус MV

Плюсы:
1. тупо проще в реализации
2. MV, правда с минусами из опять же п. 2
3. Быстро и просто - можно перезаливать таблицу по партициям

Спасибо! У нас данные приходят инкрементально через кафку, кликхаус - единственное хранилище, а суммарное количетсво данных миллиарды, так что перезалив всей таблицы нам не пойдет.
Движки таблиц смотрели, но тут интересен вопрос как долго будет проходить optimize final на миллиардах, учитвая что корректировки приходят к старым данным.

Кафка не гарантирует отсутствия дублей если что.

Проверено вот этими руками 🤲

В случае сбоев возможны повторы повторы

А под "инкрементально" подразумевается двойная запись или повтор транзакции которая изменилась?