@xaker01
Лень все лень.

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

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

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

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

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

UPD: AerospikeDB тоже позволяет сохранить готовые процедуры, так что его функционала хватит для вышеуказанной задачи.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
rozhnev
@rozhnev
Fullstack programmer, DBA, медленно, дорого
Исхлдя из того что я понял из вопроса, вы делаете два запроса в базу: поиск и затем обновление. Это можно сделать одним запросом тем самым существенно снизив нагрузку
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Подходит любая БД. Вопрос в том чем вы готовы пожертвовать ради скорости. Например вы можете хранить данные в backend (hashtable) и сбрасывать их в БД периодически. Эта схема идеально работает. Вам только надо с самим собой и с бизнесом поговорить о гарантиях. Что вы хотите? Чтоб любой вектор {id, data, user_date} сохранялся в ту-же микросекунду или вы можете эти изменения отложить на потом и применить их в БД через 15 минут например в виде
batch-update.

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


Договаривайтесь с ценностью бизнес-информацией и с компромиссами.
Ответ написан
Комментировать
@Bwana
Для указанной вами задачи (получение записи по вторичному ключу и ее изменение в режиме ACID) нет смысла использовать RDBMS. Рассмотрите использование собственного простого протокола поверх BerkeleyDB или аналогичной DB.
Ответ написан
Комментировать
firedragon
@firedragon
Не джун-мидл-сеньор, а трус-балбес-бывалый.
Что то вы делаете не так.
если есть индекс по used_date

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

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

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

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