alternative à memcached qui peut persister sur le disque
J'utilise actuellement memcached avec mon application java, et dans l'ensemble cela fonctionne très bien.
Les fonctions de memcached qui sont 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/valeurs (puisque c'est tout ce dont mon application a besoin)
- il est distribué
- il utilise efficacement la mémoire en ayant chaque objet en direct sur exactement un serveur
- il ne suppose pas que les objets proviennent d'un base de données (depuis 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 veux périodiquement (peut-être une fois par jour) Enregistrer le contenu du cache sur le disque. Et je veux être en mesure de 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 me fiche qu'elle soit incluse dans la sauvegarde ou non. Et si un la clé / valeur est modifiée pendant la sauvegarde, la valeur enregistrée doit être l'ancienne valeur ou la nouvelle valeur, mais je ne me soucie pas de laquelle.
Quelqu'un peut-il recommander une autre solution de mise en cache (gratuite ou commerciale) qui a toutes (ou un pourcentage significatif) des fonctionnalités memcached qui sont importantes pour moi, et permet également de sauvegarder et de restaurer le cache entier à partir du disque?
15 réponses
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é, il affecte sérieusement les performances du système. Selon la philosophie originale de memcached, je devrais ajouter beaucoup plus de machines avec moins de mémoire chacune, mais ce n'est pas rentable et pas exactement "Vert";)
Pour notre solution, nous avons construit une couche d'interface pour le système de Cache d'une manière qui fournit aux systèmes de cache sous-jacents peut être imbriqué , comme vous pouvez le faire avec les flux, et a écrit un fournisseur de cache pour memcached ainsi que notre propre fournisseur de stockage Key-Value-2-disk très simple. Ensuite, nous définissons un poids pour les éléments de cache qui représente le coût de la reconstruction d'un élément s'il ne peut pas être récupéré à partir du cache. Le cache disque imbriqué n'est utilisé que pour les éléments dont le poids dépasse un certain seuil, soit environ 10% de tous les éléments.
Lors du stockage d'un objet dans le cache, Nous ne perdrons pas de temps en économisant un ou les deux caches sont en file d'attente pour une exécution asynchrone de toute façon. Donc, écrire dans le cache disque n'a pas besoin d'être rapide. Idem pour les lectures: d'abord nous allons pour memcached, et seulement si ce n'est pas là et que c'est un objet "coûteux", alors nous vérifions le cache disque (qui est par magnitudes plus lent que memcached, mais encore beaucoup mieux que de recalculer 30 Go de données après qu'une seule machine soit tombée).
De Cette façon nous obtenons le meilleur 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 (citant):
Redis est une base de données clé-valeur. Il est similaire à memcached mais l'ensemble de données n'est pas volatile, et les valeurs peuvent être chaînes, exactement comme dans memcached, mais aussi des listes et des ensembles avec atomique opérations pour pousser / pop éléments.
Afin d'être très rapide mais au en même temps persistant l'ensemble de données entier est pris en mémoire et de temps en temps heure et / ou quand un nombre des changements à l'ensemble de données sont effectuées il est écrit de manière asynchrone sur le disque. Vous mai perdu les dernières requêtes qui est acceptable dans de nombreuses applications, mais il est aussi rapide qu'une base de données en mémoire (Redis prend en charge non-blocage maître-esclave la réplication afin de résoudre ce problème par redondance).
Il 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 note de côté: si vous avez besoin d'écrire tout cela sur le disque, peut-être qu'un système cache n'est pas vraiment ce dont vous avez besoin... après tout, si vous utilisez memcached en tant que cache , Vous devriez être capable de le remplir à la demande, chaque fois que c'est nécessaire-encore, je l'admets, il pourrait y avoir des problèmes de performance si vous tout le cluster memcached tombe à la fois...
Alors, peut-être qu'un logiciel orienté clé/valeur "plus" pourrait aider? Quelque chose comme CouchDB , par exemple?
il ne sera probablement pas aussi rapide que memcached, car les données ne sont pas stockées dans la RAM, mais sur le disque...
EhCache a un mode "disque persistant" qui vide le contenu du cache sur le disque à l'arrêt, et rétablit les données lors du redémarrage. En ce qui concerne 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. autre que cela, il devrait répondre à vos besoins bien. Il est également toujours en développement actif, ce que de nombreux autres frameworks de mise en cache java ne sont pas.
Try aller-memcached - memcache serveur écrit en Aller. Il persiste 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 caractéristiques suivantes manque 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 de la RAM disponible de plusieurs ordres de grandeur.
- il n'y a pas de limite de 250 octets sur la taille de la clé.
- il n'y a pas de limite de 1 Mo sur la valeur de la taille. La taille de la valeur est en fait limitée par 2 Go.
- , Il est plus rapide que l'original memcached. Il utilise également moins de CPU lors du service des demandes entrantes.
Voici les chiffres de la performance obtenue par aller-memcached-banc:
-----------------------------------------------------
| | 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 |
-----------------------------------------------------
Statiquement binaires aller-memcached et aller-memcached-banc, sont disponibles à l' page des téléchargements.
Jetez un oeil au 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 moyens pour gérer les données mises en cache de divers natures dynamiques. Comme toute mise en cache système, JCS est plus utile pour haute lire, bas mettre des applications. La latence les temps diminuent fortement et les goulots d'étranglement s'éloigner de la base de données dans un système effectivement mis en cache. Apprendre pour commencer à utiliser JCS.
Le JCS va au-delà de la simple mise en cache les objets en mémoire. Il fournit 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
Dans mon expérience, il est préférable d'écrire une couche intermédiaire entre l'application et le backend de stockage. De cette façon, vous pouvez coupler des instances memcached et par exemple sharedanced (essentiellement le même magasin clé-valeur, mais basé sur disque). La façon la plus basique de le faire est de toujours lire à partir de memcached et fail-back à sharedanced et toujours écrire à sharedanced et memcached.
Vous pouvez mettre à l'échelle les Écritures en séparant plusieurs instances de sharedance. Vous pouvez read reads n-fold en utilisant un solution comme repcached (memcached répliqué).
Si ce n'est pas trivial pour vous, vous pouvez toujours utiliser sharedanced comme remplacement de base pour memcached. C'est rapide, la plupart des appels de système de fichiers sont finalement mis en cache - l'utilisation de memcached en combinaison avec sharedance évite seulement la lecture de sharedanced jusqu'à ce que certaines données expirent dans memcache. Un redémarrage des serveurs memcached provoquerait la lecture de tous les clients à partir de l'instance sharedance au moins une fois-pas vraiment un problème, sauf si vous avez concurrence extrêmement élevée pour les mêmes clés et les clients luttent pour la même clé.
Il y a certains problèmes si vous avez affaire à un environnement de trafic très élevé, l'un est le choix du système de fichiers (reiserfs effectue 5-10x 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 sharedance uniquement, memcached a udp grâce à l'équipe facebook) et partage de données sur plusieurs instances de serveurs sharedance).
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 des hachages, des listes,etc.
Oracle NoSQL est basé sur BerkeleyDB (la solution pointée par Bill Karwin), mais ajoute sharding (partitionnement de l'ensemble de données) et Elastic scale-out. Voir: http://www.oracle.com/technetwork/products/nosqldb/overview/index.html
Je pense qu'il répond à toutes les exigences de la question initiale.
pour des raisons de divulgation complète, je travaille chez Oracle (mais pas sur le produit Oracle NoSQL). Les opinions et les points de vue exprimés dans ce post sont les miens, et ne le font pas nécessairement les opinions de mon employeur.
Memcached peut être remplacé par Couchbase - Ceci est une continuation open source et commerciale de cette gamme 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 votre code d'application client! Son produit très performant et est livré avec 24/7 clustering et Cross Datacenter Replication (XDCR) intégré. Voir document technique.
Vous pouvez utiliser Tarantool ( http://tarantool.org). c'est une base de données en mémoire avec persistance, réplication maître-maître et règles d'expiration de clé scriptable - https://github.com/tarantool/expirationd
Avez-vous regardé BerkeleyDB?
- Gestion rapide, intégrée et en cours de traitement des données.
- Magasin de clés/valeurs, non relationnel.
- stockage persistant.
- gratuit, 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 des données.
Nous utilisons OSCache . Je pense qu'il répond à presque tous vos besoins, sauf enregistrer périodiquement le cache sur le disque, mais vous devriez être en mesure de 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 qui passe par toutes les paires clé/valeur cache en mémoire et les met dans le cache Ce qui est bien avec OSCache, c'est qu'il est très facile à utiliser.
Vous pouvez utiliser GigaSpaces XAP qui est un produit commercial mature qui répond à vos besoins et plus encore. C'est 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.
Gars Nirpaz, GigaSpaces