Redis en tant que base de données
je veux utiliser Redis comme base de données, pas comme cache. De ma compréhension (limitée), Redis est un datastore mémoire. Quels sont les risques de l'utilisation de Redis, et comment les atténuer?
4 réponses
vous pouvez utiliser Redis comme un magasin faisant autorité de plusieurs façons:
-
Turn on AOF (Append-only File store) voir AOF docs . Cela maintiendra un journal de toutes les commandes Redis faites par rapport à votre ensemble de données en temps réel.
-
Exécuter Redis à l'aide de la réplication Maître-Esclave voir la réplication docs . Cela vous permettra de fournir une haute disponibilité si l'une de vos instances échoue.
-
si vous utilisez quelque chose comme EC2, vous pouvez récupérer votre partition Redis pour fournir une autre couche de protection contre la défaillance d'une instance.
À l'horizon Redis Cluster - ce qui est spécifiquement conçu comme un moyen d'exécuter Redis d'une manière qui devrait aider avec HA et d'évolutivité. Toutefois, cela ne semble pas pour au moins six mois.
Redis est une mémoire de stockage qui peut également écrire les données sur disque. Vous pouvez spécifier le nombre de fois pour faire un fsync pour rendre le redis plus sûr(mais aussi plus lent => trade-off) .
mais je ne suis toujours pas certain si redis est en état de stocker (encore?). Si par exemple ce n'est pas un gros problème quand 1 plus de tweets(twitter.com) ou quelque chose de similaire obtenir des pertes alors je voudrais certainement utiliser redis. Il y a aussi un beaucoup d'informations disponibles sur persistance sur le site Web de redis.
Vous devriez aussi être conscient de une certaine persistance des problèmes qui pourrait se produire par la lecture antirez(redis responsables) article de blog. Vous devriez lire son blog parce qu'il a quelques articles intéressants.
comme Redis est un stockage en mémoire, vous ne pouvez pas stocker de grandes données qui ne correspondront 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 est plus grand que 1/3 de la taille de la mémoire vive. C'est donc la limitation fatale de L'utilisation de Redis comme base de données.
Certes, vous pouvez distribuer vos big data dans plusieurs instances Redis, mais vous devez le faire vous-même manuellement. L'opération se fait habituellement comme ceci (en supposant que vous n'avez qu'une seule instance de démarrer):
- utilisez son mécanisme maître-esclave pour répliquer des données à la deuxième machine, maintenant vous avez 2 copies des mêmes données.
- coupe le lien entre maître et esclave.
- Supprimer le premier semestre(répartition par hachage, etc.) des données sur la première machine, et de supprimer la deuxième moitié de données sur la deuxième machine.
- dire à tous les clients(PHP, C, etc...) pour fonctionner sur la première machine si la les clés spécifiées sont sur cette machine, sinon fonctionnent sur la seconde machine.
C'est ainsi que Redis balance! Vous devez également arrêter votre service pour éviter toute écriture pendant la migration.
a l'expience 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 évolutif, Redis est tout à fait adapté pour le développement de prototypes.
nous trouvons plus tard une alternative à Redis, C'est SSDB ( https://github.com/ideawu/ssdb ), un serveur leveldb qui supporte presque tous les API de Redis, il est adapté pour stocker plus de 1 To de données, Cela dépend seulement de la taille de votre disque dur.
j'aimerais vous faire part de certaines choses que nous avons apprises 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 la meilleure performance que nous puissions obtenir d'une boîte
Pour:
- Redis était imbattable dans la performance brute. Nous avons obtenu 10K transactions par seconde de la boîte (notez qu'une transaction impliquait plusieurs Redis) commande.) Nous avons pu atteindre un taux de 25k+ transactions par seconde après quelques optimisations, avec des scripts LUA. Ainsi, en ce qui concerne la performance par boîte, Redis est inégalée.
- Redis est très simple à configurer et a une très petite courbe d'apprentissage par rapport aux autres datastores SQL et NoSQL.
Inconvénients:
- Redis supporte seulement quelques Structures de données primitives comme les hachures, Ensembles, Listes, etc. et les opérations sur ces Structures de données. Celles-ci sont plus que suffisantes lorsque vous utilisez Redis comme cache, mais si vous voulez utiliser Redis comme un stock de données primaires complet, vous vous sentirez contraint. Nous avons eu de la difficulté à modéliser nos besoins en données en utilisant ces types simples.
- le plus grand problème que nous avons vu 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 modèles d'accès pratiquement nécessite de repenser l'ensemble de la solution. Je ne suis pas sûr que ce soit le cas avec toutes NoSQL data stores (J'ai entendu que MongoDB est plus flexible, mais je ne l'ai pas utilisé moi-même)
- comme le Redis est fileté simple, L'utilisation du CPU est très faible. Vous ne pouvez pas mettre plusieurs instances Redis sur la même machine pour améliorer l'utilisation du CPU car elles seront en concurrence pour le même disque, faisant du disque comme le goulot d'étranglement.
- manque d'horizontale l'évolutivité est un problème mentionné dans d'autres réponses.