C'est très incomplet tout de même.
Parce que l'intérêt de Redis n'est pas tellement son stockage clé-valeur, ou ses types de données assez pratiques.
Il y a deux points intéressants : le cache, avec le TTL (Time to Live) pour chaque clé, qui permet de dire que la donnée ne reste disponible qu'un certain temps.
Donc typiquement pratique pour faire un cache avec invalidation temporelle automatique.
Apparemment Redka permet ça.
Mais aussi l'utilisation de Redis comme bus de données, avec les fonctions comme BLPOP ou BLMOVE, qui permettent d'attendre un élément dans une liste et de le consommer immédiatement.
Avec ces méthodes, on peut avoir plusieurs processus de travail en attente de quelque chose à faire par exemple : soit on a plein de taf et la liste grossit, soit on s'ennuie et les processus patientent de façon non active, et un seul recevra la première donnée disponible.
Ou des fonctionnalités de PUB/SUB aussi, dans la même idée mais où tout le monde reçoit les informations.
Pour le coup, Redka perd pas mal de l'utilité de Redis.
Comme si tout ce qui comptait était la commodité des types de données, alors que c'est du bonus autour du reste.
à un serveur de cache clé/valeur. Peut être que la confusion vient du fait que AWS le vend au côté de Memcached sous le terme "ElasticCache".
Redis est un serveur de data structure. Il propose :
Bitmap
Geospatial indices
Hash
HyperLogLog
List
Pub/Sub
Set
Sorted set
Stream
String
Et:
Bloom filter
Cuckoo filter
Count-min sketch
Graph
JSON
Search and query
Auto-suggest
T-digest
Time series
Top-k
Avec un support des transactions, du scripting en Lua ou JS, la mise en cluster.
On est loin d'un simple stockage clé/valeur qui d'ailleurs gagnerai à être implémenté au dessus de RocksDB / LevelDB plutôt que SQLite. D'ailleurs cela a déjà été tenté.
# Manque de fonctionnalités
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
C'est très incomplet tout de même.
Parce que l'intérêt de Redis n'est pas tellement son stockage clé-valeur, ou ses types de données assez pratiques.
Il y a deux points intéressants : le cache, avec le TTL (Time to Live) pour chaque clé, qui permet de dire que la donnée ne reste disponible qu'un certain temps.
Donc typiquement pratique pour faire un cache avec invalidation temporelle automatique.
Apparemment Redka permet ça.
Mais aussi l'utilisation de Redis comme bus de données, avec les fonctions comme BLPOP ou BLMOVE, qui permettent d'attendre un élément dans une liste et de le consommer immédiatement.
Avec ces méthodes, on peut avoir plusieurs processus de travail en attente de quelque chose à faire par exemple : soit on a plein de taf et la liste grossit, soit on s'ennuie et les processus patientent de façon non active, et un seul recevra la première donnée disponible.
Ou des fonctionnalités de PUB/SUB aussi, dans la même idée mais où tout le monde reçoit les informations.
Pour le coup, Redka perd pas mal de l'utilité de Redis.
Comme si tout ce qui comptait était la commodité des types de données, alors que c'est du bonus autour du reste.
Bref…
[^] # Re: Manque de fonctionnalités
Posté par volts . Évalué à 2 (+1/-1).
Pour les points que tu as soulevés concernant l'absence de liste et de PUB/SUB, c'est prévu de les implémenter dans de futures versions.
# Redis ne se résume pas ...
Posté par steph1978 . Évalué à 2 (+0/-0).
à un serveur de cache clé/valeur. Peut être que la confusion vient du fait que AWS le vend au côté de Memcached sous le terme "ElasticCache".
Redis est un serveur de data structure. Il propose :
Et:
Avec un support des transactions, du scripting en Lua ou JS, la mise en cluster.
On est loin d'un simple stockage clé/valeur qui d'ailleurs gagnerai à être implémenté au dessus de RocksDB / LevelDB plutôt que SQLite. D'ailleurs cela a déjà été tenté.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.