Étude d'une base NOSQL - Redis, avec son écosystème environnant

Thèmes abordés

Redis, windows, architecture maître-esclave, hash slots, base NOSQL, vitesse d'exécution, mode de persistance, Spark, notion de pair, Remote Dictionary Server, client graphique FastoRedis, opérations courantes, clefs, serveur, performances, benchmark, Snapshot, réplication, synchronisation au maitre, architecture de sentinelles, clusters des esclaves, programme, Python, noeud de cluster, routage des requêtes

Résumé du document

Redis est une base et entrepôt de données NOSQL exploitant la notion de pair (clé, valeur). Chaque donnée/valeur est stockée à l'intérieur d'une clé. Tout se passe comme s'il s'agissait d'un dictionnaire conséquent régi par l'ensemble de ces clés, et qui plus est persistant. D'où l'appellation pour Redis de « Remote Dictionary Server » (Serveur de dictionnaire à distance).
Un autre point essentiel est que toute donnée Redis réside en mémoire, contrairement à la majorité des bases de données qui stockent des données sur disque ou SSD.
Redis est un choix de premier rang pour la mise en cache, les classements, l'analyse en temps réel et les applications pub/sub.
Dans cette étude, nous découvririons Redis avec sa structure de données simple et riche, puis nous insérerons notre jeu de données en établissant quelques requêtes après avoir analysé la réplication.

Extraits

[...] L'objectif de cette partie est d'illustrer comment ces deux puissants systèmes pourraient fonctionner. On installe la librairie en téléchargeant les sources : $ git clone https://github.com/RedisLabs/spark-redis.git cd spark-redis mvn clean package -DskipTests On donne ensuite les principales étapes de la lecture des données de Redis au stockage des données résultantes dans Redis Mise en place de la connexion entre Redis et Spark On utilise le fichier jar compilé à l'étape de build avec maeven au lancement de Spark et on initialise un SparkContext une fois dans Spark, indiquant l'adresse IP et le port sur lequel le serveur Redis tourne. [...]

[...] Pour cela, attaquons le cluster des sentinelles avec Redis-py, car très simple à mettre en œuvre. En effet, avec le client Redis-cli, il faut installer des binaires pour que le mot clef SENTINEL soit reconnu . On s'appuiera sur la documentation github dans laquelle il y'a heureusement un support et renvoi à la documentation Redis officielle pour traiter les clusters avec sentinelles. C'est exactement ce qu'il nous faut. On branche le client Redis-py avec le cluster des sentinelles (nous travaillons donc dans Python) : from redis.sentinel import Sentinel sentinel = Sentinel([(' 26379), 26380), 26381)], socket_timeout= 0.1 ) Découvrons le maître du groupe mymaster : sentinel.discover_master('mymaster') Output:(' 6379) Cela est bien cohérent avec la façon dont laquelle on a construit notre cluster (voir plus haut). [...]

[...] D'où l'appellation pour Redis de Remote Dictionary Server (Serveur de dictionnaire à distance). Un autre point essentiel est que toute donnée Redis réside en mémoire, contrairement à la majorité des bases de données qui stockent des données sur disque ou SSD. Redis est un choix de premier rang pour la mise en cache, les classements, l'analyse en temps réel et les applications pub/sub. Dans cette étude, nous découvririons Redis avec sa structure de donnée simple et riche, puis nous insérerons notre jeu de donnée en établissant quelques requêtes après avoir analysé la réplication. [...]

[...] Pour créer un cluster, nous avons besoin d'un utilitaire : Redis-trib, relatif à la version 3 de Redis (ce dernier fonctionnant avec une version de Redis 3 ou ce qui est notre cas. Pour y parvenir, nous devons déjà installer Redis-gem. gem install redis redis-trib.rb create --replicas : : : : : :7005 Output > Creating cluster > Performing hash slots allocation on 6 nodes . Using 3 masters: : : :7002 Adding replica :7003 to :7000 Adding replica :7004 to :7001 Adding replica :7005 to :7002 3ae1023daf29ea703f11ff91db710b1b970ad24e :7000 slots:0-5460 (5461 slots) master bcac06a210ca95b80eb39a29c9230949836bb9e :7001 slots:5461-10922 (5462 slots) master cdc2489b297d3503dfaf5e13dc1d0e982c4d4aa :7002 slots:10923-16383 (5461 slots) master 0e211a394a457e82d56837fbe2061b47d289083e :7003 replicates 3ae1023daf29ea703f11ff91db710b1b970ad24e f5db1d89d12f7ce467fe33465b4e2a94196c3a :7004 replicates bcac06a210ca95b80eb39a29c9230949836bb9e4 87a8152f5d0271214458927c83370a5f886493e :7005 replicates cdc2489b297d3503dfaf5e13dc1d0e982c4d4aa7 All 16384 slots covered. [...]

[...] Nous disposons de 16384 hash slots. Pour 4 serveurs se partageant cette plage, afin d'équilibrer les charges des serveurs, nous voulons découper la plage en parts égales, soit en 4095 hash slots par serveur : ./redis-trib.rb reshard --from all f2858cb2905f9b817377e874b21c617ce8814e4a --slots 4095 --yes :7000 Voyons désormais notre table de hashage : redis-trib.rb info :7000 output :7011 (f2858cb ) 0 keys 4095 slots 0 slaves :7003 (0e211a ) 895 keys 4096 slots 1 slaves :7001 (bcac06a ) 896 keys 4096 slots 1 slaves :7002 (cdc2489b . [...]