@aywan
Универсальная не боевая единица

Выбор бд для хранения списка, с быстрой записью и удалением элементов?

Существует некий объект А и существуют подписчики на изменение этотого объекта. Объект А может менятся очень часто (иногда даже чаще 1 раза в секунду), и поэтому выборка списка его подписчиков должна работать довольно быстро. Подписчики также могут довольно часто подписываться и отписывать на получение обновлений по любому из объектов.

На данный момент в системе не бывает одновременно больше чем 400 объектов А, а количество подписчиков не превышает 600 в среднем и 1000 в пике (ожидаем рост). Из практики будет получатся так, что на небольшое количество объектов А (<10%) будет подписаны большая часть клиентов (100%), в то время как на оставшиеся объекты подписки может и не быть вовсе.
Сообственно вопрос: в чем лучше всего это все хранить? какую структуру данных сделать? ну и что почитать, потестить?

Первое что приходит в голову взять Redis и по ключу идентификатору А.id хранить список идентификаторов подписчиков. Однако боюсь начнут возникать проблемы с изменением списка после очередной подписки/отписки.
Можно хранить все в традиционной РСУБД, но тогда будут тормаза при получении списка.

ps. На данный момент у нас такая реализация, что клиенты (подписчики) самы интерисуются переодически не поменялось ли чего. Вроде все не плохо, но иногда клиенты страдают от того что не вовремя получают информацию о изменениях. Ну и потом, хочется поэксперементировать.
pps. А может быть я все усложняю, и достаточно просто будет хранить все в отдельном приложении массивом в мапе, или что-ниубудь подобное. Хотя будет обидно если все это нечаяно упадет. Разрабатыватся вероятно будет на golang, так что подойдут варианты со встроенными решениями.
  • Вопрос задан
  • 651 просмотр
Пригласить эксперта
Ответы на вопрос 1
@laxikodeje
Tarantool, Redis - их производительности хватит за глаза.
Не будет никаких проблем, что вы боитесь.

Более того, если у вас Go и он не перезапускается на каждый чих - почему бы вам в самой программе на Go не хранить?
Ответ написан
Ваш ответ на вопрос

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

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