ما هي بعض حالات الاستخدام الحقيقية للذهاب مع متجر مستندات NOSQL؟

Question

لقد قرأت الوثائق ومشاهدة Screencasts خاصة بـ Mongo DB خلال الأيام القليلة الماضية ، وأنا في حيرة من العمر عندما يكون حل كهذا أفضل من بيئة PG أو MySQL النموذجية.

على وجه التحديد ، سؤالي تحت أي ظرف من الظروف (مع حالة الاستخدام ستكون لطيفة) هل ترغب في الذهاب إلى طريق NOSQL؟

شكرًا!

Answer 1

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

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

3. تكرار النطاق الترددي المنخفض. بمجرد كسر الحمض ، يمكنك أن يكون لديك القراء والكتاب على العقد الورقية لرسم بياني للشبكة مع بيانات جزئية لا تحتاج إلى نسخ متماثلة كاملة من قاعدة البيانات. يستخدم منتج شركتي الخاص ، وظيفة قيادة الجيش في المستقبل هذا.

4. قابلية التشغيل البيني للبيانات. تتيح لك معظم قواعد بيانات NOSQL إدخال البيانات دون معرفة المخطط في وقت مبكر ، مما يسمح بالاتصالات بين الأنظمة المتباينة بشكل أسهل.

5. التحجيم الهائل. هذا هو أكثر ما نوقش ، وغالبًا ما يتعرض للإساءة من قبل مؤيدي NOSQL. إذا كان هذا هو السبب الوحيد وراء اختيار NOSQL ، فابدأ بـ MySQL بدلاً من ذلك وتوسيع نطاقه لاحقًا.

Answer 2

حالة الاستخدام
نستخدم mongoDB لهيكل بيانات عابر للغاية. يعمل في الواقع كجور / مدير وظيفة مع العديد من وحدات العمل التي تتم معالجتها كل ثانية. لا تحتوي وحدة العمل على مخطط محدد (يتم اختراع وحدات مختلفة بشكل متكرر إلى حد ما) ومع ذلك نحتاج إلى القدرة على الاستعلام عن حقول أو خصائص محددة دون تكرارها على DB بأكمله. لذلك لتلخيص: عابرة للغاية ومتاحة للغاية (لا يمكن أن تمنع الاستعلام) مع حمولة عمل تبلغ حوالي 600QPS لجهاز "سلعة" واحد يعمل في السحابة.

حقيقة الأمر هي أنه من الصعب للغاية القيام الشيء نفسه على جهاز SQL مع الحفاظ على نفس التكاليف.

حالات الاستخدام الشائعة الأخرى لـ MongoDB (أيضًا بالنسبة لنا) هي جمع إحصائي ، فهي فعالة للغاية في زيادة خصائص محددة داخل المستندات ، وأكثر من ذلك بكثير ثم معظم أنظمة RDBMS.

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

Answer 3

REST REST APIS RETRESS JSON (على سبيل المثال ، العديد من افتح واجهات برمجة التطبيقات للحكومة). إذا كنت ترغب في تفريغ بيانات REST إلى متجر بيانات محلي (في حالة حاجة إلى تشغيل التحليل ، إلخ) ، فإن تناول كائن JSON مع MongoDB أمر تافلي. لا حاجة لتحديد مخطط الجدول. والأفضل من ذلك ، إذا تغير كائن JSON مع مرور الوقت (على سبيل المثال ، تقوم API REST بإرجاع حقول إضافية) ، فلا يزال بإمكانك تناول البيانات في خطوة واحدة. جرب ذلك بقاعدة بيانات علائقية!