Redis
 sql >> Base de données >  >> NoSQL >> Redis

Est-ce un bon cas d'utilisation pour Redis sur une API REST ServiceStack ?

À quoi penser lors de la conception d'une application NoSQL Redis

1) Pour développer correctement dans Redis, vous devriez réfléchir davantage à la façon dont vous structureriez les relations dans votre programme C#, c'est-à-dire avec les classes de collection C# plutôt qu'un modèle relationnel destiné à un SGBDR. Le meilleur état d'esprit serait de penser davantage au stockage de données comme une base de données de documents plutôt que des tables RDBMS. Essentiellement, tout est blobbé dans Redis via une clé (index), il vous suffit donc de déterminer quelles sont vos entités principales (c'est-à-dire les racines agrégées) qui seraient conservées dans son propre "espace de noms de clé" ou s'il s'agit d'une entité non principale, c'est-à-dire simplement métadonnées qui doivent simplement être conservées avec son entité parent.

Exemples de Redis en tant que magasin de données principal

Voici un bon article qui explique comment créer une application de blog simple à l'aide de Redis :

http://www.servicestack.net/docs/redis-client/designing-nosql-database

Vous pouvez également consulter le code source de RedisStackOverflow pour un autre exemple concret utilisant Redis.

Fondamentalement, vous devrez stocker et récupérer les éléments de chaque type séparément.

var redisUsers = redis.As<User>();
var user = redisUsers.GetById(1);
var userIsWatching = redisUsers.GetRelatedEntities<Watching>(user.Id);

La façon dont vous stockez la relation entre les entités utilise les ensembles de Redis, par exemple :vous pouvez stocker la relation Utilisateurs/Observateurs de manière conceptuelle avec :

SET["ids:User>Watcher:{UserId}"] = [{watcherId1},{watcherId2},...]

Redis est sans schéma et idempotent

Le stockage des identifiants dans des ensembles Redis est idempotent, c'est-à-dire que vous pouvez ajouter watcherId1 au même ensemble plusieurs fois et il n'en aura qu'une seule occurrence. C'est bien car cela signifie que vous n'avez jamais besoin de vérifier l'existence de la relation et que vous pouvez librement continuer à ajouter des identifiants associés comme s'ils n'avaient jamais existé.

En relation :écrire ou lire dans une collection Redis (par exemple, List) qui n'existe pas revient au même qu'écrire dans une collection vide, c'est-à-dire qu'une liste est créée à la volée lorsque vous ajoutez un élément à une liste tout en accédant à un non- liste existante renverra simplement 0 résultats. Il s'agit d'un gain de productivité et sans friction puisque vous n'avez pas à définir vos schémas à l'avance pour les utiliser. Bien que si vous en ayez besoin, Redis fournit l'opération EXISTS pour déterminer si une clé existe ou une opération TYPE afin que vous puissiez déterminer son type.

Créez vos relations/index sur vos écritures

Une chose à retenir est qu'il n'y a pas d'index implicites dans Redis, vous devrez généralement configurer vos index/relations nécessaires pour vous lire pendant vos écritures. Fondamentalement, vous devez penser à toutes vos exigences de requête dès le départ et vous assurer de mettre en place les relations nécessaires au moment de l'écriture. Le code source RedisStackOverflow ci-dessus en est un bon exemple.

Remarque :le fournisseur ServiceStack.Redis C# suppose que vous disposez d'un champ unique appelé Id c'est sa clé primaire. Vous pouvez le configurer pour utiliser un champ différent avec le ModelConfig.Id() mappage de configuration.

Persistance Redis

2) Redis prend en charge 2 types de modes de persistance prêts à l'emploi RDB et Append Only File (AOF). RDB écrit des instantanés de routine tandis que le fichier Append Only agit comme un journal des transactions enregistrant toutes les modifications entre les instantanés - je recommande d'ajouter les deux jusqu'à ce que vous soyez à l'aise avec ce que chacun fait et ce dont votre application a besoin. Vous pouvez lire toute la persistance Redis sur http://redis.io/topics/persistence.

Remarque Redis prend également en charge la réplication triviale, vous pouvez en savoir plus sur :http://redis.io/topics/replication

Redis adore la RAM

3) Étant donné que Redis fonctionne principalement en mémoire, la ressource la plus importante est que vous disposiez de suffisamment de RAM pour stocker l'intégralité de votre ensemble de données en mémoire + un tampon pour le moment où il prend un instantané sur le disque. Redis est très efficace, donc même une petite instance AWS pourra gérer beaucoup de charge - ce que vous voulez rechercher, c'est avoir suffisamment de RAM.

Visualiser vos données avec l'interface utilisateur d'administration Redis

Enfin, si vous utilisez le client ServiceStack C# Redis, je vous recommande d'installer l'interface utilisateur d'administration Redis qui offre une belle vue visuelle de vos entités. Vous pouvez en voir une démonstration en direct sur :http://servicestack.net/RedisAdminUI/AjaxClient/