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

Question

[Иван Брагин]

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

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

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

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

Comments

[sim3x]

хранить все в традиционной РСУБД, но тогда будут тормаза при получении списка.

почему?

[Иван Брагин]

sim3x: С тормазами наверное преувеличил.

[uvelichitel]

Так в redis есть pub/sub, а в традиционной РСУБД вроде нет, по крайней мере не во всякой есть.

Answer 1

[laxikodeje]

Tarantool, Redis - их производительности хватит за глаза.
Не будет никаких проблем, что вы боитесь.

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

Comments

[chupasaurus]

Слышали по персистентные данные и резервное хранение? Думаю что список подписчиков должен храниться в них. Если хост, обрабатывающий подписки не один, то как их синхронизировать?

[laxikodeje]

chupasaurus: Посмотрите архитектуру Тарантула, к примеру.
ВСЕ хранит в оперативной памяти.
Но при этом умудряется быть ПЕРСИСТЕНТНЫМ.
;)

[chupasaurus]

laxikodeje: Я про вторую часть вашего ответа. Как работают In-memory DBs прекрасно знаю.

[laxikodeje]

chupasaurus:
Вряд ли вы действительно "прекрасно знаете"

Вы даже неправильно термины употребляете

Не DBs, а DBMS
А DB - это сами данные.

Ну и персистентные in-memory DBMS - это не типичные in-memory DBMS.

[laxikodeje]

chupasaurus:
В чем проблема обеспечения персистентности в Go?
Он не умеет писать на диск?

Я вам уже дал намек - посмотрите архитектуру Тарантула.

На Хабре есть прекрасные статьи.
Про Тарантул.

Там разжевано как можно обеспечивать персистентность (да еще без потери производительности) при работе In-Memory DBMS

На нагрузках миллионов пользователей в Mail.Ru

[laxikodeje]

chupasaurus:

Если хост, обрабатывающий подписки не один, то как их синхронизировать?

Вы постановку задачи читали?

Зачем на 400 объектов (1000 в пике) еще и второй хост??????????????????????????????

Я вас уверяю: без лишнего звена СУБД сервис на Go будет летать. Не понадобится никакой второй-третий и пр. доп. сервера.

https://habrahabr.ru/post/282299/

Причем этот тест Golang VS In-Memory DBMS.
С классической дисковой - было бы еще хуже.

P.S:

Чем вас спасет СУБД? Кроме доп. тормозов.
Их синхронизировать не так просто. Еще накладные расходы.

[chupasaurus]

laxikodeje: Откройте Википедию, вбейте в поле поиска In-memory database, удивитесь тому, что это устоявшийся термин.

Окей, всеведущий, поведуй мне, как синхронизировать состояние данных в памяти программы на golang для N>2 изолированных физически узлов.
Подозреваю, что оверхед и стоимость добавления в архитектуру редиса/memcached/... меньше, чем реализация того же функционала с нуля.

Как у вас с теорией графов? Каждая ветвь - отдельный объект, в графе из задачи их больше 24.000 сейчас.
СУБД спасает, снимая головную боль хранения и синхронизации данных.

[laxikodeje]

chupasaurus:

Ты сейчас начинаешь притягивать за уши условия работы, которые никогда не возникнут на обсуждаемой задаче.


А че - давайте для всякого мелкопроекта теперь будем свою службу оркестрации микросервисов разворачивать.

Мы же модную архитектуру узнали недавно - распараллеливание для множества узлов. Теперь ее нужно внедрять туда куда надо и куда не надо.

P.S.:
Такие как ты нудят, что современные программы - монстры, что Винда и Убунту жиреют и жиреют.

А когда дело доходит до их собственного софта - реализуют ПРОСТЕЙШИЕ вещи все столь же монстроидальными методами.

P.S.:
Я вас уверяю, сделать надежную синхронизацию средствами Redis/Tarantool - тоже нужно мозгами пошевелить.

[laxikodeje]

Как у вас с теорией графов? Каждая ветвь - отдельный объект, в графе из задачи их больше 24.000 сейчас.

Что у вас с ПРАКТИКОЙ?

Вы в курсе, что графы довольно плохо ложатся на архитектуру распространенных СУБД?

Да, есть специальные иерархические СУБД, но вы хоть раз в жизни такую лично видели? Используют для всех задач универсальные РСУБД или всяческие key-value и т.п. Но не специализированные иерархические.

Реализовывать в РСУБД или в Tarantool/Redis полноценную работу с графами - это куча кода, и не оптимально по быстродействию.

Насчет этого "страшного" количества - 24000. Вы видимо, в прошлом учебном году ознакомились с областью АРИФМЕТИКИ, называемой комбинаторикой и теперь вам нравится все считать? Но опять таки, если мы вернемся к ПРАКТИКЕ - 24000 это не 24 млн.. Для современных компьютеров - такое количество объектов ерунда, это всего лишь мелкая доля секунды их работы.