Quelle est l'importance de la différence de performances entre le stockage en mémoire et en base de données [fermé]

Question

Fermé.Cette question doit être plus concentré.Il n'accepte actuellement pas de réponses.

---

Vous voulez améliorer cette question? Mettez à jour la question pour qu'elle se concentre sur un seul problème en modifier ce message.

Fermé il y a 5 ans.

Je crée une application de chat dans signalr.Il a actuellement quelques fonctionnalités avec le stockage dans une base de données pour le stockage permanent des messages.Je souhaite implémenter des listes d'utilisateurs et j'ai relu cet article:

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

Quelle est l'importance de cette différence entre le stockage en mémoire?Y a-t-il probablement plus d'une seconde de différence entre, disons, 1000 utilisateurs et 10 000 utilisateurs qui s'envoient des messages à un rythme normal de 1 msg par seconde (ils ont bu beaucoup de sucre)?Et à quel point est-ce utile?Toute référence à des tests antérieurs sur les performances serait extrêmement appréciée.

Deuxièmement, je vais peut-être dans le mauvais sens, mais si je veux stocker une liste d'utilisateurs et qu'il y a plusieurs salles de discussion, je suppose que j'aurai besoin d'un dictionnaire séparé par salle?Et si oui, est-ce faisable puisque je veux que les utilisateurs puissent également générer leurs propres salles.Je ne vois tout simplement pas comment l'in-memory peut être réalisé de cette façon.

Merci

Answer 1

Je déteste fournir un seul lien pour une réponse, mais cette salle de discussion entièrement fonctionnelle est disponible https://jabbr.net répond à tout ce qui vous inquiète.

Sources: https://github.com/jabbr/jabbr

Pour commenter votre principale préoccupation en mémoire par rapport à la base de données:DB ajoute la possibilité de conserver les données ou même de faire évoluer votre application, MAIS est BEAUCOUP moins performant qu'en mémoire.Maintenant, ne vous méprenez pas, même si c'est BEAUCOUP moins performant, cela ne signifie pas qu'il faudra quelques secondes pour envoyer des messages en fonction de votre application...Tout est une question de compromis.

Quant à l'application d'une architecture orientée base de données à 1000 vs 10 000 utilisateurs, tout dépend de la façon dont vous l'implémentez.Par exemple, le fournisseur de mise à l'échelle REDIS exécute tout en mémoire, mais persiste ensuite sur le disque à intervalles réguliers.Ceci est évidemment extrêmement rapide mais permet "une certaine" perte de données.

Answer 2

Ce n'est pas directement lié à votre question initiale.

Je pense que vous ne pouvez pas les enregistrer dans un stockage en mémoire. Le problème est que si le pool d'applications est recyclé, tous les messages stockés en mémoire auront disparu.

Vous ne pouvez pas prédire quand le pool d'applications sera recyclé (au total, vous pouvez définir manuellement une heure spécifique de recyclage).Cela peut arriver en quelques jours ou quelques heures.

Idéalement, vous souhaitez stocker dans un emplacement persistant comme Base de Données.Si vous vous inquiétez des performances de l'enregistrement dans la base de données, vous pouvez asynchrone la tâche d'enregistrement de la base de données.

Answer 3

Découvrez cette comparaison:

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

Redis (en mémoire) surpasse MySQL (base de données classique) Évidemment, leurs domaines d'application sont fortement différents, donc on ne peut pas dire qu'en général, Redis soit meilleur que MySQL.Chaque projet logiciel est son propre monde, et de nombreuses solutions différentes peuvent être appliquées.Dans certaines situations, Redis et MySQL sont utilisés ensemble pour différentes parties d'une plate-forme (par ex.Commerce électronique Magento)

C'est à vous d'évaluer si vous avez besoin d'une solution en mémoire ou d'une base de données standard.Je pense qu'un débit de 1 insertion/seconde peut être atteint facilement via MySQL, mais ce n'est qu'un avis.Je vous suggère d'écrire une implémentation de votre produit qui soit "Redis aware":commencez à utiliser MySQL, mais utilisez-le via une couche d'abstraction qui s'adapte à la fois à MySQL et à Redis (je ne sais pas si une telle couche est disponible en open source, mais vous pouvez publier la vôtre...)