Comments 25
Хм. 150гб? Это очень мало чтобы создавать проблемы. Для MSSQL это игрушечный объем.
краткая справка: данный движок автоматически удаляет дубликаты записей по ключу сортировки
Вот тут имеются вопросы. Понятно, что в исходных данных, которые переносятся, поле версии отсутствует как класс... но что использовалось как поле сортировки? или исходные данные содержали в том числе и штамп времени создания записи (или штамп времени создания и штамп времени, на который передаются показания, у вас одно и то же)? но если так - то есть ли гарантия, что последние значения - верные? Потому как вы указываете:
В таблице хранятся как автоматически переданные данные, так и внесённые жителями вручную.
что не исключает сценария типа "сегодня снимаем показания автоматом, а завтра абонент вручную вводит показания, снятые им два дня назад"... или вообще случая, когда, зная о грядущем повышении тарифа, потребитель сознательно завышает показания, чтобы оплатить авансом побольше по текущему тарифу - в этом случае автоматический съём, который получит значения меньше предыдущих, вообще неясно как себя должен повести.
Мне лично вообще категорически не понравился подход, когда часть исходного сырого датасета (пусть и имеющего дубликаты и иные погрешности) удаляется безвозвратно, и уж тем более когда это выполняется автоматически.
Исходные данные содержат как время внесения показаний, так и флаг, вручную они были добавлены или автоматически. Соответственно, при выборке данных для отчета это также учитывается (если ручные показания были внесены Х дней назад, приоритетны они, иначе - автоматические). По поводу безвозвратного удаления — в крайнем случае можно получить эталонные показания, но это весьма трудозатратно.
Не написали самого важного, про вставку данных. Думаю автор знает, что clickhouse не умеет транзакций, а гарантию доставки хочется (вдруг какие то данные не придут).
Clickhouse много чего делает «не так» (как мы привыкли в mysql). И многое он делает «сам» периодически и тихо. Короче нельзя просто так взять и скопировать таблицу из MySQL ;)
Вроде у них там уже есть транзакции на уровне экспериментальной фичи.
Но а ещё есть чисто философская мысль, если я вставляю в КХ через кафку и в кафке включаю транзакции - это годная вещь? Или надо больше транзакционности?
Replicated replacing merge tree умеет в дедубликацию при вставке, видит последние n инсертов (вроде по умолчанию 50) и в случае если один и тот же батч данных прилетело, то второй раз просто будет игнорировать
для PostgreSQL есть extension:
https://github.com/citusdata/citus
тут и колоночное хранение и распределенные таблицы
ну и справедливости ради - был опыт работы c БД Percona (форк MySQL) размером 1Tb, правда - хорошо спроектированной - было все ок.
Спасибо, не надо)
Citus, увы, так prod-ready решением и не стал. В одном проекте имели неосторожность, как раз под IoT, взять его. И, когда начали возникать необъснимые проблемы, и вышло связаться с разрабами, те так и сказали, что "простите, но мы не можем гарантировать, что не будет случайных потерь данных при вашем сценарии использования".
А что за сценарий использования был, что они так ответили?
Наличие Azure Cosmos DB for PostgreSQL как-то не похоже на "prod-ready решением и не стал"
простите, но мы не можем гарантировать, что не будет случайных потерь данных при вашем сценарии использования
вау, жестко как, впрочем реальность такова, что любой продукт приходится проверять, подойдет ли он под реальную с запасом нагрузку
Что-то я не понял, раньше была полная история показаний, а потом эффективные менеджеры оптимизировали и вы стали данные через пол года нафиг того, на мусорку.
А в MariaDB не использовали партицирование?
Учитывая, что вы явно с превеликим удовольствием открыли для себя партиции, знали ли вы о индексах в mariadb?
И зачем экономить место? Неужто ваше время, потраченное на это все стоит дешевле?
И кажется вы не очень хорошо знакомы с разными бд, от чего сделали совсем не оптимальный выбор. По вашим же словам и вашим проблемам, вам нужна именно OLTP бд, к которым относится постгрес, например. А потом накинуть туда нормальную модель данных. И ничто тогда не остановит этот паровоз. А статистику считать в ваших объемах - пустяк, постгрес прожует легко.
А вот клик мучать запросом показаний конкретного юзера - такое себе)
Да он и будет работать не очень хорошо с таким запросом. Там структура неподходящая. Для такого запроса как раз нужна обычная реляционная база. Вот группировки клик хорошо будет делать. Я вот не пойму почему просто две базы рядом не поставить?
Да, знали.
Учитывая планируемый рост, место действительно придется экономить. Но да, в процессе не раз всплывала мысль.
Не буду строить из себя эксперта, но знакомства и опыт с разными БД - дело наживное.
А вот клик мучать запросом показаний конкретного юзера - такое себе)
Вы пришли к этому: PARTITION BY toYYYYMM(created)
А что было изначально?
Clickhouse: прогулки по граблям