Redis vs RocksDB
J'ai lu sur Redis et RocksDB, je n'ai pas les avantages de Redis sur RocksDB.
Je sais que Redis est entièrement en mémoire et RocksDB est en mémoire et utilise le stockage flash. Si toutes les données tiennent en mémoire, laquelle dois-je choisir? ont-ils les mêmes performances? Redis évolue linéairement avec le nombre de CPU? Je suppose qu'il y a d'autres différences que je ne comprends pas.
J'ai un jeu de données qui tient en mémoire et j'allais choisir Redis mais il semble que RocksDB m'offre la même chose et si un jour le jeu de données augmente trop, je n'aurais pas à m'inquiéter pour la mémoire.
Il n'ont rien en commun. Vous essayez de comparer des pommes et des oranges ici.
Redis est un distant magasin de données en mémoire (similaire à memcached). C'est un serveur. Une seule instance Redis est très efficace, mais totalement non évolutive (en ce qui concerne le CPU). Un cluster Redis est évolutif (concernant le CPU).
RocksDB est un magasin de clés/valeurs intégré (similaire à BerkeleyDB ou plus exactement LevelDB). Il s'agit d'une bibliothèque prenant en charge le multithread et une persistance basée sur des arborescences de fusion structurées en journaux.
Alors que la réponse de Didier Spezia est correcte dans sa distinction entre les deux projets, ils sont liés par un projet appelé LedisDB . LedisDB est une couche d'abstraction écrite en Go qui implémente une grande partie de l'API Redis sur des moteurs de stockage comme RocksDB. Dans de nombreux cas, vous pouvez utiliser la même bibliothèque cliente Redis directement avec LedisDB, ce qui en fait presque une baisse en remplacement de Redis dans certaines situations. Redis est évidemment plus rapide, mais comme OP l'a mentionné dans sa question, le principal avantage de l'utilisation de RocksDB est que votre ensemble de données n'est pas limité à la quantité de mémoire disponible. Je trouve cela utile non pas parce que je traite des ensembles de données très volumineux, mais parce que RAM est cher et vous pouvez obtenir plus de kilométrage sur des serveurs virtuels plus petits.
- Redis, en général, a plus de fonctionnalités que RocksDB. Il peut comprendre nativement la sémantique des structures de données complexes telles que les listes et les tableaux. RocksDB, en revanche, considère les valeurs stockées comme un blob de données. Si vous souhaitez effectuer un traitement supplémentaire, vous devez apporter les données à votre programme et les y traiter (en d'autres termes, vous ne pouvez pas déléguer le traitement au moteur de base de données aka RocksDB).
- RocksDB ne fonctionne que sur un seul serveur. Redis a une version en cluster (bien qu'elle ne soit pas gratuite)
- Redis est conçu pour le calcul en mémoire, bien qu'il prenne également en charge la sauvegarde des données sur le stockage persistant, mais les principaux cas d'utilisation se trouvent dans les cas d'utilisation de la mémoire. RocksDB, en revanche, est généralement utilisé pour les données persistantes et, dans la plupart des cas, stocke les données sur un support persistant.
- RocksDB a un meilleur support multi-thread (spécialement pour les lectures - les écritures souffrent toujours d'un accès simultané).
De nombreux serveurs memcached utilisent Redis (où le protocole utilisé est memcached mais le serveur sous-jacent est Redis). Cela n'utilise pas la plupart des fonctionnalités de Redis mais c'est un cas où Redis et RocksDB fonctionnent tous les deux de manière similaire (en tant que KVS bien que toujours dans un contexte différent, où memcached basé sur Redis est un cache mais RocksDB est une base de données, mais pas une entreprise)
@Guille Si vous savez que le comportement des données chaudes (récupérées fréquemment) est basé sur l'horodatage, Rocksdb serait un choix judicieux, mais optimisez-le pour le repli à l'aide de filtres de floraison.Si vos données chaudes sont aléatoires, optez pour Redis .L'utilisation de rocksDB entièrement en mémoire n'est généralement pas recommandée dans les bases de données à structure de journal comme Rocksdb et son optimisé spécifiquement pour le stockage SSD et flash.Par conséquent, ma recommandation serait de comprendre le cas d'utilisation et de choisir une base de données pour ce cas particulier.