سؤال

لدي مشروع مع تطبيقان (كتب وقارئ).

يحتوي تطبيق الكتب على طاولة مع 4 ملليونات من الصفوف مع هذه الحقول:

 book_title = models.CharField(max_length=40)
 book_description = models.CharField(max_length=400)

لتجنب الاستعلام عن قاعدة البيانات بـ 4 ملليونات من الصفوف ، أفكر في تقسيمها على الموضوع (20 نموذجًا يحتوي على 20 جدولًا يحتوي على 200.000 صف (Book_Horror ، Book_drammatic ، ECC).

في تطبيق "القارئ" ، أفكر في إدراج هذه الحقول:

reader_name = models.CharField(max_length=20, blank=True)
book_subject = models.IntegerField()
book_id = models.IntegerField()

لذا ، بدلاً من ForeignKey ، أفكر في استخدام عدد صحيح "book_subject" (والذي يسمح للوصول إلى الجدول المناسب) و "book_id" (الذي يسمح للوصول إلى الكتاب في الجدول المحدد في "book_subject").

هل الحل الجيد لتجنب الاستعلام عن طاولة مع 4 ملليونات من الصفوف؟

هل يوجد حل بديل؟

شكرا ^__ ^

هل كانت مفيدة؟

المحلول

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

الفهارس هي الخطوة الأولى ، يبدو أنك فعلت هذا. يجب أن يكون 4 ملايين صف على ما يرام بالنسبة إلى DB للتعامل مع فهرس.

ثانياً ، تحقق من عدد الاستفسارات التي تقوم بتشغيلها. يمكنك القيام بذلك بشيء مثل شريط أدوات Django Debug ، وستفاجأ غالبًا بعدد الاستعلامات غير الضرورية.

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

إذا كنت حقًا ، فعلاً إلى تقسيم الجداول ، يمكن لأحدث إصدار من Django (1.2 alpha) التعامل مع Sharding (على سبيل المثال Multi-DB) ، ويجب أن تكون قادرًا على كتابة حل أقسام أفقي (Postgres يوفر DB في DB طريقة للقيام بذلك). من فضلك لا تستخدم النوع لتقسيم الجداول! اختر شيئًا لن تتغير عليه أبدًا ، وسوف تعرفه دائمًا عند إجراء استعلام. مثل المؤلف وتقسيمه على الحرف الأول من اللقب أو شيء من هذا القبيل. هذا هو الكثير من الجهد ولديه عدد من العيوب لقاعدة بيانات ليست كبيرة بشكل خاص-وهذا هو السبب في أن معظم الناس هنا ينصحون بها!

تعديل

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

نصائح أخرى

ForeignKey يتم تنفيذها على النحو IntegerField في قاعدة البيانات ، لذلك يمكنك توفير القليل من لا شيء على حساب تشل النموذج الخاص بك.

يحرر:ومن أجل بيت ، احتفظ بها في جدول واحد واستخدم الفهارس حسب الاقتضاء.

هل تواجه مشاكل في الأداء؟ إذا كان الأمر كذلك ، فقد تحتاج إلى ذلك أضف بضع فهارس.

طريقة واحدة للحصول على فكرة عن المكان الذي سيساعد فيه الفهرس هي النظر إلى سجل استعلام خادم DB الخاص بك (التعليمات هنا إذا كنت على MySQL).

إذا كنت لا تواجه مشاكل في الأداء ، فما عليك سوى الذهاب معه. تصنع قواعد البيانات للتعامل مع ملايين السجلات ، وجيانغو جيد جدًا في توليد استعلامات معقولة.

نهج شائع لهذا النوع من المشكلات هو Sharding. لسوء الحظ ، فإن الأمر متروك في الغالب إلى ORM لتنفيذه (سباتي لا يتمتع به بشكل رائع) ولا يدعم Django هذا. ومع ذلك ، لست متأكدًا من أن 4 ملايين صف من الصفوف أمر سيء حقًا. يجب أن تظل استفساراتك قابلة للإدارة بالكامل.

ربما يجب أن تنظر إلى التخزين المؤقت بشيء مثل memcached. Django يدعم هذا جيد جدا.

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

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

على سبيل المثال ، مع MySQL ، ربما ستحتاج إلى ضبط إعدادات InnoDB ؛ بالنسبة إلى postgresql ، ستحتاج إلى تغيير مشاركين _buffers وعدد من الإعدادات الأخرى.

لست على دراية بـ Django ، لكن لدي فهم عام لـ DB.

عندما يكون لديك قواعد بيانات كبيرة ، من الطبيعي جدًا أن تفعل ذلك فهرس قاعدة البيانات الخاصة بك. بهذه الطريقة ، يجب أن يكون استرداد البيانات سريعًا.

عندما يتعلق الأمر بربط كتاب بقارئ ، يجب عليك إنشاء جدول آخر ، يربط القارئ بالكتب.

إنها ليست فكرة سيئة لتقسيم الكتب إلى مواضيع. لكنني لست متأكدًا مما تعنيه من خلال وجود 20 تطبيقًا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top