У нас есть основная таблица, где хранятся записи за короткий промежуток времени. (1-6 минут) При селекте мы агрегируем записи (час, день, месяц), на таком большом объеме данных это работает медленно, поэтому мы строим materialize view, где хранятся записи схлопнутые по часу, что существенно ускоряет выборку и агрегацию. Но записи в эту вьюху залетают при инсерте в основную таблицу. Как будто бы в твоём решение, мы сможем получать дедуплицированные данные из основной таблицы, но вставить во вьюхи без дублей мы не сможем, как думаешь?
Привет, возможно)) но я долго пытался найти решение, которое будет полностью покрывать наш кейс, и хорошее, быстро работающие я не смог найти. Если ты знаешь как решить эту задачку для описанного кейса - буду рад ознакомиться!
Думаем как лучше захендлить эту историю, а пока принимаем такой риск, пока такого не случалось, но если случится, етсь скрипт, который все подправит. А вот история с дублями при чтении из кафки постоянно случается с первых минут работы сервиса
Из за того, что строим materialize view от основной таблицы, где храняться агрегированные по часу записи, куда записи залетают при инсерте в основную таблицу. Если на моменте инсерта будет дубль в основной таблице, то он залетит во вьюху и убрать оттуда его будет уже куда сложнее, т.к там нет уникальных идентификаторов
Пробовали что-то похожее. Проблема в том, в основной дедуплицированной таблице хранятся метрики за коротки промежуток времени, и их агррегация по часу, дню, месяцу на селекте отрабатывает достаточно долго из-за большого количества. Поэтому мы строим Materialize View, где храним агрегированный по часу метрики, но поскольку записи во вьюху залетают во время вставки в основную таблицу, то если в основную заедут дубли, то они заедут и вовьюху. Хотя в таком варианте, можно закидывать во вьюху "только свежие строки среди дублируемых
Такой вариант не рассматривали, будет здорово если расскажешь идею поподробнее.
Вставка в клик происходит в рамках монговской транзакции, в случае ошибки клика, откатим монгу.
Тут понятно, что может быть риск ошибки коммита или ролбека, попробуем еще раз, в крайнем случае - принимаем такой риск и захендлим волшебным скриптом, но пока не приходилось
Таймстампы есть, как вариант можно их использовать, для сокращения выборки при проверки на уникальность, но это действительно не отменяет параллельной вставки.
Если говорить про первичный ключ, то мы используем временноую переменную в ключе для партицирования, но поскольку движок Replacing не умеет в отсутсвие дублей на уровне всей таблицы в любой момент времени, то можно выбрать любой ключ, нашей задаче это не поможет.
Если говорить про вставку батчем тут действительно N*log(M)
Не очень понял вопроса. matview не джойнит таблицу ch с монгой, мы делаем в ставку в монгу, проверяя тем самым записи на уникальность, все уникальные записи вставляются и в монгу и в таблицу в CH, на основании этой вставки мы закидываем данные в matview с агрегацией метрик по часу
У нас есть основная таблица, где хранятся записи за короткий промежуток времени. (1-6 минут) При селекте мы агрегируем записи (час, день, месяц), на таком большом объеме данных это работает медленно, поэтому мы строим materialize view, где хранятся записи схлопнутые по часу, что существенно ускоряет выборку и агрегацию. Но записи в эту вьюху залетают при инсерте в основную таблицу. Как будто бы в твоём решение, мы сможем получать дедуплицированные данные из основной таблицы, но вставить во вьюхи без дублей мы не сможем, как думаешь?
Привет, возможно)) но я долго пытался найти решение, которое будет полностью покрывать наш кейс, и хорошее, быстро работающие я не смог найти. Если ты знаешь как решить эту задачку для описанного кейса - буду рад ознакомиться!
Думаем как лучше захендлить эту историю, а пока принимаем такой риск, пока такого не случалось, но если случится, етсь скрипт, который все подправит. А вот история с дублями при чтении из кафки постоянно случается с первых минут работы сервиса
Из за того, что строим materialize view от основной таблицы, где храняться агрегированные по часу записи, куда записи залетают при инсерте в основную таблицу. Если на моменте инсерта будет дубль в основной таблице, то он залетит во вьюху и убрать оттуда его будет уже куда сложнее, т.к там нет уникальных идентификаторов
Да, такое решение будет работать, но медленно)
Пробовали что-то похожее. Проблема в том, в основной дедуплицированной таблице хранятся метрики за коротки промежуток времени, и их агррегация по часу, дню, месяцу на селекте отрабатывает достаточно долго из-за большого количества. Поэтому мы строим Materialize View, где храним агрегированный по часу метрики, но поскольку записи во вьюху залетают во время вставки в основную таблицу, то если в основную заедут дубли, то они заедут и вовьюху. Хотя в таком варианте, можно закидывать во вьюху "только свежие строки среди дублируемых
нет, вставка батчем
Такой вариант не рассматривали, будет здорово если расскажешь идею поподробнее.
Вставка в клик происходит в рамках монговской транзакции, в случае ошибки клика, откатим монгу.
Тут понятно, что может быть риск ошибки коммита или ролбека, попробуем еще раз, в крайнем случае - принимаем такой риск и захендлим волшебным скриптом, но пока не приходилось
Таймстампы есть, как вариант можно их использовать, для сокращения выборки при проверки на уникальность, но это действительно не отменяет параллельной вставки.
Если говорить про первичный ключ, то мы используем временноую переменную в ключе для партицирования, но поскольку движок Replacing не умеет в отсутсвие дублей на уровне всей таблицы в любой момент времени, то можно выбрать любой ключ, нашей задаче это не поможет.
Если говорить про вставку батчем тут действительно N*log(M)
Не очень понял вопроса. matview не джойнит таблицу ch с монгой, мы делаем в ставку в монгу, проверяя тем самым записи на уникальность, все уникальные записи вставляются и в монгу и в таблицу в CH, на основании этой вставки мы закидываем данные в matview с агрегацией метрик по часу