Toutes les réponses (au moment d'écrire ces lignes) supposent que Redis, MongoDB et peut-être une base de données relationnelle basée sur SQL sont essentiellement le même outil: "stocker des données". Ils ne considèrent pas du tout les modèles de données.
MongoDB: données complexes
MongoDB est un magasin de documents. Pour comparer avec une base de données relationnelle basée sur SQL: les bases de données relationnelles se simplifient en fichiers CSV indexés, chaque fichier étant une table; les magasins de documents se simplifient en fichiers JSON indexés, chaque fichier étant un document, plusieurs fichiers étant regroupés.
Les fichiers JSON sont similaires dans leur structure aux fichiers XML et YAML et aux dictionnaires comme en Python, alors pensez à vos données dans ce type de hiérarchie. Lors de l'indexation, la structure est la clé: un document contient des clés nommées, qui contiennent soit d'autres documents, des tableaux ou des valeurs scalaires. Considérez le document ci-dessous.
{
_id: 0x194f38dc491a,
Name: "John Smith",
PhoneNumber:
Home: "555 999-1234",
Work: "555 999-9876",
Mobile: "555 634-5789"
Accounts:
- "379-1111"
- "379-2574"
- "414-6731"
}
Le document ci-dessus a une clé PhoneNumber.Mobile, qui a une valeur 555 634-5789. Vous pouvez rechercher dans une collection de documents où la clé,, PhoneNumber.Mobilea une certaine valeur; ils sont indexés.
Il a également un tableau Accountsqui contient plusieurs index. Il est possible d'interroger un document Accountscontenant exactement un sous-ensemble de valeurs, tous certains sous-ensembles de valeurs ou l'un quelconque des sous-ensembles de valeurs. Cela signifie que vous pouvez rechercher Accounts = ["379-1111", "379-2574"]et ne pas trouver ce qui précède; vous pouvez rechercher Accounts includes ["379-1111"]et trouver le document ci-dessus; et vous pouvez rechercher Accounts includes any of ["974-3785","414-6731"]et trouver ce qui précède et tout document comprenant le compte "974-3785", le cas échéant.
Les documents vont aussi loin que vous le souhaitez. PhoneNumber.Mobilepourrait contenir un tableau, ou même un sous-document ( PhoneNumber.Mobile.Worket PhoneNumber.Mobile.Personal). Si vos données sont très structurées, les documents constituent une avancée importante par rapport aux bases de données relationnelles.
Si vos données sont principalement plates, relationnelles et structurées de manière rigide, vous feriez mieux avec une base de données relationnelle. Encore une fois, le grand signe est de savoir si vos modèles de données conviennent le mieux à une collection de fichiers CSV interdépendants ou à une collection de fichiers XML / JSON / YAML.
Pour la plupart des projets, vous devrez faire des compromis, en acceptant une solution de contournement mineure dans certaines petites zones où SQL ou les magasins de documents ne correspondent pas; pour certains grands projets complexes stockant une large diffusion de données (de nombreuses colonnes; les lignes ne sont pas pertinentes), il sera judicieux de stocker certaines données dans un modèle et d'autres données dans un autre modèle. Facebook utilise à la fois SQL et une base de données graphique (où les données sont placées dans les nœuds et les nœuds sont connectés à d'autres nœuds); Craigslist utilisait auparavant MySQL et MongoDB, mais cherchait à passer entièrement sur MongoDB. Ce sont des endroits où l'étendue et la relation des données sont confrontées à des handicaps importants si elles sont regroupées sous un même modèle.
Redis: valeur-clé
Redis est, fondamentalement, un magasin de valeurs-clés. Redis vous permet de lui donner une clé et de rechercher une seule valeur. Redis lui-même peut stocker des chaînes, des listes, des hachages et quelques autres choses; cependant, il ne recherche que par son nom.
L'invalidation du cache est l'un des problèmes difficiles de l'informatique; l'autre nomme des choses. Cela signifie que vous utiliserez Redis lorsque vous souhaitez éviter des centaines de recherches excessives sur un back-end, mais vous devrez déterminer quand vous avez besoin d'une nouvelle recherche.
Le cas d'invalidation le plus évident est la mise à jour à l'écriture: si vous lisez user:Simon:lingots = NOTFOUND, vous pouvez SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simonet stocker le résultat 100, comme SET user:Simon:lingots = 100. Ensuite , lorsque vous accordez Simon 5 Lingots, vous avez bien lu user:Simon:lingots = 100, SET user:Simon:lingots = 105et UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Vous en avez maintenant 105 dans votre base de données et dans Redis, et vous pouvez obtenir user:Simon:lingotssans interroger la base de données.
Le deuxième cas est la mise à jour des informations dépendantes. Disons que vous générez des morceaux d'une page et mettez en cache leur sortie. L'en-tête montre l'expérience, le niveau et le montant d'argent du joueur; la page de profil du joueur a un bloc qui montre leurs statistiques; et ainsi de suite. Le joueur gagne de l'expérience. Eh bien, maintenant vous avez plusieurs templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simonet ainsi de champs de suite où vous avez mis en cache la sortie d'une base de données des requêtes demi-douzaine passent par un moteur de template. Normalement, lorsque vous affichez ces pages, vous dites:
$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
$t = BuildTemplate("StatsBox.tmpl",
GetStatsFromDatabase($playerName));
SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;
Étant donné que vous venez de mettre à jour les résultats de GetStatsFromDatabase("Simon"), vous devez abandonner templates:*:Simonvotre cache de valeurs-clés. Lorsque vous essayez de rendre l'un de ces modèles, votre application supprimera la récupération des données de votre base de données (PostgreSQL, MongoDB) et l'insérera dans votre modèle; il stockera ensuite le résultat dans Redis et, espérons-le, ne prendra pas la peine de faire des requêtes de base de données et des modèles de rendu la prochaine fois qu'il affichera ce bloc de sortie.
Redis vous permet également de faire des files d'attente de messages d'abonnement à l'éditeur et autres. C'est un tout autre sujet. Le point ici est que Redis est un cache de valeurs-clés, qui diffère d'une base de données relationnelle ou d'un magasin de documents.
Conclusion
Choisissez vos outils en fonction de vos besoins. Le plus grand besoin est généralement un modèle de données, car cela détermine la complexité et le risque d'erreur de votre code. Les applications spécialisées s'appuieront sur les performances, des endroits où vous écrivez tout dans un mélange de C et d'assemblage; la plupart des applications se contentent de gérer le cas généralisé et utilisent un système de mise en cache tel que Redis ou Memcached, qui est beaucoup plus rapide qu'une base de données SQL hautes performances ou un magasin de documents.