Какой вариант архитектуры лучше выбрать для хранения данных?
Логика работы сервиса такая.
Проверяется есть ли данный ID в таблице БД. Если такой уже есть, выполняется операция удаления и затем идет вставка (upsert использовать не могу т.к. удалять нужно данные сразу из кучи связных таблиц)
Проблема в том, что БД (PG) содержит уже сотни миллионов записей и каждая подобная проверка очень сильно тормозит вставку.
Я думал использовать какое-то in-memory хранилище для указанных ID чтобы все проверки выполнялись в нем.
Вопрос -- стоит ли городить такой огород? Если стоит, то какое решение выбирать?
Поиск уникального ID в таблице "очень сильно тормозит систему"? Серьезно?
Вот в то, что удаление и вставка с перестройкой индексов создает заметный оверхед без всякой на то необходимости - в это поверить куда легче...
С индексацией знакомы? Индексы создали по тем полям, по которым делаете проверки и поиски?
Какое время поиска той или иной строки по индексируемым полям в вашем случае?
Теоретически если есть индекс по ID, то поиск должен быть достаточно быстрым. Можно сделать горизонтальное партиционирование по хэшу от ID, что бы разбить таблицу на несколько кусков.
Попробовать вынести ID в отдельную, небольшую таблицу.
Еще можно только вставлять данные и выбирать только с последним временем вставки. Хотя поиск для чтения будет медленным. Опять же партиционировать по времени вставки.
Средний
Простой
