it-swarm.asia

استيراد مصادر بيانات كبيرة مسطحة مع Drupal 7 مع طرق عرض 3

هدفي هو إنتاج طريقة سريعة وموثوقة ومؤتمتة للوصول إلى للقراءة فقط البيانات الواردة في العديد من مصادر البيانات الكبيرة جدًا ( CSV s ، العرض الثابت ومستندات XML) باستخدام Drupal 7 الذي يمكن الاستعلام عنه باستخدام الوحدة المشاهدات . أفضل استخدام بالفعل الوحدات المتاحة ، ولكن بناء وحدة مخصصة هو أيضًا خيار.

للمساعدة في استبعاد الوحدات والأساليب غير المناسبة للمهمة ، إليك الإحصائيات الموجودة على الملفات التي أعمل معها:

  • الاستيراد السنوي: 8،500،000 سطر CSV ملف. (يتم التطهير وإعادة التحميل سنويًا. لديه مفتاح أساسي.)
  • الاستيراد الأسبوعي: 350.000 خط عرض ثابت. (تطهير وإعادة تحميل أسبوعيًا. لا يوجد مفتاح أساسي .)
  • استيراد كل ساعة: 3،400 سطر CSV ملف. (ترغب في التحديث والمزامنة قدر الإمكان ، ولكن ليس أكثر من كل 20 دقيقة. لديه مفتاح أساسي)
  • الاستيراد اليومي: 200 ملف XML العنصر. (يتم التنظيف وإعادة التحميل يوميًا. به مفتاح أساسي)

التحويل بين التنسيقات الثلاثة ليس مشكلة ويمكن إجراؤه إذا كان سيحسن أداء الاستيراد أو سيسمح بتوفير أدوات أفضل. ( AWK لـ عرض ثابت إلى CSV ، إلخ.) الاسترداد وأتمتة التحويل سهلة عبر cron و sh نصوص برمجية ، ولكن لا تزال بحاجة إلى أتمتة Drupal 7. يمكن أيضًا استخدام الجداول المخصصة طالما أن vews يمكن أن تشير إلى البيانات باستخدام العلاقات.

ما أفضل ممارسة لتحقيق هذا النوع من تكامل البيانات مع Drupal 7؟ أيضًا ، هل أترك أي تفاصيل مهمة تتعلق بالبيانات أو ما أحاول تحقيقه؟


فيما يلي بعض المشاريع التي أبحث عنها حاليًا لإيجاد حل. أود أن أتوسع في هذا لمساعدة الآخرين على تحديد المسار الذي يجب عليهم اتخاذه عند العمل مع عمليات استيراد البيانات الأكبر.

استيراد البيانات إلى العقد:

الخلاصات ستقوم باستيراد البيانات بشكل موثوق. تعتبر السرعة معقولة لمصادر البيانات الأصغر ولكنها بطيئة جدًا بالنسبة لجداول 300k +.

الأتمتة المتاحة باستخدام cron and Job Scheduler (Alpha Alpha لـ D7 حاليًا).

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

الأتمتة متاحة عبر drush و cron.

الجداول المخصصة بدلاً من العقد

وحدة البيانات تبدو واعدة للغاية ، ولكنها عربات التي تجرها الدواب للغاية لـ D7 في الوقت الحالي. يمكن تلبية متطلبات الأتمتة وسرعة الاستيراد بسهولة باستخدام البيانات ، ولكن الموثوقية غير موجودة. تكامل طرق العرض (الرابط لـ D6) يبدو واعدًا جدًا.

تمت إضافة هذا كمرجع. لا يوجد مرشح D7 في هذه المرحلة ، ولكن يمكن أن يعمل كنقطة بداية لوحدة مخصصة.

تمت إضافة هذا كمرجع. يبدو أنه قد تم استيعابه في الجدول Wizard in Drupal 6. مرة أخرى ، تمت إضافته كمرجع فقط.

يبدو أنه يتطلب معالج الجدول (D6 فقط) لـ طرق العرض التكامل. تمت إضافتها كمرجع ، ولكنها لا تستوفي متطلبات المشاهدات.


MPD - تمت إضافة "الجداول المخصصة" كحل ممكن ، ووحدات موسعة. شكرا لك على هذه الإضافة.

13
Citricguy

تخبرني حدسي أن هذه الخطة ستجعل خوادمك تشتعل فيها النيران ...

على محمل الجد ، إذا كنت تعمل على زيادة هذه البيانات ، فأعتقد أنك بحاجة إلى الاحتفاظ بالبيانات في مصدر بيانات خارجي ثم دمجها مع Drupal.

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

لقد قمت بدمج الكثير من مصادر البيانات الخارجية في دروبال ، وهو ليس بالأمر الصعب. أعطيت نظرة عامة في خطة الانتقال ل PHP5 رجس إلى دروبال . كان ذلك من أجل Drupal 6 ، ولكن الشيء نفسه ينطبق بشكل أساسي على Drupal 7. بشكل أساسي ، يمكنك محاكاة ما تفعله CCK/Fields API مع الواجهة الخاصة بك.

على الرغم من عدم وجود UUID لقاعدة البيانات الأسبوعية ، فإنه يلقي بالفعل على مفتاح العمل. يتطلب هذا الجزء الكثير على الرغم من ذلك ، يمكن توفيره في منتدى Q/A مثل هذا.

إذا كنت ترغب حقًا في السير في طريق الاستيراد ، فسوف أفعل الكفالة على Feeds و Migrate وكتابة نص الاستيراد الخاص بك. بشكل أساسي ، تقوم بإجراء عملية بيع الكتب الأولية من index.php واستعلام مصدر البيانات الخاص بك وإنشاء العقد ثم حفظها. برمجيا جعل العقد سهلا.

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

تحرير أدناه لمعالجة توضيح/توسيع:

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

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

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

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

8
mpdonadio

أعتقد أن النهج القائم على العقدة (أو حتى القائم على الكيان) سيحرق خادمك بملايين العقدة. إلى جانب ذلك ، بالنظر إلى استيراد الساعة ، فهذا يعني أنك ستقوم بإنشاء node_save () مرة واحدة على الأقل في الثانية. هذا كثير على Drupal ويسبب مشكلة في الأداء.

السبب وراء ذلك هو أنه لن تحتاج إلى أي آلية ربط ، لن تحتاج إلى pathauto (ولكن يمكنك إنشاء اسم مستعار يدويًا ، إنه أرخص بكثير من pathauto) ، لن تحتاج إلى حقول ... اكتب استعلام "INSERT" البسيط أسرع 100 مرة من node_save () أو الكيان (ave) ().

1/IMHO الخيار الأفضل هو جدول مخصص ووحدة مخصصة لاستيراد البيانات الخاصة بك ، ثم كتابة معالجات طرق العرض للتكامل Drupal.

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

2
jcisio