it-swarm.asia

ما هو التوازن الجيد بين إعادة استخدام الحقول مقابل إنشاء حقول جديدة في سياق قابلية التوسع؟

لقد قرأت العبارة التالية على موقع ويب:

بدلاً من إضافة حقول جديدة إلى نوع المحتوى ، تعد إضافة الحقول الموجودة خيارًا أفضل لتقليل تعقيد النظام وتحسين قابلية التوسع.

وتنشأ بعض الشكوك.

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

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

34
rafamd

عادةً ما لا يمثل مقدار البيانات في الحقل مشكلة. إذا كنت قلقًا بشأن ذلك ، فابحث عن مكونات تخزين ميدانية بديلة أو اكتب ما تريده. على سبيل المثال MongoDB ، والتي يمكنها التعامل مع أي شيء تضعه فيه. يتم استخدامه على سبيل المثال على http://examiner.com .

مشكلة حقيقية ومع ذلك هي عدد الحقول لديك. لأنه حاليًا في Drupal 7 ، فإن التكوين الميداني الكامل لـ جميع الحقول ، بغض النظر عما إذا كانت محملة أم لا ، يتم جلبها من ذاكرة التخزين المؤقت في كل طلب.

لقد رأيت مواقع تحتوي على أكثر من 250 حقلاً ، حيث يستغرق تحميل تهيئة الحقل وإلغاء تسلسلها 13 ميغابايت + ذاكرة.

تحرير: تم تحسين ذاكرة التخزين المؤقت لمعلومات الحقل (انظر http://drupal.org/node/104079 للحصول على التفاصيل) مع Drupal 7.22 ، فقط حقول الحزم التي يتم عرضها على صفحة معينة يتم تحميلها من ذاكرة التخزين المؤقت وهي إدخالات ذاكرة تخزين مؤقت منفصلة. يعمل هذا فقط إذا لم تكن هناك مكالمات API خاطئة تطلب مثيلات عبر حزم متعددة.

24
Berdir

أتفق تمامًا مع البردير. فيما يلي تجربتي مع مشروع يحتوي على ملايين الصفوف و 30-40 حقلاً في بعض أنواع العقد.

  1. لا يمثل عدد الصفوف في جدول الحقول مشكلة كبيرة لأداء القراءة ، حيث يتم جلب جميع الحقول بواسطة المفتاح الأساسي.
  2. يمكن أن يتزايد عدد الحقول لكل نوع عقدة بسرعة إلى مشاكل كبيرة في الأداء عند كتابة عقد جديدة. ينتج عن وجود أكثر من 30 حقلاً لنوع عقدة واحدة 60+ عبارات INSERT عند إنشاء عقدة جديدة. هذا يستغرق ثواني لإكمال. إذا كنت من المستخدمين الذين ينشئون الكثير من البيانات ، فإن ذلك سيؤثر على أدائك. ستستغرق عمليات الإدراج المجمعة لـ 1000 عُقدة ساعة تقريبًا. إذا كان عليك تحديث 100 ألف عقد ، فهذه مشكلة كبيرة.
  3. إذا كنت تعتقد أن عدد حقول الحقول سوف يضربك ، فيجب أن تفكر بجدية في كتابة تخزينك الميداني أو لا تستخدم الحقول. (لا يزال بإمكانك جعل العقدة الخاصة بك تعمل مع طرق العرض بجهد إضافي.)
  4. كلمة عن MongoDB. إنه مشروع مثير للاهتمام للغاية وآمل أن يكون في صدارة قواعد البيانات الكبيرة. لسوء الحظ مقارنة بنضج MySql أو PgSql إنه طفل. كن مستعدًا للتعامل مع منتج صغير جدًا.
13
BetaRide

إذا كنت قلقًا بالفعل بشأن ما سيحدث ، فعندئذ أعتقد أن المحاكاة مطلوبة.

احصل على حساب في Rackspace Cloud أو Amazon أو Linode أو في أي مكان آخر يمكنك بسهولة تشغيل VPS. اصنع حالتين متطابقتين. تثبيت Drupal على كل منها. قم بإنشاء بعض أنواع المحتوى الوهمي ، وقم بإعداد الحقول بطريقة واحدة في نظام ، وطريقة أخرى في النظام الآخر. استخدم وحدة التطوير لإنشاء حمولة قارب من المحتوى. اضبط إعدادات الأداء للتأكد من Drupal يتم التخزين المؤقت حسب الحاجة. قم بتشغيل mysqltuner واضبط MySQL على كل توصية. تحقق مرة أخرى PHP وإعدادات APC حتى تتمكن من لضرب المبادلة وأنك لا تقوم بتمرير ذاكرة التخزين المؤقت APC.

بمجرد حصولك على تكوين أساسي جيد لكل منها ، ابدأ في محاكاة حركة المرور (كل من الزوار العاديين وتحديثات المشرف) باستخدام wget and drush ، ثم الملف الشخصي.

المحاكاة ليست مثالية أبدًا ، لكنها يمكن أن تجعلك تسير في الاتجاه الصحيح.

5
mpdonadio

نصيحة أخرى: إن وجود الكثير من الحقول سيسبب مشاكل مع العديد من الوحدات المختلفة أيضًا. على سبيل المثال ، فإن واجهة المستخدم الرسومية Token GUI تجعل متصفحك يتأخر لمدة دقائق إذا حاولت تحرير الأسماء المستعارة لعناوين URL على سبيل المثال. يمكن رؤية هذا السلوك في جميع الصفحات التي سيتم فيها تحميل الرمز المميز وعرضه (بما في ذلك devel - dpm () إلخ.)

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

قد يسهل أيضًا إنشاء القالب بسبب سمات العقدة المتشابهة.

2
Andre Baumeier

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

2
jozwikjp

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

ومع ذلك ، فقد نجحت. إذا كنت تستخدم التخزين المؤقت والورنيش ، فإن وقت انتظار المستخدم لم يكن بهذا السوء.

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

لحسن الحظ ، قررنا إعادة معالجة منتجاتنا قليلاً حتى نأمل أن نحصل على الحد الأقصى لعدد الحقول لدينا في نطاق 200-250 لمنتجاتنا الأكثر تعقيدًا (نحن في الأجهزة العلمية ، لذلك هناك حاجة إلى قياسات ومواصفات معقدة) .

1
Waterskier19

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

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

0
joevallender

لقد كنت دائمًا أعيد استخدام الحقول ، لكنني الآن أفكر في استخدام حقول فريدة لكل نوع عقدة لمشروع جديد. أريد بالفعل أن أبقي كل شيء مفصولًا بشكل جيد (الحقول ، المشاهدات ، القواعد ، السياقات ، إلخ) لكل حزمة كيان. لذا فقد أثار مسألة قابلية التوسع التي قادتني هنا. أنا مرتاح من تعديل Berdir (تم تحسين ذاكرة التخزين المؤقت لمعلومات الحقل (انظر http://drupal.org/node/104079 للحصول على التفاصيل) مع Drupal 7.22 ، يتم تحميل حقول الحزم المعروضة على صفحة معينة فقط من ذاكرة التخزين المؤقت وهي إدخالات ذاكرة تخزين مؤقت منفصلة. وينجح ذلك فقط في حالة عدم وجود مكالمات API خاطئة تطلب مثيلات عبر حزم متعددة).

أريد فقط أن أشير إلى أن هناك وحدة مثيرة للاهتمام للغاية كنت أستخدمها منذ شهور على مواقع متعددة ومعقدة: https://www.drupal.org/project/render_cache . إنها واحدة من تلك الأحجار الكريمة المخفية في رأيي.

كما هو موضح في صفحة المشروع ، يتم استخدام جزء التعليقات في الواقع على D.O. نفسه.

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

0
Oscar