@beduin01

Какой вариант архитектуры лучше выбрать для хранения данных?

Логика работы сервиса такая.
Проверяется есть ли данный ID в таблице БД. Если такой уже есть, выполняется операция удаления и затем идет вставка (upsert использовать не могу т.к. удалять нужно данные сразу из кучи связных таблиц)

Проблема в том, что БД (PG) содержит уже сотни миллионов записей и каждая подобная проверка очень сильно тормозит вставку.

Я думал использовать какое-то in-memory хранилище для указанных ID чтобы все проверки выполнялись в нем.

Вопрос -- стоит ли городить такой огород? Если стоит, то какое решение выбирать?
  • Вопрос задан
  • 102 просмотра
Пригласить эксперта
Ответы на вопрос 1
@gsaw
Теоретически если есть индекс по ID, то поиск должен быть достаточно быстрым. Можно сделать горизонтальное партиционирование по хэшу от ID, что бы разбить таблицу на несколько кусков.

Попробовать вынести ID в отдельную, небольшую таблицу.

Еще можно только вставлять данные и выбирать только с последним временем вставки. Хотя поиск для чтения будет медленным. Опять же партиционировать по времени вставки.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы