Quelle est la meilleure méthode de sérialisation pour les objets dans memcached?

Question

Mon application Python utilise actuellement la API python-memcached pour définir et obtenir des objets dans memcached. Cette API utilise le module pickle natif de Python pour sérialiser et désérialiser les objets Python.

Cette API simplifie et accélère l'enregistrement de memcached dans les listes Python, les dictionnaires et les nuplets imbriqués. La lecture de ces objets dans l'application est totalement transparente: elle fonctionne simplement.

Mais je ne veux pas être limité à l’utilisation exclusive de Python, et si tous les objets memcached sont sérialisés avec pickle, les clients écrits dans d’autres langues ne fonctionneront pas.

Voici la sérialisation multiplateforme. options que j'ai envisagées:

1. XML - L'avantage principal est qu'il est lisible par l'homme, mais ce n'est pas important dans cette application. XML prend également beaucoup de place et son analyse coûte cher.

2. JSON - semble être un bon standard pour plusieurs plates-formes, mais je ne suis pas sûr qu'il conserve le caractère des types d'objet lors de la lecture à partir de memcached. Par exemple, selon cette publication , les n-uplets sont transformés en listes lorsqu’on utilise simplejson ; de plus, il semble que l'ajout d'éléments à la structure JSON pourrait endommager le code écrit dans l'ancienne structure

3. tampons de protocole Google - cela m'intéresse beaucoup parce qu'il semble très rapide et compact - au moins 10 fois plus petit et plus rapide que XML; ce n'est pas lisible par l'homme, mais ce n'est pas important pour cette application; et il semble conçu pour prendre en charge la croissance de la structure sans casser l'ancien code

Considérant les priorités de cette application, quelle est la méthode de sérialisation d'objet idéale pour memcached?

1. Prise en charge multi-plateformes (Python, Java, C #, C ++, Ruby, Perl)

2. Gestion des structures de données imbriquées

3. Sérialisation / dé-sérialisation rapides

4. Encombrement mémoire minimum

5. Flexibilité de changer de structure sans détruire l'ancien code

Answer 1

J'ai essayé plusieurs méthodes et choisi le format JSON compressé comme meilleur compromis entre vitesse et encombrement mémoire. La fonction native de pickle de Python est légèrement plus rapide, mais les objets résultants ne peuvent pas être utilisés avec des clients non Python.

Je vois une compression 3: 1 pour que toutes les données soient stockées dans memcache et que l'application obtienne des temps de réponse inférieurs à 10 ms, y compris le rendu des pages.

Voici une comparaison de JSON, Thrift, Protocol Buffers et YAML, avec et sans compression:

http://bouncybouncy.net/ramblings/posts/more_on_js_l >

On dirait que ce test a les mêmes résultats que ceux obtenus avec du JSON compressé. Comme je n'ai pas besoin de prédéfinir chaque structure, cela semble être la réponse multiplate-forme la plus rapide et la plus petite.

Answer 2

Un élément important à prendre en compte est & "voulez-vous spécifier chaque définition de structure &"; ?

Si cela vous convient, vous pouvez jeter un coup d'œil à:

1. Tampons de protocole - http://code.google.com/apis/protocolbuffers /docs/overview.html
2. Thrift - http://developers.facebook.com/thrift/ (plus axé sur les services) )

Ces deux solutions nécessitent des fichiers de support pour définir chaque structure de données.

Si vous préférez ne pas engager la surcharge du développeur pour la définition préalable de chaque structure, consultez:

1. JSON (via python cjson et json PHP natif). Les deux sont vraiment très rapides si vous n’avez pas besoin de transmettre un contenu binaire (tel que des images, etc.).
2. Un autre langage de balisage @ http://www.yaml.org/ . Aussi très vite si vous avez la bonne bibliothèque.

Cependant, je pense que le transport de contenu binaire pose des problèmes à ces deux applications. C’est pourquoi elles ont été exclues pour notre utilisation. Remarque: YAML peut disposer d'un bon support binaire. Vous devrez vérifier les bibliothèques clientes - voir ici: http://yaml.org/type/binary.html

Dans notre société, nous avons mis en place notre propre bibliothèque (Extruct) pour la sérialisation multilingue avec support binaire. Nous avons actuellement des implémentations (décentes) rapides en Python et PHP, bien que ce ne soit pas très lisible en raison de l’utilisation de base64 sur toutes les chaînes (support binaire). Finalement, nous les porterons en C et utiliserons un codage plus standard.

Les langages dynamiques comme PHP et Python deviennent très lents si vous avez trop d'itérations dans une boucle ou si vous devez regarder chaque caractère. C, d’autre part, brille lors de telles opérations.

Si vous souhaitez voir la mise en oeuvre d'Extruct, veuillez me le faire savoir. (informations de contact sur http://blog.gahooa.com/ sous & "À propos de moi quot;)

Answer 3

& "; Support multiplateforme (Python, Java, C #, C ++, Ruby, Perl) &";

Dommage que ce critère soit premier. L'intention de la plupart des langues est d'exprimer les structures de données fondamentales et le traitement différemment. C'est ce qui fait de plusieurs langues un & "Problème &" ;: elles sont toutes différentes.

Une représentation unique valable dans de nombreuses langues est généralement impossible. Il y a des compromis sur la richesse de la représentation, de la performance ou de l'ambiguïté.

JSON remplit bien les critères restants. Les messages sont compacts et analysés rapidement (contrairement à XML). La nidification est bien gérée. Changer de structure sans casser le code est toujours douteux - si vous supprimez quelque chose, l'ancien code sera brisé. Si vous modifiez quelque chose qui était requis, l'ancien code sera brisé. Si vous ajoutez des éléments, JSON s'en charge également.

J'aime lisible par l'homme. Cela facilite beaucoup le débogage et le dépannage.

La subtilité de transformer les nuplets Python en listes n'est pas un problème intéressant. L’application destinataire connaît déjà la structure en cours de réception et peut la modifier (si cela importe).

Modifiez les performances.

Analyse des documents XML et JSON de http://developers.de/blogs/damir_dobric/archive/2008/12/27/performance-comparison-soap-vs-json-wcf-implementation.aspx

xmlParse 0.326 jsonParse 0.255

JSON semble être nettement plus rapide pour le même contenu. J'ai utilisé les modules Python SimpleJSON et ElementTree dans Python 2.5.2.

Answer 4

Ce lien pourrait vous intéresser:

http://kbyanc.blogspot.com/2007/07 /python-serializer-benchmarks.html

Une alternative: MessagePack semble être le sérialiseur le plus rapide du marché. Peut-être que vous pouvez essayer.

Answer 5

Hessian répond à toutes vos exigences. Il existe une bibliothèque python ici:

https://github.com/bgilmore/mustaine

La documentation officielle du protocole se trouve ici:

http://hessian.caucho.com/

Je l’utilise régulièrement en Java et en Python. Cela fonctionne et ne nécessite pas l'écriture de fichiers de définition de protocole. Je ne saurais vous dire comment le sérialiseur Python fonctionne, mais la version Java est raisonnablement efficace:

https://github.com/eishay/jvm-serializers/wiki/