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 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é / valeur (puisque c’est tout ce dont mon application a besoin)
  • c’est dissortingbué
  • il utilise efficacement la mémoire en faisant en sorte que chaque object vive sur un seul serveur
  • il ne suppose pas que les objects proviennent d’une firebase database (puisque mes objects ne sont pas des objects de firebase database)

Cependant, il y a une chose que j’aimerais faire, que memcached ne peut pas faire. Je veux 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 sur disque n’a pas besoin d’être très complexe. Si une nouvelle clé / valeur est ajoutée pendant la sauvegarde, peu importe si elle est incluse dans la sauvegarde ou non. 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 peu importe 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 importantes pour moi, et permet également d’enregistrer et de restaurer l’intégralité du cache depuis le 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 append beaucoup plus de machines avec moins de mémoire chacune, mais ce n’est pas rentable et pas exactement “informatique verte”;)

    Pour notre solution, nous avons construit une couche d’interface pour le système de cache de manière à pouvoir imbriquer les fournisseurs des systèmes de cache sous-jacents, comme vous pouvez le faire avec les stream, et à écrire un fournisseur de cache pour memcached Fournisseur de stockage sur -2 disques. 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 extrait du cache. Le cache disque nested n’est utilisé que pour les éléments dont le poids dépasse un certain seuil, soit environ 10% de tous les éléments.

    Lorsque vous stockez un object dans le cache, nous ne perdons pas de temps car l’enregistrement dans un ou les deux caches est de toute façon mis en queue pour une exécution asynchrone. L’écriture sur le cache disque n’a donc pas besoin d’être rapide. Idem pour les lectures: Nous allons d’abord chercher memcached, et seulement si ce n’est pas là et que c’est un object “coûteux”, alors nous vérifions le cache disque (qui est plus lent que memcached mais données après une seule machine est tombé en panne).

    De cette façon, nous obtenons le meilleur des deux mondes, sans remplacer rien de nouveau.

    Je n’ai jamais essayé, mais qu’en est-il des redis ?
    Sa page d’accueil indique (citant):

    Redis est une firebase database de valeurs-clés. Il est similaire à memcached mais le jeu de données n’est pas volatile et les valeurs peuvent être des chaînes, exactement comme dans memcached, mais aussi des listes et des ensembles avec des opérations atomiques pour des éléments push / pop.

    Pour être très rapide mais en même temps persistant, tout le jeu de données est pris en mémoire et de temps en temps et / ou lorsqu’un certain nombre de modifications du jeu de données sont effectuées, il est écrit de manière asynchrone sur le disque. Vous risquez de perdre les dernières requêtes acceptables dans de nombreuses applications, mais il est aussi rapide qu’une firebase database 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 plutôt 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 pouvoir le remplir à nouveau -demand, chaque fois que c’est nécessaire – encore, je l’avoue, il pourrait y avoir des problèmes de performance si tout votre cluster memcached tombe immédiatement …

    Ainsi, peut-être que certains logiciels “plus” orientés sur la clé / valeur pourraient 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, mais …

    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 besoins, lors de l’exécution en mode dissortingbué, 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 à vos besoins. Il est également encore en développement actif, ce que beaucoup d’autres frameworks de mise en cache Java ne sont pas.

    Essayez go-memcached – le serveur memcache écrit dans 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 manque les fonctionnalités suivantes dans le memcached d’ origine:

    • 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 taille de la valeur. La taille de la valeur est en réalité limitée par 2 Go.
    • C’est plus rapide que l’original memcached . Il utilise également moins de processeur lors de la réception des demandes entrantes.

    Voici les performances obtenues 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 | ----------------------------------------------------- 

    Des fichiers binarys liés statiquement pour go-memcached et go-memcached-bench sont disponibles sur la page des téléchargements .

    Jetez un coup d’œil au système de cache Java Apache (JCS)

    JCS est un système de mise en cache dissortingbué en Java. Il est destiné à accélérer les applications en fournissant un moyen de gérer les données mises en cache de différentes natures dynamics. Comme tout système de mise en cache, JCS est particulièrement utile pour les applications à haute lecture et faible. Les temps de latence diminuent fortement et les goulots d’étranglement s’éloignent de la firebase database dans un système effectivement mis en cache. Apprenez à utiliser JCS.

    Le JCS va au-delà de la simple mise en cache d’objects 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 dissortingbution 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 resortingeval * Network efficient multi-key resortingeval 

    Je pense que la membase est ce que tu veux.

    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, partagées (essentiellement le même magasin clé-valeur, mais basé sur le disque). La façon la plus simple de le faire est de toujours lire à partir de memcached et de revenir à un partage et de toujours écrire dans sharedanced et memcached.

    Vous pouvez mettre à l’échelle les écritures en les partageant entre plusieurs instances de partage. Vous pouvez mettre à l’échelle les lectures N-fold en utilisant une solution comme repcached (memcached répliqué).

    Si ce n’est pas sortingvial pour vous, vous pouvez toujours utiliser sharedanced comme remplacement de base de memcached. Il est rapide, la plupart des appels de systèmes de fichiers sont finalement mis en cache – l’utilisation de memcached en combinaison avec la méthode de partage évite la lecture de fichiers partagés 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 qui n’est pas vraiment un problème, à moins que vous ayez une concurrence élevée pour les mêmes clés et que les clients recherchent la même clé.

    Il y a certains problèmes si vous avez affaire à un environnement à trafic très élevé, le premier est le choix du système de fichiers (reiserfs fonctionne 5 à 10 fois mieux que ext3 à cause de la mise en cache interne de l’arborescence). est plutôt une surcharge si vous utilisez uniquement le partage, memcached a udp grâce à l’équipe facebook) et la mise à l’échelle se fait généralement sur votre application (en partageant les données entre plusieurs instances de serveurs partagés).

    Si vous pouvez exploiter ces facteurs, cela pourrait être une bonne solution pour vous. Dans notre configuration actuelle, un serveur partagé unique / memcache peut atteindre environ 10 millions de pages vues par jour, mais cela dépend des applications. 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 telles que Hash, Lists, etc.

    Qu’en est-il de la terre cuite ?

    Oracle NoSQL est basé sur BerkeleyDB (la solution pointée par Bill Karwin), mais ajoute du sharding (partitionnement du jeu de données) et du scale-out élastique. Voir: http://www.oracle.com/technetwork/products/nosqldb/overview/index.html

    Je pense que cela répond à toutes les exigences de la question initiale.

    Dans un souci de transparence, je travaille chez Oracle (mais pas sur le produit Oracle NoSQL). Les opinions et opinions exprimées dans cet article sont les miennes et ne reflètent pas nécessairement les opinions ou les opinions de mon employeur.

    Couchbase peut remplacer memcached – il s’agit d’une source ouverte et commerciale de cette gamme de produits. Il a des données à la persistance du disque (très efficace et configurable). Les auteurs originaux de memcached ont également travaillé sur Couchbase et sont compatibles avec le protocole memcached – vous n’avez donc pas besoin de modifier le code de votre application client! Son produit très performant est fourni avec un clustering 24/7 et une réplication XDCR (Cross Datacenter Replication) intégrée. Voir le document technique .

    Vous pouvez utiliser Tarantool ( http://tarantool.org ). Il s’agit d’une firebase database en mémoire avec des règles de persistance, de réplication maître-maître et d’expiration de clés scriptables – https://github.com/tarantool/expirationd

    Avez-vous regardé BerkeleyDB ?

    • Gestion rapide et intégrée des données en cours.
    • Magasin clé / valeur, 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 dissortingbuée, mais les données ne sont pas partitionnées. Chaque nœud stocke l’dataset complet.

    Nous utilisons OSCache . Je pense que cela répond à presque tous vos besoins, sauf la sauvegarde périodique du cache sur le disque, mais vous devriez pouvoir créer 2 gestionnaires de cache (un basé sur la mémoire et un sur le disque dur) et lancer périodiquement java cronjob sur toutes les clés en mémoire. paires de valeurs et les met dans le cache hdd. Ce qui est bien avec OSCache, c’est qu’il est très facile à utiliser.

    Vous pouvez utiliser GigaSpaces XAP, un produit commercial mature qui répond à vos besoins et plus encore. C’est la grid de données en mémoire dissortingbuée la plus rapide (cache ++), elle est entièrement dissortingbuée et prend en charge plusieurs styles de méthodes de persistance.

    Guy Nirpaz, GigaSpaces

    Juste pour compléter cette liste – je viens de trouver couchbase . Cependant, je ne l’ai pas encore testé.