Redis comme base de données

Question

Je veux utiliser Redis comme une base de données, pas comme un cache. D'après ma compréhension (limitée), Redis est un datastore en mémoire. Quels sont les risques liés à l'utilisation de Redis, et comment puis-je les atténuer ?

Answer 1

Vous pouvez utiliser Redis comme un magasin faisant autorité de plusieurs manières différentes :

• Allumez AOF (Magasin de fichiers en annexe seulement) voir les documents de l'AOF . Cela permettra de conserver un journal de toutes les commandes Redis effectuées sur votre ensemble de données en temps réel.

• Exécuter Redis en utilisant la réplication maître-esclave voir la documentation sur la réplication . Cela vous permettra d'assurer une haute disponibilité en cas de défaillance d'une de vos instances.

• Si vous utilisez quelque chose comme EC2, vous pouvez sauvegarder votre partition Redis en EBS pour fournir une autre couche de protection contre les pannes d'instance.

A l'horizon, il y a Cluster Redis - Il s'agit d'un moyen spécifique d'exécuter Redis d'une manière qui devrait contribuer à l'HA et à l'évolutivité. Cependant, elle n'apparaîtra pas avant au moins six mois.

Answer 2

Redis est un magasin en mémoire qui peut également réécrire les données sur le disque. Vous pouvez spécifier combien de fois il faut faire un fsync pour rendre redis plus sûr (mais aussi plus lent => compromis) .

Mais je ne suis pas certain que redis soit encore en état de stocker des données (de mission) critiques (encore ?). Si, par exemple, ce n'est pas un énorme problème quand 1 tweets de plus (twitter.com) ou quelque chose de similaire est perdu, alors j'utiliserais certainement redis. Il y a également beaucoup d'informations disponibles sur persistance sur le site de Redis.

Vous devez également savoir que quelques problèmes de persistance ce qui pourrait se produire en lisant l'article du blog d'antirez (mainteneurs de redis). Vous devriez lire son blog car il a des articles intéressants.

---

Answer 3

Comme Redis est un stockage en mémoire, vous ne pouvez pas stocker de grandes données qui ne correspondent pas à la taille de la mémoire de votre machine. Redis fonctionne généralement très mal lorsque les données qu'il stocke sont supérieures à 1/3 de la taille de la RAM. C'est donc la limite fatale de l'utilisation de Redis comme base de données.

Certes, vous pouvez distribuer vos données volumineuses dans plusieurs instances Redis, mais vous devez le faire manuellement. L'opération se déroule généralement comme suit (en supposant que vous n'ayez qu'une seule instance au départ) :

1. Utilisez son mécanisme maître-esclave pour répliquer les données sur la deuxième machine. Vous avez maintenant deux copies des mêmes données.
2. Coupez la connexion entre le maître et l'esclave.
3. Supprimez la première moitié (divisée par hachage, etc.) des données sur la première machine, et supprimez la seconde moitié des données sur la seconde machine.
4. Dites à tous les clients (PHP, C, etc...) de fonctionner sur la première machine si les clés spécifiées sont sur cette machine, sinon de fonctionner sur la seconde machine.

C'est la façon dont Redis s'adapte ! Vous devez également arrêter votre service pour empêcher toute écriture pendant la migration.

A l'expérience que nous rencontrons, nous avons cette conclusion à Redis : Redis n'est pas le bon choix pour stocker plus de 30G de données, Redis n'est pas extensible, Redis est plutôt adapté au développement de prototypes.

Nous trouverons plus tard une alternative à Redis, à savoir SSDB( https://github.com/ideawu/ssdb ), un serveur leveldb qui supporte presque toutes les APIs de Redis, il est approprié pour stocker plus de 1TB de données, cela dépend seulement de la taille de votre disque dur.

Answer 4

J'aimerais partager quelques éléments que nous avons appris en utilisant Redis comme base de données principale dans notre service. Nous avons choisi Redis car nous avions des données qui ne pouvaient pas être partitionnées. Nous voulions obtenir les meilleures performances possibles à partir d'un seul boîtier.

Pour :

• Redis était imbattable en termes de performances brutes. Nous avons obtenu 10 000 transactions par seconde (notez qu'une transaction implique plusieurs commandes Redis). Nous avons pu atteindre un taux de 25K+ transactions par seconde après quelques optimisations, ainsi que des LUA scripts. Donc, en ce qui concerne les performances par boîte, Redis est inégalé.
• Redis est très simple à configurer et sa courbe d'apprentissage est très faible par rapport aux autres bases de données SQL et NoSQL.

Cons :

• Redis ne supporte que quelques structures de données primitives comme les hachages, les ensembles, les listes, etc. et les opérations sur ces structures de données. Celles-ci sont plus que suffisantes lorsque vous utilisez Redis comme un cache, mais si vous voulez utiliser Redis comme un magasin de données primaire à part entière, vous vous sentirez limité. Nous avons eu du mal à modéliser nos besoins en données à l'aide de ces types simples.
• Le plus gros problème que nous avons rencontré avec Redis était le manque de flexibilité. Une fois que vous avez résolu la structure de vos données, toute modification des exigences de stockage ou des modèles d'accès nécessite pratiquement de repenser l'ensemble de la solution. Je ne suis pas sûr que ce soit le cas avec tous les magasins de données NoSQL (j'ai entendu dire que MongoDB était plus flexible, mais je ne l'ai pas utilisé moi-même).
• Comme Redis est monofilaire, l'utilisation du CPU est très faible. Vous ne pouvez pas placer plusieurs instances Redis sur la même machine pour améliorer l'utilisation du CPU, car elles se disputeraient le même disque, faisant du disque le goulot d'étranglement.
• Le manque d'extensibilité horizontale est un problème, comme le mentionnent d'autres réponses.