Насколько значительна разница в производительности между хранилищем в памяти и базой данных [закрыто]

Question

Закрыто.Этот вопрос должен быть более сосредоточенный.В настоящее время он не принимает ответы.

---

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он фокусировался только на одной проблеме. редактирование этого сообщения.

Закрыто 5 лет назад.

Я создаю приложение чата в signalr.В настоящее время он имеет некоторую функциональность по сохранению в базе данных для постоянного хранения сообщений.Я хочу реализовать списки пользователей и перечитываю эту статью:

http://www.asp.net/signalr/overview/signalr-20/hubs-api/mapping-users-to-connections#inmemory

Насколько существенна эта разница между хранилищем в памяти?Вероятность разницы более чем в секунду между, скажем, 1000 пользователей и 10 000 пользователей, отправляющих друг другу сообщения с нормальной скоростью, скажем, 1 сообщение в секунду (они съели много сахара)?И насколько это полезно?Будем очень признательны за любые ссылки на предыдущие тесты производительности.

Во-вторых, возможно, я делаю это неправильно, но если я хочу сохранить список пользователей и есть несколько чатов, я предполагаю, что мне понадобится отдельный словарь для каждой комнаты?И если да, то осуществимо ли это, поскольку я хочу, чтобы пользователи также могли создавать свои собственные комнаты.Я просто не понимаю, как таким образом можно добиться использования памяти.

Спасибо

Answer 1

Ненавижу давать единственную ссылку для ответа, но это полнофункциональный чат OSS. https://jabbr.net касается всего, что вас беспокоит.

Источник: https://github.com/jabbr/jabbr

Чтобы прокомментировать вашу основную проблему в памяти и в базе данных:БД добавляет возможность сохранять данные или даже масштабировать ваше приложение, НО НАМНОГО менее производительно, чем в памяти.Не поймите меня неправильно, хотя производительность НАМНОГО ниже, это не означает, что отправка сообщений займет несколько секунд, в зависимости от вашего приложения...Все дело в компромиссах.

Что касается применения архитектуры, ориентированной на БД, для 1000 или 10 000 пользователей, все зависит от того, как вы ее реализуете.Например, поставщик горизонтального масштабирования REDIS выполняет все операции в памяти, но затем через определенные промежутки времени сохраняется на диске.Очевидно, что это очень быстро, но допускает «некоторую» потерю данных.

Answer 2

Это не имеет прямого отношения к вашему первоначальному вопросу.

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

Вы не можете предсказать, когда будет перезагружен пул приложений (в целом вы можете вручную установить определенное время для перезапуска).Это может произойти как через несколько дней, так и через несколько часов.

В идеале вы хотите хранить в постоянном месте, например База данных.Если вас беспокоит производительность сохранения в базу данных, вы можете асинхронный задача сохранения базы данных.

Answer 3

Посмотрите это сравнение:

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparision/

Redis (в памяти) опережает MySQL (классический DB) Очевидно, что их области применения сильно различаются, поэтому мы не можем сказать, что в целом Redis лучше MySQL.Каждый программный проект — это отдельный мир, и в нем можно применить множество различных решений.В некоторых ситуациях Redis и MySQL используются вместе для разных частей платформы (например.Электронная коммерция Magento)

Вам решать, нужно ли вам решение в памяти или стандартная база данных.Я думаю, что пропускная способность 1 вставка в секунду может быть легко достигнута с помощью MySQL, но это всего лишь мнение.Я предлагаю вам написать реализацию вашего продукта, поддерживающую Redis:начните использовать MySQL, но используйте его через уровень абстракции, который адаптируется как к MySQL, так и к Redis (я не знаю, доступен ли такой уровень с открытым исходным кодом, но вы можете выпустить свой собственный...)