Quel est l'intérêt de plusieurs bases de données Redis?
Je suis donc arrivé à un endroit où je voulais segmenter les données que je stocke dans redis dans des bases de données distinctes, car je dois parfois utiliser la commande keys sur un type de données spécifique, et je voulais les séparer pour les rendre plus rapides. .
Si je segmente en plusieurs bases de données, tout est toujours à thread unique et je n'ai toujours qu'un seul noyau. Si je lance simplement une autre instance de Redis sur la même boîte, je peux utiliser un noyau supplémentaire. En plus de cela, je ne peux pas nommer les bases de données Redis, ni leur donner d'identifiant plus logique. Cela dit, pourquoi et quand voudrais-je utiliser plusieurs bases de données Redis au lieu de créer une instance supplémentaire de Redis pour chaque base de données supplémentaire que je souhaite? Et dans le même esprit, pourquoi Redis n’essaie-t-il pas d’utiliser un noyau supplémentaire pour chaque base de données supplémentaire que j’ajoute? Quel est l'avantage d'être mono-thread sur plusieurs bases de données?
En principe, les bases de données Redis sur la même instance ne diffèrent pas des schémas des instances de base de données SGBDR.
Cela dit, pourquoi et quand voudrais-je utiliser plusieurs bases de données Redis au lieu de créer une instance supplémentaire de Redis pour chaque base de données supplémentaire que je souhaite?
L'utilisation des bases de données Redis dans la même instance Redis présente un avantage évident: la gestion. Si vous créez une instance distincte pour chaque application et supposons que vous avez 3 applications, il s'agit de 3 instances redis distinctes, dont chacune aura probablement besoin d'un esclave pour la haute disponibilité en production, soit un total de 6 instances. Du point de vue de la gestion, cela devient vite compliqué, car vous devez tous les surveiller, effectuer des mises à niveau/des correctifs, etc. Si vous ne prévoyez pas de surcharger Redis avec des E/S élevées, une instance unique avec un esclave est plus simple et plus simple. plus facile à gérer à condition de respecter votre contrat de niveau de service.
Vous ne voulez pas utiliser plusieurs bases de données dans une seule instance Redis. Il est obsolète et, comme vous l'avez indiqué, plusieurs instances vous permettent de tirer parti de plusieurs cœurs. Si vous utilisez la sélection de base de données, vous devrez refactoriser lors de la mise à niveau. Surveiller et gérer plusieurs instances n'est ni difficile ni douloureux.
En effet, vous obtiendriez de bien meilleures métriques sur chaque base de données en les séparant par instance. Chaque instance aurait des statistiques reflétant ce segment de données, ce qui pourrait permettre un meilleur réglage et une surveillance plus réactive et précise. Utilisez une version récente et séparez vos données par instance.
Comme Jonaton l'a dit, n'utilisez pas la commande keys. Vous obtiendrez de bien meilleures performances si vous créez simplement un index clé. Chaque fois que vous ajoutez une clé, ajoutez le nom de la clé à un jeu. La commande keys n’est pas très utile une fois que vous avez fait l’échelle, car le retour prendra beaucoup de temps.
Laissez le modèle d'accès déterminer comment structurer vos données plutôt que de le stocker de la façon dont vous pensez le faire, puis de chercher à savoir comment y accéder et le mâcher plus tard. Vous constaterez de bien meilleures performances et constaterez que le code consommateur de données est souvent plus simple et plus propre.
En ce qui concerne les threads simples, considérez que redis est conçu pour la vitesse et l’atmicité. Certaines actions de modification de données dans une base de données n'ont pas besoin d'attendre une autre base de données, mais que se passe-t-il si cette action est enregistrée dans le fichier de vidage ou si des transactions sont traitées sur des esclaves? À ce stade, vous commencez à vous lancer dans les mauvaises herbes de la programmation simultanée.
En utilisant plusieurs instances, vous transformez la complexité du multi-threading en un système de style de transmission de messages plus simple.
Même Salvatore Sanfilippo (créateur de Redis) pense que l’utilisation de plusieurs bases de données dans Badis est une mauvaise idée. Voir son commentaire ici:
https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion
Je comprends en quoi cela peut être utile, mais malheureusement, je considère Redis comme une pire décision en matière de conception de Redis: de multiples erreurs de base de données ... sans aucun gain réel, cela rend les internes beaucoup plus complexes. La réalité est que les bases de données ne sont pas bien dimensionnées pour diverses raisons, telles que l'expiration active des clés et des machines virtuelles. Si la sélection de base de données peut être effectuée avec une chaîne, je peux voir que cette fonctionnalité est utilisée comme couche de dictionnaire évolutive O(1), ce n'est pas le cas.
Avec les numéros de base de données, avec quelques bases par défaut, nous communiquons mieux en quoi consiste cette fonctionnalité et comment elle peut être utilisée, je pense. J'espère qu'à un moment donné, nous pourrons supprimer complètement le support des bases de données, mais je pense qu'il est probablement trop tard, car de nombreuses personnes comptent sur cette fonctionnalité pour leur travail.
Je ne connais pas vraiment les avantages d'avoir plusieurs bases de données sur une seule instance. J'imagine que c'est utile si plusieurs services utilisent le même serveur de base de données afin d'éviter les conflits de clés.
Je ne recommanderais pas d'utiliser la commande
KEYS, car c'est O(n)) et cela ne s'adapte pas bien. Qu'est-ce que vous utilisez pour cela? Peut-être que redis n'est pas la meilleure solution pour vous si une fonctionnalité commeKEYSest essentielle.Je pense qu'ils mentionnent les avantages d'un serveur à thread unique dans leur FAQ, mais le principal est la simplicité - vous n'avez pas à vous soucier de l'accès simultané de manière réelle. Chaque action est bloquante, donc deux choses ne peuvent pas modifier la base de données en même temps. Idéalement, vous devriez avoir une (ou plusieurs) instances par cœur de chaque serveur et utiliser un algorithme de hachage cohérent (ou un proxy) pour diviser les clés entre eux. Bien sûr, vous perdrez certaines fonctionnalités - la tuyauterie ne fonctionnera que sur le même serveur, les tris deviennent plus difficiles, etc.
Les bases de données Redis peuvent être utilisées dans les rares cas de déploiement d'une nouvelle version de l'application, où la nouvelle version nécessite de travailler avec différentes entités.
J'utilise redis pour mettre en place une liste noire d'adresses e-mail et j'ai des valeurs TTL) différentes pour différents niveaux de liste noire. Avoir différentes bases de données sur la même instance m'aide beaucoup.
L'utilisation de plusieurs bases de données dans une seule instance peut être utile dans le scénario suivant:
Différentes copies de la même base de données pourraient être utilisées pour la production, le développement ou les tests à l'aide de données en temps réel. Les personnes peuvent utiliser réplica pour cloner une instance redis dans le même but. Cependant, la première approche est plus facile pour les programmes en cours d’exécution qui choisissent la bonne base de données pour passer au mode souhaité.