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

Question

[beduin01]

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

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

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

Вопрос -- стоит ли городить такой огород? Если стоит, то какое решение выбирать?

Comments

[Adamos]

Поиск уникального ID в таблице "очень сильно тормозит систему"? Серьезно?
Вот в то, что удаление и вставка с перестройкой индексов создает заметный оверхед без всякой на то необходимости - в это поверить куда легче...

[alexalexes]

С индексацией знакомы? Индексы создали по тем полям, по которым делаете проверки и поиски?
Какое время поиска той или иной строки по индексируемым полям в вашем случае?

[beduin01]

alexalexes, индексы стоят, просто у меня куча запросов прилетает и я думал, что вынос этого всего в память ускорит процесс.

Answer 1

[gsaw]

Теоретически если есть индекс по ID, то поиск должен быть достаточно быстрым. Можно сделать горизонтальное партиционирование по хэшу от ID, что бы разбить таблицу на несколько кусков.

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

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