web-dev-qa-db-fra.com

Y a-t-il quelque chose comme Redis DB, mais non limité avec RAM size?

Je recherche une base de données répondant à ces critères:

  • Peut être non persistant;
  • Presque toutes les clés de la base de données doivent être mises à jour une fois toutes les 3 à 6 heures (100 M + clés avec une taille totale de 100 Go)
  • Possibilité de sélectionner rapidement les données par clé (ou clé primaire)
  • Cela doit être un SGBD (donc LevelDB ne convient pas)
  • Lorsque les données sont écrites, le cluster de bases de données doit pouvoir répondre aux requêtes (les nœuds uniques peuvent être bloqués cependant)
  • Pas en mémoire - notre ensemble de données dépassera les limites RAM
  • Mise à l'échelle horizontale et réplication
  • Prend en charge la réécriture complète de toutes les données (MongoDB ne vide pas l'espace après la suppression des données)
  • C # et Java

Voici mon processus de travail avec une telle base de données: nous avons un cluster d'analyse qui produit 100 millions d'enregistrements (50 Go) de données toutes les 4 à 6 heures. Les données sont un "tableau de clés [20]". Ces données doivent être distribuées aux utilisateurs via un système frontal avec un taux de 1 à 10 000 requêtes par seconde. En moyenne, seulement ~ 15% des données sont demandées, le reste sera réécrit en 4 à 6 heures lors de la génération du prochain ensemble de données.

Ce que j'ai essayé:

  1. MongoDB. Frais généraux de stockage de données, coûts de défragmentation élevés.
  2. Redis. Semble parfait, mais il est limité avec RAM et nos données le dépassent.

La question est donc: existe-t-il quelque chose comme Redis, mais sans s'y limiter avec la taille RAM?

40
Andrey

Oui, il existe deux alternatives à Redis qui ne sont pas limitées par la taille RAM tout en restant compatible avec le protocole Redis:

Ardb (C++), réplication (Master-Slave/Master-Master): https://github.com/yinqiwen/ardb

Un serveur de stockage persistant compatible avec le protocole redis, prend en charge LevelDB/KyotoCabinet/LMDB comme moteur de stockage.

Edis (Erlang): http://inaka.github.io/edis/

Edis est un remplacement de serveur compatible avec le protocole pour Redis, écrit en Erlang. Le but d'Edis est d'être un remplaçant de Redis lorsque la persistance est plus importante que de conserver l'ensemble de données en mémoire. Edis (actuellement) utilise leveldb de Google comme backend.

Et pour être complet, voici une autre base de données de structures de données:

Hyperdex (chaînes, entiers, flottants, listes, ensembles, cartes): http://hyperdex.org/doc/latest/DataTypes/#chap:data-types

HyperDex c'est:

  • Rapide: HyperDex a une latence plus faible, un débit plus élevé et une variance plus faible que les autres magasins de valeurs-clés.
  • Évolutif: HyperDex évolue à mesure que de nouvelles machines sont ajoutées au système.
  • Cohérent: HyperDex garantit la linéarisation des opérations basées sur les clés. Ainsi, une lecture renvoie toujours la dernière valeur insérée dans le système. Pas seulement "éventuellement", mais immédiatement et toujours.
  • Tolérance aux pannes: HyperDex réplique automatiquement les données sur plusieurs machines afin que les défaillances simultanées, jusqu'à une limite déterminée par l'application, n'entraînent pas de perte de données. Consultable:
  • HyperDex permet des recherches efficaces d'attributs de données secondaires.
  • Facile à utiliser: HyperDex fournit des API pour une variété de scripts et de langues natives.
  • Auto-entretien: un HyperDex est auto-entretenu et nécessite peu de maintenance par l'utilisateur.
25
FGRibreau

Oui, SSDB ( https://github.com/ideawu/ssdb ), il a des API très similaires à Redis: http://www.ideawu.com/ssdb/docs/ php /

SSDB prend en charge le hachage, zset. Il utilise leveldb comme moteur de stockage, la plupart des données sont stockées sur le disque, RAM est utilisé pour le cache. Sur notre instance SSDB avec 300 Go de données, il n'utilise que 800 Mo de RAM.

21
ideawu

De nos jours, vous pouvez facilement trouver des serveurs avec plus de 100 Go de RAM pour héberger une seule instance, ou vous pouvez partager vos données et utiliser plusieurs serveurs avec moins de RAM. Stockage de 100 Go avec Redis (dans RAM) n'est pas vraiment un problème.

Maintenant, si vous voulez vraiment essayer un clone à saignement de Redis non limité par la taille RAM, il y a NDS (par Matt Palmer):

Notez que le backend de stockage de NDS est passé de Kyoto Cabinet à LMDB (un très bon package, qui alimente également OpenLDAP), précisément en raison de problèmes de récupération d'espace après la suppression des clés.

D'autres solutions - non compatibles avec Redis - peuvent également répondre à vos besoins: Couchbase et Aerospike, par exemple, pourraient facilement prendre en charge votre débit. Cassandra et Riak fonctionneraient probablement aussi bien à condition d'avoir suffisamment de nœuds.

4
Didier Spezia