التبديل من MySQL إلى Cassandra - إيجابيات/سلبيات؟
https://stackoverflow.com/questions/2332113
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
للحصول على معلومات أساسية بسيطة - يتناول هذا السؤال مشروعًا يعمل على مثيل EC2 صغير واحد، وهو على وشك الانتقال إلى مثيل متوسط.المكونات الرئيسية هي Django و MySQL وعدد كبير من أدوات التحليل المخصصة المكتوبة في Python و Java ، والتي تقوم بالرفع الثقيل.نفس الجهاز يعمل بنظام Apache أيضًا.
يبدو نموذج البيانات كما يلي - يتم تدفق كمية كبيرة من البيانات في الوقت الفعلي من أجهزة استشعار مختلفة متصلة بالشبكة، ومن الناحية المثالية، أرغب في إنشاء نهج استطلاع طويل بدلاً من الاستطلاع الحالي كل 15 دقيقة (حد من إحصائيات الحوسبة والكتابة في قاعدة البيانات نفسها).بمجرد وصول البيانات ، أقوم بتخزين الإصدار الخام في MySQL ، والسماح لأدوات التحليل بالتفوق على هذه البيانات ، وتخزين الإحصائيات في جداول قليلة أخرى.يتم تقديم كل هذا باستخدام Django.
الميزات العلائقية التي سأحتاجها -
- ترتيب حسب [يبدو أن SliceRange في واجهة برمجة تطبيقات Cassandra تفي بهذا]
- مجموعة من
- علاقات عديدة ومتعددة بين جداول متعددة [يبدو أن Cassandra SuperColumns تعمل بشكل جيد بالنسبة لشخص واحد للكثيرين]
- أبو الهول في هذا يعطيني محرك نص كامل لطيف، لذلك هذا ضروري أيضًا. [في كاساندرا، يبدو أن مشروع لوساندرا يلبي هذه الحاجة]
مشكلتي الرئيسية هي أن قراءة البيانات بطيئة للغاية (وعمليات الكتابة ليست بهذه السرعة أيضًا).لا أرغب في إنفاق الكثير من المال والأجهزة عليه الآن، وأفضّل شيئًا يمكن التوسع فيه بسهولة بمرور الوقت.إن تحجيم MySQL عموديًا ليس أمرًا تافهًا بهذا المعنى (أو رخيصًا).
لذا، بعد أن قرأت الكثير عن NOSQL وجربت أشياء مثل MongoDB وCassandra وVoldemort، أسئلتي هي،
على مثيل EC2 المتوسط، هل سأحصل على أي فوائد في عمليات القراءة/الكتابة من خلال التحول إلى شيء مثل Cassandra? هذا المقال (pdf) يبدو بالتأكيد أنه يشير إلى ذلك.حاليًا، أود أن أقول إن بضع مئات من عمليات الكتابة في الدقيقة ستكون هي القاعدة.بالنسبة للقراءات - نظرًا لأن البيانات تتغير كل 5 دقائق أو نحو ذلك، فإن إبطال ذاكرة التخزين المؤقت يجب أن يحدث بسرعة كبيرة.وفي مرحلة ما، يجب أن يكون قادرًا على التعامل مع عدد كبير من المستخدمين المتزامنين أيضًا.يتم إيقاف أداء التطبيق حاليًا على MySQL من خلال إجراء بعض الصلات على جداول كبيرة حتى إذا تم إنشاء الفهارس - يستغرق عرض شيء يصل إلى 32 ألف صف أكثر من دقيقة.(قد يكون هذا أيضًا أحد عناصر الإدخال/الإخراج الافتراضية لـ EC2).يبلغ حجم الجداول حوالي 4-5 مليون صف، وهناك حوالي 5 جداول من هذا القبيل.
يتحدث الجميع عن استخدام كاساندرا على عقد متعددة، في ضوء نظرية CAP والاتساق النهائي.لكن بالنسبة لمشروع بدأ للتو في النمو، هل من المنطقي نشر خادم كاساندرا عقدة واحدة؟هل هناك أي محاذير؟على سبيل المثال، هل يمكن استبدال MySQL كواجهة خلفية لـ Django؟[هل هذا مستحسن؟]
إذا قمت بالتحويل، أعتقد أنه سيتعين علي إعادة كتابة أجزاء من التطبيق للقيام بالكثير من "الإدارة" حيث يتعين علي إجراء عمليات بحث متعددة لجلب الصفوف.
هل سيكون من المنطقي استخدام MySQL كمخزن قيمة رئيسي؟ بدلا من محرك العلائقية، وتذهب مع ذلك؟وبهذه الطريقة يمكنني الاستفادة من عدد كبير من واجهات برمجة التطبيقات المستقرة المتاحة، بالإضافة إلى محرك مستقر (والانتقال إلى الارتباط حسب الحاجة).(منشور بريت تايلور من Friendfeed حول هذا - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)
أي رؤى من الأشخاص الذين قاموا بالتحول ستكون موضع تقدير كبير!
شكرًا.
المحلول
لا توفر Cassandra وقواعد البيانات الموزعة الأخرى المتوفرة اليوم نوع دعم الاستعلام المخصص الذي اعتدت عليه من SQL.وذلك لأنه لا يمكنك توزيع الاستعلامات ذات الصلات بشكل فعال، لذا يتم التركيز على إلغاء التسوية بدلاً من ذلك.
ومع ذلك، فإن Cassandra 0.6 (الإصدار التجريبي سيصدر رسميًا غدًا، ولكن يمكنك البناء من الفرع 0.6 بنفسك إذا كنت غير صبور) يدعم خريطة/تقليل Hadoop للتحليلات، والذي يبدو في الواقع مناسبًا لك.
توفر Cassandra دعمًا ممتازًا لإضافة عقد جديدة بدون ألم، حتى إلى مجموعة أولية مكونة من عقدة واحدة.
ومع ذلك، في بضع مئات من عمليات الكتابة/الدقيقة، ستكون جيدًا في استخدام MySQL لفترة طويلة جدًا.تعد Cassandra أفضل بكثير في كونها مخزنًا للمفتاح/القيمة (والأفضل من ذلك، عائلة المفتاح/العمود) ولكن MySQL أفضل بكثير في كونها قاعدة بيانات علائقية.:)
لا يوجد دعم django لـ Cassandra (أو قاعدة بيانات nosql أخرى) حتى الآن.إنهم يتحدثون عن القيام بشيء ما للإصدار التالي بعد 1.2، ولكن بناءً على التحدث إلى مطوري Django في pycon، لا أحد متأكد حقًا كيف سيبدو ذلك بعد.
نصائح أخرى
إذا كنت مطور قواعد بيانات علائقية (مثلي)، فأنا أقترح/أشير إلى:
- احصل على بعض الخبرة في العمل مع Cassandra قبل أن تلتزم باستخدامه في نظام الإنتاج...خاصة إذا كان نظام الإنتاج هذا لديه موعد نهائي صعب للانتهاء.ربما استخدمه كواجهة خلفية لشيء غير مهم أولاً.
- لقد كان الأمر أكثر صعوبة مما توقعت أن أقوم بأشياء بسيطة أعتبرها أمرًا مفروغًا منه فيما يتعلق بمعالجة البيانات باستخدام محركات SQL.وعلى وجه الخصوص، فإن فهرسة البيانات وفرز مجموعات النتائج ليس بالأمر الهين.
- لقد أثبتت نمذجة البيانات أنها صعبة أيضًا.باعتبارك مطور قواعد بيانات علائقية، فإنك تأتي إلى الطاولة ومعك الكثير من الأمتعة...يجب أن تكون على استعداد لتعلم كيفية نمذجة البيانات بشكل مختلف تمامًا.
قالت هذه الأشياء، أوصي بشدة بالبناء شئ ما في كاساندرا.إذا كنت مثلي، فإن القيام بذلك سوف يتحدى فهمك لتخزين البيانات ويجعلك تعيد التفكير في النظرة المستقبلية لقاعدة البيانات العلائقية التي تناسب جميع المواقف والتي لم أكن أدرك حتى أنني أحملها.
بعض الموارد الجيدة التي وجدتها تشمل:
يعد Django-cassandra وضعًا تجريبيًا مبكرًا.كما أن Django لم يصنع قواعد بيانات بدون SQL.يعتمد المفتاح في Django ORM على SQL (يوصي Django باستخدام PostgreSQL).إذا كنت بحاجة إلى استخدام no-sql فقط (يمكنك مزج sql وno-sql في نفس التطبيق)، فأنت بحاجة إلى استخدام no-sql ORM بشكل محفوف بالمخاطر (وهو أبطأ بكثير من SQL orm التقليدي أو الاستخدام المباشر للتخزين No-SQL).أو ستحتاج إلى إعادة كتابة Django ORM بالكامل.ولكن في هذه الحالة لا أستطيع أن أفترض، لماذا تحتاج إلى جانغو.ربما يمكنك استخدام شيء آخر، مثل تورنادو؟
