أحتاج إلى نصيحة حول NOSQL/MongoDB وهيكل البيانات/النماذج

Question

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

دعنا نقول أن لدينا هذه النماذج الثلاثة:

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

أريد أن أكون قادرًا على طرح قاعدة البيانات هذه الأسئلة:

• من الذي صوت لهذه القصة؟
• ما الذي صوت هذا المستخدم؟

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

على سبيل المثال ، إذا قمت بتخزين كائنات التصويت باعتبارها مجموعة فرعية للقصص ، فلن يكون من السهل الحصول على المعلومات - "ما صوت المستخدم لصالحه".

Answer 1

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

db.users.find({stories: story_id})

أين story_id هل _id من القصة المعنية. إذا قمت بإنشاء فهرس على stories حقل كل من هذين الاستفسارات سيكون سريعا.

Answer 2

• لا تقلق إذا كانت استفساراتك فعالة حتى يبدأ الأمر
• وفقًا للاقتباس أدناه ، أنت تفعل ذلك بشكل خاطئ

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

إرشادات الإبلاغ عن الاشتراكات في عمليات البيانات

Answer 3

حسنًا ، لقد أعطيت نموذج بيانات طبيعي كما ستفعل في إعداد SQL.

في فهمي أنك لا تفعل هذا في Mongodb. يمكنك تخزين المراجع ، لكنك لا تفعل أسباب الأداء في الحالة العامة.

أنا لست خبيراً في منطقة NOSQL بأي حال من الأحوال ، ولكن لماذا لا تتبع احتياجاتك وتخزين المستخدم (IDS) الذي صوت لصالح قصة في مجموعة القصص والقصة (IDS) لدى المستخدم صوتت لصالح مجموعة المستخدمين؟

Answer 4

في couchdb هذا بسيط جدا. منظر واحد ينبعث:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.story_id, doc.user_id);
 }
}

وجهة نظر أخرى تنبعث منها:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.user_id, doc.story_id);
 }
}

كلاهما استفسارات سريع للغاية لأنه لا يوجد انضمام. إذا كنت بحاجة إلى بيانات المستخدم أو بيانات القصة ، فإن CouchDB يدعم إحضار متعدد الوثيقة. أيضا بسرعة كبيرة وهي إحدى الطرق للقيام بـ "الانضمام".

Answer 5

لقد كنت أبحث في Mongodb و Couchdb كثيرًا مؤخرًا ، لكن رؤيتي محدودة. ومع ذلك ، عند التفكير في تخزين الأصوات داخل وثيقة القصة ، قد تضطر إلى القلق بشأن ضرب حد حجم وثيقة 4MB. حتى لو لم تقم بذلك ، فقد تقوم باستمرار بزيادة حجم الوثيقة بما يكفي لتتسبب في تحريكه وبالتالي إبطاء كتاباتك (انظر كيف يتم حجم المستندات في MongoDB).

أما بالنسبة إلى CouchDB ، فإن هذه الأنواع من الأشياء بسيطة للغاية وأنيقة وسريعة جدًا بمجرد حساب فهارس العرض. ومع ذلك ، فقد ترددت شخصياً في القيام بمشروع مماثل في CouchDB بسبب المعايير التي تبين أنها تبطئ تدريجياً إلى درجة كبيرة مع نمو قاعدة البيانات (وتنمو فهارس العرض). أحب أن أرى بعض المعايير الحديثة التي تظهر أداء CouchDB مع زيادة حجم قاعدة البيانات. أريد أن أجرب mongodb أو couchdb ، لكن SQL لا يزال يبدو فعالًا ومنطقيًا للغاية ، لذلك سأبقى معه حتى يناسب المشروع الإغراء بشكل صحيح.