alternative à memcached qui peut persister sur le disque
J'utilise actuellement memcached avec mon Java, et dans l'ensemble cela fonctionne très bien.
Les fonctionnalités de memcached les plus importantes pour moi sont:
- c'est rapide, car les lectures et les écritures sont en mémoire et ne touchent pas le disque
- c'est juste un magasin de clés/valeur (car c'est tout ce dont mon application a besoin)
- c'est distribué
- il utilise efficacement la mémoire en faisant vivre chaque objet sur exactement un serveur
- il ne suppose pas que les objets proviennent d'une base de données (puisque mes objets ne sont pas des objets de base de données)
Cependant, il y a une chose que j'aimerais faire que memcached ne peut pas faire. Je souhaite enregistrer périodiquement (peut-être une fois par jour) le contenu du cache sur le disque. Et je veux pouvoir restaurer le cache à partir de l'image disque enregistrée.
La sauvegarde du disque n'a pas besoin d'être très complexe. Si une nouvelle clé/valeur est ajoutée pendant la sauvegarde, je m'en fiche qu'elle soit incluse ou non dans la sauvegarde. Et si une clé/valeur existante est modifiée pendant la sauvegarde, la valeur enregistrée doit être soit l'ancienne valeur, soit la nouvelle valeur, mais je m'en fiche de laquelle.
Quelqu'un peut-il recommander une autre solution de mise en cache (gratuite ou commerciale) qui possède toutes (ou un pourcentage significatif) des fonctionnalités memcached qui sont importantes pour moi, et permet également d'enregistrer et de restaurer l'intégralité du cache à partir du disque?
Peut-être votre problème comme le mien: je n'ai que quelques machines pour memcached, mais avec beaucoup de mémoire. Même si l'un d'eux échoue ou doit être redémarré, cela affecte sérieusement les performances du système. Selon la philosophie memcached originale, je devrais ajouter beaucoup plus de machines avec moins de mémoire chacune, mais ce n'est pas rentable et pas exactement "green IT";)
Pour notre solution, nous avons construit une couche d'interface pour le système de cache de manière à ce que les fournisseurs des systèmes de cache sous-jacents puissent être imbriqués, comme vous pouvez le faire avec les flux, et avons écrit un fournisseur de cache pour memcached ainsi que notre propre fournisseur de stockage sur disque Key-Value-2 très simple. Ensuite, nous définissons un poids pour les éléments du cache qui représente combien il est coûteux de reconstruire un élément s'il ne peut pas être récupéré du cache. Le cache disque imbriqué n'est utilisé que pour les éléments dont le poids dépasse un certain seuil, peut-être environ 10% de tous les éléments.
Lors du stockage d'un objet dans le cache, nous ne perdrons pas de temps car l'enregistrement dans un ou les deux caches est de toute façon mis en file d'attente pour une exécution asynchrone. L'écriture dans le cache disque n'a donc pas besoin d'être rapide. Idem pour les lectures: D'abord, nous optons pour memcached, et seulement s'il n'est pas là et qu'il s'agit d'un objet "coûteux", nous vérifions ensuite le cache disque (qui est plus lent que memcached, mais toujours bien meilleur que recalculant 30 Go de données après une seule machine est tombé en panne).
De cette façon, nous tirons le meilleur parti des deux mondes, sans remplacer memcached par quelque chose de nouveau.
Je ne l'ai jamais essayé, mais qu'en est-il de redis ?
Sa page d'accueil dit (en citant):
Redis est une base de données de valeurs-clés. Il est similaire à memcached mais l'ensemble de données n'est pas volatile, et les valeurs peuvent être des chaînes, exactement comme dans memcached, mais également des listes et des ensembles avec des opérations atomiques pour les éléments Push/pop.
Afin d'être très rapide mais en même temps persistant, l'ensemble de données est pris en mémoire et de temps en temps et/ou lorsqu'un certain nombre de modifications sont apportées à l'ensemble de données, il est écrit de manière asynchrone sur le disque. Vous pouvez perdre les dernières requêtes acceptables dans de nombreuses applications, mais elles sont aussi rapides qu'une base de données en mémoire (Redis prend en charge la réplication maître-esclave non bloquante afin de résoudre ce problème par redondance).
Cela semble répondre à certains points dont vous avez parlé, alors peut-être que cela pourrait être utile, dans votre cas?
Si vous l'essayez, je suis assez intéressé par ce que vous découvrez, btw ;-)
En remarque: si vous avez besoin d'écrire tout cela sur le disque, peut-être qu'un système de cache n'est pas vraiment ce dont vous avez besoin .. après tout, si vous utilisez memcached comme cache , vous devriez être en mesure de le remplir à nouveau à la demande, chaque fois que cela est nécessaire - encore, je l'admets, il pourrait y avoir des problèmes de performances si tout votre cluster memcached tombe en même temps ...
Alors, peut-être qu'un logiciel orienté "plus" de magasin de clés/valeurs pourrait aider? Quelque chose comme CouchDB , par exemple?
Ce ne sera probablement pas aussi rapide que Memcached, car les données ne sont pas stockées dans la RAM, mais sur le disque, cependant ...
EhCache a un mode "disque persistant" qui vide le contenu du cache sur le disque à l'arrêt, et rétablira les données lors du redémarrage. Quant à vos autres exigences, lors de l'exécution en mode distribué, il réplique les données sur tous les nœuds, plutôt que de les stocker sur un seul. à part cela, il devrait convenir parfaitement à vos besoins. Il est également en cours de développement actif, ce que de nombreux autres cadres de mise en cache Java ne le sont pas.
Essayez go-memcached - serveur memcache écrit en Go . Il conserve les données mises en cache sur le disque hors de la boîte. Go-memcached est compatible avec les clients memcache. Il a les fonctionnalités suivantes manquantes dans l'original memcached :
- Les données mises en cache survivent aux pannes et/ou redémarrages du serveur.
- La taille du cache peut dépasser la taille RAM de plusieurs ordres de grandeur).
- Il n'y a pas de limite de 250 octets sur la taille des clés.
- Il n'y a pas de limite de 1 Mo sur la taille de la valeur. La taille de la valeur est en fait limitée à 2 Go.
- Il est plus rapide que l'original memcached . Il utilise également moins de CPU lors du traitement des demandes entrantes.
Voici les chiffres de performance obtenus via go-memcached-bench :
-----------------------------------------------------
| | go-memcached | original memcached |
| | v1 | v1.4.13 |
| workerMode ----------------------------------------
| | Kqps | cpu time | Kqps | cpu time |
|----------------------------------------------------
| GetMiss | 648 | 17 | 468 | 33 |
| GetHit | 195 | 16 | 180 | 17 |
| Set | 204 | 14 | 182 | 25 |
| GetSetRand | 164 | 16 | 157 | 20 |
-----------------------------------------------------
Les binaires liés statiquement pour go-memcached et go-memcached-bench sont disponibles sur page de téléchargements .
Jetez un œil à Apache Java Caching System (JCS)
JCS est un système de mise en cache distribué écrit en Java. Il est destiné à accélérer les applications en fournissant un moyen de gérer les données mises en cache de diverses natures dynamiques. Comme tout système de mise en cache, JCS est le plus utile pour les applications à lecture élevée et à faible intensité. Les temps de latence baissent fortement et les goulots d'étranglement s'éloignent de la base de données dans un système efficacement mis en cache. Découvrez comment commencer à utiliser JCS.
Le JCS va au-delà de la simple mise en cache d'objets en mémoire. Il offre de nombreuses fonctionnalités supplémentaires:
* Memory management * Disk overflow (and defragmentation) * Thread pool controls * Element grouping * Minimal dependencies * Quick nested categorical removal * Data expiration (idle time and max life) * Extensible framework * Fully configurable runtime parameters * Region data separation and configuration * Fine grained element configuration options * Remote synchronization * Remote store recovery * Non-blocking "zombie" (balking facade) pattern * Lateral distribution of elements via HTTP, TCP, or UDP * UDP Discovery of other caches * Element event handling * Remote server chaining (or clustering) and failover * Custom event logging hooks * Custom event queue injection * Custom object serializer injection * Key pattern matching retrieval * Network efficient multi-key retrieval
Je pense que membase est ce que vous voulez.
D'après mon expérience, il est préférable d'écrire une couche intermédiaire entre l'application et le stockage backend. De cette façon, vous pouvez associer des instances memcached et par exemple sharedanced (essentiellement le même magasin de valeurs-clés, mais basé sur le disque). La façon la plus simple de le faire est de toujours lire à partir de memcached et de basculer vers sharedanced et d'écrire toujours sur sharedanced et memcached.
Vous pouvez mettre à l'échelle les écritures en partageant entre plusieurs instances de partage. Vous pouvez redimensionner les lectures N fois en utilisant une solution telle que repcached (memcached répliqué).
Si cela n'est pas trivial pour vous, vous pouvez toujours utiliser sharedanced comme remplacement de base de memcached. C'est rapide, la plupart des appels du système de fichiers sont finalement mis en cache - l'utilisation de memcached en combinaison avec le partage n'évite que la lecture de sharedanced jusqu'à ce que certaines données expirent dans memcache. Un redémarrage des serveurs memcached obligerait tous les clients à lire l'instance de partage au moins une fois - ce n'est pas vraiment un problème, sauf si vous avez une concurrence extrêmement élevée pour les mêmes clés et que les clients se disputent la même clé.
Il y a certains problèmes si vous avez affaire à un environnement très fréquenté, l'un est le choix du système de fichiers (reiserfs fonctionne 5 à 10 fois mieux que ext3 en raison de la mise en cache interne de l'arborescence fs), il n'a pas de support udp (TCP keepalive est assez lourd si vous utilisez uniquement le partage, memcached a udp grâce à l'équipe facebook) et la mise à l'échelle est généralement effectuée sur votre application (en partageant les données sur plusieurs instances de serveurs de partage).
Si vous pouvez tirer parti de ces facteurs, cela pourrait être une bonne solution pour vous. Dans notre configuration actuelle, un seul serveur sharedanced/memcache peut évoluer jusqu'à environ 10 millions de pages vues par jour, mais cela dépend de l'application. Nous n'utilisons pas la mise en cache pour tout (comme Facebook), donc les résultats peuvent varier en ce qui concerne votre application.
Et maintenant, un bon 2 ans plus tard, Membase est un excellent produit pour cela. Ou Redis, si vous avez besoin de fonctionnalités supplémentaires comme les hachages, les listes, etc.
Avez-vous regardé BerkeleyDB ?
- Gestion rapide, intégrée et en cours des données.
- Magasin de clés/valeurs, non relationnel.
- Stockage persistant.
- Libre, open-source.
Cependant, il ne répond pas à l'un de vos critères:
- BDB prend en charge la réplication distribuée, mais les données ne sont pas partitionnées. Chaque nœud stocke l'ensemble de données complet.
Qu'en est-il de Terre cuite ?
Oracle NoSQL est basé sur BerkeleyDB (la solution à laquelle Bill Karwin a fait référence), mais ajoute un partage (partitionnement de l'ensemble de données) et une montée en charge élastique. Voir: http://www.Oracle.com/technetwork/products/nosqldb/overview/index.html
Je pense qu'il répond à toutes les exigences de la question d'origine.
Dans un souci de divulgation complète, je travaille chez Oracle (mais pas sur le produit Oracle NoSQL). Les opinions et points de vue exprimés dans ce message sont les miens et ne reflètent pas nécessairement les opinions ou les points de vue de mon employeur.
memcached peut être remplacé par Couchbase - il s'agit d'une continuation open source et commerciale de cette ligne de produits. Il a des données sur la persistance du disque (très efficace et configurable). Les auteurs originaux de memcached ont également travaillé sur Couchbase et son compatible avec le protocole memcached - vous n'avez donc pas besoin de changer le code de votre application client! Son produit très performant est livré avec un clustering 24/7 et Cross Datacenter Replication (XDCR) intégré. Voir document technique .
Vous pouvez utiliser Tarantool ( http://tarantool.org ). Il s'agit d'une base de données en mémoire avec des règles de persistance, de réplication maître-maître et d'expiration de clé scriptable - https://github.com/tarantool/expirationd
Vous pouvez utiliser GigaSpaces XAP qui est un produit commercial mature qui répond à vos besoins et plus encore. Il s'agit de la grille de données en mémoire distribuée la plus rapide (cache ++), elle est entièrement distribuée et prend en charge plusieurs styles de méthodes de persistance.
Guy Nirpaz, GigaSpaces
Nous utilisons OSCache . Je pense qu'il répond à presque tous vos besoins, sauf en sauvegardant périodiquement le cache sur le disque, mais vous devriez pouvoir créer 2 gestionnaires de cache (un basé sur la mémoire et un basé sur le disque dur) et exécuter périodiquement Java cronjob that passe par toutes les paires clé/valeur du cache en mémoire et les place dans le cache hdd. Ce qui est bien avec OSCache, c'est qu'il est très facile à utiliser.
Juste pour compléter cette liste - je viens de trouver couchbase . Cependant je ne l'ai pas encore testé.