Quel est l'intérêt de plusieurs bases de données Redis?

Donc, je suis arrivé à un endroit où je voulais segmenter les données que je stocke dans Redis dans des bases de données séparées car j'ai parfois besoin d'utiliser la commande de touches sur un type spécifique de données, et je voulais les séparer pour le rendre plus rapide .

Si je segmente en plusieurs bases de données, tout est toujours à un seul thread et je ne peux toujours utiliser qu'un seul noyau. Si je lance juste une autre instance de Redis sur la même boîte, j'utilise un noyau supplémentaire. En plus de cela, je ne peux pas nommer les bases de données Redis, ni leur donner une sorte d'identifiant plus logique. Donc, avec tout cela dit, pourquoi / quand voudrais-je utiliser plusieurs bases de données Redis au lieu de simplement créer une instance supplémentaire de Redis pour chaque base de données supplémentaire que je veux? Et dans le même ordre d'idées, pourquoi Redis n'essaye-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'avoir un seul thread sur les bases de données?

En principe, les bases de données Redis sur la même instance ne sont pas différentes des schémas dans les instances de base de données SGBDR.

Donc, avec tout cela dit, pourquoi / quand voudrais-je utiliser plusieurs bases de données Redis au lieu de simplement créer une instance supplémentaire de Redis pour chaque base de données supplémentaire que je veux?

Il y a un avantage évident à utiliser les bases de données redis dans la même instance redis, c'est la gestion. Si vous créez une instance distincte pour chaque application, et disons 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 6 instances au total. Du point de vue de la gestion, cela devient très vite compliqué car vous devez les surveiller tous, faire des mises à niveau / correctifs, etc. Si vous ne prévoyez pas de surcharger les redis avec des E / S élevées, une seule instance avec un esclave est plus simple et plus facile à gérer à condition qu'il respecte votre SLA.

Vous ne souhaitez pas utiliser plusieurs bases de données dans une seule instance Redis. Il est obsolète et, comme vous l'avez noté, 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. La surveillance et la gestion de plusieurs instances ne sont ni difficiles ni douloureuses.

En effet, vous obtiendrez de bien meilleures métriques sur chaque base de données par ségrégation basée sur l'instance. Chaque instance aurait des statistiques reflétant ce segment de données, ce qui peut 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 l'a dit Jonaton, n'utilisez pas la commande keys. Vous trouverez 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 ensemble. La commande par touches n'est pas très utile une fois que vous passez à l'échelle, car il faudra beaucoup de temps pour revenir.

Laissez le modèle d'accès déterminer comment structurer vos données plutôt que de les stocker comme vous le pensez, puis travailler sur la façon d'y accéder et de les hacher plus tard. Vous verrez de bien meilleures performances et découvrirez que le code consommateur de données est souvent beaucoup plus propre et plus simple.

En ce qui concerne le filetage unique, considérez que redis est conçu pour la vitesse et l'atomicité. Bien sûr, les actions modifiant des 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 enregistre dans le fichier de vidage ou traite des transactions sur des esclaves? À ce stade, vous commencez à vous plonger dans les mauvaises herbes de la programmation simultanée.

En utilisant plusieurs instances, vous transformez la complexité multi-threads en un système de style de transmission de messages plus simple.

Même Salvatore Sanfilippo (créateur de Redis) pense que c'est une mauvaise idée d'utiliser plusieurs bases de données dans Redis. Voir son commentaire ici:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Je comprends à quel point cela peut être utile, mais malheureusement, je considère que les multiples erreurs de base de données Redis sont ma pire décision dans la conception Redis ... sans aucun gain réel, cela rend les éléments internes beaucoup plus complexes. La réalité est que les bases de données ne s'adaptent pas bien pour un certain nombre de raisons, comme 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 O (1) évolutive, mais ce n'est pas le cas.

Avec les numéros de DB, avec un défaut de quelques DB, nous communiquons mieux ce qu'est cette fonctionnalité et comment peut être utilisée je pense. J'espère qu'à un moment donné, nous pourrons abandonner le support de plusieurs bases de données, mais je pense qu'il est probablement trop tard car un certain nombre de personnes se fient à cette fonctionnalité pour leur travail.

1. Je ne connais pas vraiment les avantages d'avoir plusieurs bases de données sur une seule instance. Je suppose que c'est utile si plusieurs services utilisent le (s) même (s) serveur (s) de base de données, afin d'éviter les collisions de clés.

2. Je ne recommanderais pas de construire autour de la KEYScommande, car c'est O (n) et cela ne s'adapte pas bien. Pourquoi l'utilisez-vous et que vous pouvez accomplir d'une autre manière? Peut-être que redis n'est pas la meilleure solution pour vous si des fonctionnalités telles que KEYSsont vitales.

3. Je pense qu'ils mentionnent les avantages d'un serveur à thread unique dans leur FAQ, mais l'essentiel est la simplicité - vous n'avez pas à vous soucier de la concurrence 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 auriez 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 elles. Bien sûr, vous perdrez certaines fonctionnalités - la tuyauterie ne fonctionnera que pour les choses sur le même serveur, les tris deviennent plus difficiles, etc.

J'utilise redis pour implémenter une liste noire d'adresses e-mail, et j'ai différentes valeurs TTL pour différents niveaux de liste noire, donc avoir différents DB sur la même instance m'aide beaucoup.

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.

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 en utilisant des données en temps réel. Les utilisateurs peuvent utiliser une réplique 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 existants de sélectionner simplement la bonne base de données pour passer au mode prévu.

Je sais que cette question a des années, mais il y a une autre raison pour laquelle plusieurs bases de données peuvent être utiles.

Si vous utilisez un "cloud Redis" de votre fournisseur de cloud préféré, vous avez probablement une taille de mémoire minimale et vous paierez ce que vous allouez. Cependant, si votre ensemble de données est plus petit que cela, vous gaspillerez un peu de l'allocation, et donc un peu d'argent.

En utilisant des bases de données, vous pouvez utiliser la même instance cloud Redis pour fournir un service pour (par exemple) le développement, l'UAT et la production, ou plusieurs instances de votre application, ou quoi que ce soit d'autre - en utilisant ainsi plus de mémoire allouée et donc un peu plus cher- efficace.

Un cas d'utilisation que je regarde a plusieurs instances d'une application qui utilisent chacune 200-300K, mais l'allocation minimale sur mon fournisseur de cloud est de 1M. Nous pouvons consolider 10 instances sur un seul Redis sans vraiment compromettre les limites, et ainsi économiser environ 90% du coût d'hébergement Redis. Je comprends que cette approche comporte des limites et des problèmes, mais je pense que cela vaut la peine d'être mentionné.