ما هي أفضل طريقة لتسلسل الكائنات في memcached؟

Question

يستخدم تطبيق Python الخاص بي حاليًا واجهة برمجة تطبيقات بايثون memcached لتعيين والحصول على الكائنات في memcached.تستخدم واجهة برمجة التطبيقات هذه لغة Python الأصلية وحدة المخلل لإجراء تسلسل وإلغاء تسلسل كائنات بايثون.

تعمل واجهة برمجة التطبيقات هذه على تسهيل وسرعة تخزين قوائم Python والقواميس والصفوف المتداخلة في memcached، كما أن قراءة هذه الكائنات مرة أخرى في التطبيق تكون شفافة تمامًا - فهي تعمل فقط.

لكنني لا أريد أن أقتصر على استخدام بايثون حصريًا، وإذا تم إجراء تسلسل لجميع كائنات memcached باستخدام Pickle، فلن يعمل العملاء المكتوبون بلغات أخرى.

فيما يلي خيارات التسلسل عبر الأنظمة الأساسية التي فكرت فيها:

1. XML - الفائدة الرئيسية هي أنه يمكن قراءته بواسطة الإنسان، ولكن هذا ليس مهمًا في هذا التطبيق.يشغل XML أيضًا مساحة كبيرة، كما أن تحليله مكلف.

2. JSON - يبدو وكأنه معيار جيد عبر الأنظمة الأساسية، لكنني لست متأكدًا من أنه يحتفظ بخصائص أنواع الكائنات عند قراءتها مرة أخرى من memcached.على سبيل المثال، وفقا ل هذا المشنور يتم تحويل الصفوف إلى قوائم عند الاستخدام com.simplejson;يبدو أيضًا أن إضافة عناصر إلى بنية JSON قد يؤدي إلى كسر التعليمات البرمجية المكتوبة في البنية القديمة

3. مخازن بروتوكول جوجل - أنا مهتم حقًا بهذا لأنه يبدو سريعًا جدًا ومضغوطًا - على الأقل 10 مرات أصغر وأسرع من XML؛إنها ليست قابلة للقراءة من قبل الإنسان، ولكن هذا ليس مهما لهذا التطبيق؛ويبدو أنه مصمم لدعم تنمية الهيكل دون كسر التعليمات البرمجية القديمة

بالنظر إلى أولويات هذا التطبيق، ما هي الطريقة المثالية لتسلسل الكائنات لـ memcached؟

1. دعم عبر الأنظمة الأساسية (Python، Java، C#، C++، Ruby، Perl)

2. التعامل مع هياكل البيانات المتداخلة

3. التسلسل السريع/إلغاء التسلسل

4. الحد الأدنى من مساحة الذاكرة

5. المرونة في تغيير الهيكل دون كسر التعليمات البرمجية القديمة

Answer 1

لقد جربت عدة طرق واستقرت على JSON المضغوط كأفضل توازن بين السرعة وبصمة الذاكرة.تعد وظيفة Pickle الأصلية في Python أسرع قليلاً، ولكن لا يمكن استخدام الكائنات الناتجة مع عملاء غير Python.

أرى ضغطًا بنسبة 3:1 بحيث يتم احتواء جميع البيانات في ذاكرة التخزين المؤقت ويحصل التطبيق على أوقات استجابة أقل من 10 مللي ثانية بما في ذلك عرض الصفحة.

فيما يلي مقارنة بين JSON وThrift وProtocol Buffers وYAML، مع الضغط وبدونه:

http://bouncybouncy.net/ramblings/posts/more_on_json_vs_thrift_and_protocol_buffers/

يبدو أن هذا الاختبار حصل على نفس النتائج التي حصلت عليها مع JSON المضغوط.نظرًا لأنني لا أحتاج إلى تحديد كل بنية مسبقًا، يبدو أن هذا هو أسرع وأصغر إجابة عبر الأنظمة الأساسية.

Answer 2

أحد الاعتبارات الرئيسية هو "هل تريد تحديد كل تعريف للبنية"?

إذا كنت موافقًا على ذلك، فيمكنك إلقاء نظرة على:

1. المخازن المؤقتة للبروتوكول - http://code.google.com/apis/protocolbuffers/docs/overview.html
2. التوفير - http://developers.facebook.com/thrift/ (أكثر توجها نحو الخدمات)

يتطلب كلا الحلين ملفات دعم لتحديد كل بنية بيانات.

---

إذا كنت تفضل عدم تحمل المطور تكاليف إضافية للتعريف المسبق لكل بنية، فقم بإلقاء نظرة على:

1. JSON (عبر python cjson، و PHP json الأصلي).كلاهما سريع حقًا إذا لم تكن بحاجة إلى نقل محتوى ثنائي (مثل الصور، وما إلى ذلك...).
2. لغة ترميزية أخرى @ http://www.yaml.org/.سريع جدًا أيضًا إذا حصلت على المكتبة المناسبة.

ومع ذلك، أعتقد أن كلاهما واجه مشكلات في نقل المحتوى الثنائي، ولهذا السبب تم استبعادهما لاستخدامنا. ملحوظة: قد يكون لدى YAML دعم ثنائي جيد، سيتعين عليك التحقق من مكتبات العميل - انظر هنا: http://yaml.org/type/binary.html

---

في شركتنا، قمنا بطرح مكتبتنا الخاصة (Extruct) للتسلسل عبر اللغات بدعم ثنائي.لدينا حاليًا تطبيقات سريعة (لائقة) في Python وPHP، على الرغم من أنها ليست قابلة للقراءة من قبل الإنسان نظرًا لاستخدام base64 على جميع السلاسل (الدعم الثنائي).في النهاية، سنقوم بنقلها إلى لغة C واستخدام المزيد من التشفير القياسي.

تصبح اللغات الديناميكية مثل PHP وPython بطيئة جدًا إذا كان لديك عدد كبير جدًا من التكرارات في حلقة أو كان عليك إلقاء نظرة على كل حرف.C من ناحية أخرى يضيء في مثل هذه العمليات.

إذا كنت ترغب في رؤية تنفيذ Extruct، فيرجى إبلاغي بذلك.(معلومات الاتصال على http://blog.gahooa.com/ ضمن "نبذة عني")

Answer 3

"دعم عبر الأنظمة الأساسية (Python، Java، C#، C++، Ruby، Perl)"

سيئة للغاية هذه المعايير هي الأولى.الهدف من معظم اللغات هو التعبير عن هياكل البيانات الأساسية ومعالجتها بشكل مختلف.هذا ما يجعل اللغات المتعددة "مشكلة":كلهم مختلفون.

من المستحيل عمومًا تقديم تمثيل واحد جيد عبر العديد من اللغات.هناك تنازلات في ثراء التمثيل أو الأداء أو الغموض.

JSON يلبي المعايير المتبقية بشكل جيد.الرسائل مضغوطة ويتم تحليلها بسرعة (على عكس XML).يتم التعامل مع التعشيش بشكل جيد.يعد تغيير البنية دون كسر التعليمات البرمجية أمرًا غير واضح دائمًا - إذا قمت بإزالة شيء ما، فسيتم كسر التعليمات البرمجية القديمة.إذا قمت بتغيير شيء مطلوب، فسوف ينكسر الكود القديم.ومع ذلك، إذا كنت تضيف أشياء، فإن JSON يتعامل مع هذا أيضًا.

أنا أحب أن يقرأها الإنسان.فهو يساعد في الكثير من التصحيح واستكشاف الأخطاء وإصلاحها.

إن الدقة في تحويل صفوف بايثون إلى قوائم ليست مشكلة مثيرة للاهتمام.يعرف التطبيق المتلقي بالفعل البنية التي يتم استلامها، ويمكنه تعديلها (إذا كان ذلك مهمًا).

---

تحرير على الأداء.

تحليل مستندات XML وJSON من 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 أسرع بشكل ملحوظ لنفس المحتوى.لقد استخدمت وحدات Python SimpleJSON وElementTree في Python 2.5.2.

Answer 4

قد يهمك هذا الرابط:

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

بديل :يبدو أن MessengerPack هو أسرع برنامج تسلسلي موجود.ربما يمكنك تجربتها

Answer 5

هسه يلبي جميع الاحتياجات الخاصة بك.توجد مكتبة بايثون هنا:

https://github.com/bgilmore/mustaine

يمكن العثور على الوثائق الرسمية للبروتوكول هنا:

http://hessian.caucho.com/

أستخدمه بانتظام في كل من Java وPython.إنه يعمل ولا يتطلب كتابة ملفات تعريف البروتوكول.لا أستطيع أن أخبرك بكيفية أداء مُسلسِل Python، لكن إصدار Java فعال بشكل معقول:

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