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

Question

[Popchik]

Итак, идея данного мессенджера заключается в том, что диалоги хранятся только локально на девайсах пользователей, на сервер ничего не уходит. На сервере же будет хранится только необходимая информация, без которой пользователи не смогут найти друг друга. Вопрос в том, какой же тип и логику лучше выбрать для бд с такой задачей, я в планировке бд не силен, хотелось бы услышать здравую критику и , конечно же, ответ на вопрос

Схема логики бд

Answer 1

[Александр Таратин]

Нафиг хранение ip пользователя.
Делайте сразу на основе WebRTC и проектируйте систему отталкиваясь от его возможностей. Тогда сможете в будущем без проблем сделать web клиенты которые тоже смогут использовать p2p.
Сервер же будет использоваться как прокси, когда оба (или если групповая переписка - все из группы) пользователя окажутся за непробиваемым NAT.
Естественно все передаваемые данные ассиметрично шифруем в любом случае.

Comments

[Popchik]

Почитал про NAT, можете ответить, он будет играть тут защитную роль ? И если да, то каким образом и как это лучше организовать ? Спасибо за ответ

[Александр Таратин]

Popchik, Никакой. Это проблема, которую вам придется решить, если будете делать все ручками и связывать клиентов на чистых сокетах. Придется попотеть, если оба окажутся за серыми ip адресами.
Для WebRTC существуют готовые пути решения Как преодолеть NAT (webrtc)? ну и в гугле куча информации.

Answer 2

[Владимир Владимирович]

то, что вы нарисовали не совсем схема данных. Да и не рисуют ее отрывками... ну я не встречал такого. Это у вас смешение диаграммы состояний системы и сущностей БД...

Answer 3

[Alexey]

Вы всё равно рано или поздно упретёсь в необходимость хранения истории на сервере. Для синхронизации, для мультилогина на разных девайсах. Юзеры заставят, проверено на своей шкуре :)

Для локальной базы - идеально SQLite, потому что она нативно уже есть и хорошо работает, а мощь взрослых СУБД вам тут не нужна. Структура - не принципиальна, зависит от ваших данных.

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

И максимально кешируйте всё в памяти. Работать напрямую с базой на сервере - потеря производительности. Опять же, я не знаю, сколько у вас будет онлайн, сложно сказать что-то определённое в этой ситуации.