Какая база данных подходит для частых UPDATE и сортировки?

Question

[Виктор Батиенко]

В базе данных есть очень нагруженная таблица примерно с 1-3млн записями.
Для упрощения в ней есть данные
id|data|used_date

backend обращается к базе данных получает строку отсортированной по used_date ( получаем строку по самой старой дате)
и делает update для нее вставляя текущее время. (пока выполняет операция select + update запись блокируется чтоб другой не мог ее получить и обновить)

Какая база больше подходит для такой задачи,
в данный момент все крутится на postgresql и 16ядер CPU еле справляются с нагрузкой

Answer 1

[Eugene Usachev]

Если я правильно понял суть вопроса, вам подойдёт любая KV СУБД. Вынесите только эту таблицу в какой-нибудь Tarantool или Redis (я имею в виду использовать хранимые процедуры для вашей задачи). 1-3 млн записей - относительно немного. Даже если одна запись весит 4 КБ, все данные займут 4-12 ГБ ОЗУ, что не так уж и много. Если использовать батчинг, что Redis, что Tarantool дадут вам на 16 ядрах свыше 100к RPS на такие сложные запросы.

Можете так же глянуть AerospikeDB (хранит данные на диске, но с индексами в памяти, где один индекс стоит 64 байт), но я не уверен, что вам хватит его функционала. Если вы дадите больше контекста, возможно, я смогу предложить вам другие идеи.

UPD: AerospikeDB тоже позволяет сохранить готовые процедуры, так что его функционала хватит для вышеуказанной задачи.

Comments

[Виктор Батиенко]

Спасибо решил свою задачу.
Оставлю решение на будущее для тех кто тоже ищет решение:

Использовал REDIS тип списки
Из нужной таблицы выгружаем все ID в список
дальше используем lpop - удалить и получить элемент сначала списка
сразуже за ним rpush -- помешаем эту же запись в конец списка
Решаем проблему сортировки по used_date (updated_at)
Получается механизм очередей, но при этом все происходить очень быстро.

Дальше уже делаем get по id в нашу базу и получаем информацию и делаем все что нужно.
дублей ( повторных получений записи при 10000 одновременных запросах не обнаружено)
Тест проводился на 52 млн записях ( хотя нужно было для 1 млн, но при первой попытке задублировал все данные)

Answer 2

[Slava Rozhnev]

Исхлдя из того что я понял из вопроса, вы делаете два запроса в базу: поиск и затем обновление. Это можно сделать одним запросом тем самым существенно снизив нагрузку

Answer 3

[mayton2019]

Подходит любая БД. Вопрос в том чем вы готовы пожертвовать ради скорости. Например вы можете хранить данные в backend (hashtable) и сбрасывать их в БД периодически. Эта схема идеально работает. Вам только надо с самим собой и с бизнесом поговорить о гарантиях. Что вы хотите? Чтоб любой вектор {id, data, user_date} сохранялся в ту-же микросекунду или вы можете эти изменения отложить на потом и применить их в БД через 15 минут например в виде
batch-update.

Поэтому вопрос оптимизации БД - это вопрос не только технически но и организационный. А запись в Postgress в через длинный сетевой стек да еще и с фиксацией транзакции это такое яростное безкомпромиссное решение
которое не всегда и нужно.

Договаривайтесь с ценностью бизнес-информацией и с компромиссами.

Answer 4

[Bwana]

Для указанной вами задачи (получение записи по вторичному ключу и ее изменение в режиме ACID) нет смысла использовать RDBMS. Рассмотрите использование собственного простого протокола поверх BerkeleyDB или аналогичной DB.

Answer 5

[Владимир Коротенко]

Что то вы делаете не так.
если есть индекс по used_date

а я подозреваю что его нет, то базе вообще параллельно.

Если же он есть (что странно) сделайте какую нибудь key value базу и периодически сбрасывайте из нее значения в БД