كنت أستخدم Apache Solr Search الوحدة النمطية في Drupal 6 وأنا أنظر إلى Search API for Drupal 7. لقد رأيت بعض المناقشة هنا لكني أبحث عن أي أسباب لاختيار واحد أو آخر.
هل هناك سبب لاختيار واحد على الآخر؟ إذا كان الأمر كذلك، لماذا أو لماذا لا؟ لقد سمعت أنه قد تكون هناك مشكلات معقدة و/أو مشكلات في الأداء في Search API. هل هذا صحيح؟
اعتبارًا من عام 2015 ، يمكننا مقارنة وحدات واجهة برمجة تطبيقات البحث مقابل وحدات Apache Solr Search بالأرقام:
| Apache Solr Search | Search API
Posted in: | 2007 | 2010
Downloads: | >2k | >20k
Reported installs: | >21k | >64k
Total bugs: | >1200 | >600
Active bugs: | >200 | >170
Commits: | >1.3k | >1.5k
مما يشير إلى الاختيار الواضح. تم تطوير Search API بعد 3 سنوات وتمكن من الاستفادة من منافسه.
علاوة على ذلك ، يوفر Search API بنية مختلفة تمامًا وأكثر مرونة ويتم الحفاظ عليه بشكل أكثر نشاطًا. الأهم من ذلك ، أنها تدعم بالفعل أحدث Drupal 8 و Solr 5.x التي لا تمتلكها Apachesolr حتى الآن.
بدأ Search API حديثًا وهو أكثر مرونة في تكوينه بما في ذلك دعم طرق العرض (بالنسبة لـ Apachesolr تحتاج إلى وحدة إضافية). هناك أيضًا الكثير من الوحدات التي توسع وظائفها.
ثانيًا ، لتجنب حل بعض المشكلات من قبل المجتمع مرتين بسبب الاختلافات في بنية هذه الوحدات ، يوجد حاليًا بعض الجهود المشتركة بين هذين المشروعين مثل:
المصدر: Battleplan for Search & Solr in Drupal 8 at Acquia
ملاحظة ، لا يُنصح باستخدام كلتا الوحدتين في نفس البيئة.
لمزيد من التحليل الفني للاختلافات ، يرجى التحقق من التفاصيل أدناه.
نظرة عامة على API:
يعتمد بشكل كبير على Entity API
ميزات التمديد:
تركيب اساسي:
ميزات الفهرس:
بناءً على Entity API:
كيفية تكوين الفهرس الخاص بك - الحقول:
طرق عرض واجهة برمجة تطبيقات البحث:
افتراضيًا: يتم استرداد البيانات عبر تحميل الكيان
وصفات API البحث:
خطاف لإضافة
أطلقت هوك عند فهرسة العناصر
ميزات التمديد:
وصفات أباتشيسولر:
المصدر: Search API vs Apachesolr slideshow
أنظر أيضا:
لقد حاولت استخدام كليهما ويمكنني أن أقول هذا: هذا يعتمد على وضعك.
في الوقت الحالي ، لا يمكن للإصدار 7 الثابت من وحدة ApacheSolr Integration سوى فهرسة العقد. لذلك إذا كان لديك كيانات غير عقدة تحتاج إلى فهرستها ، فيجب عليك استخدام ما زال قيد التقدم multientity patch for it. يمكن لـ ApacheSolr Integration تخزين الكثير من البيانات المختلفة للمحتوى عند تكوينه بشكل صحيح.
إن واجهة برمجة تطبيقات البحث تستقطب الفهرس وتحتوي على الكثير من الأشياء الرائعة التي تمت كتابتها له. ومع ذلك ، فإن Search API يجلب فقط معرف البيانات التي تبحث عنها. هذا يعني تحميل أي بيانات أخرى بخلاف المعرّف سيتطلب تحميل_كيان ، أو ضرب قاعدة بياناتك أو أي طبقة تخزين مؤقت تضعها في مكانها. بالنسبة إلى المواقع كثيفة البحث ، قد لا يكون هذا هو الحل الأمثل.
هنا هو عرض تقديمي رائع في drupalcon chicago حول وحدة ApacheSolr Integration ، الدقيقة 16 للإشارة إلى Search API.
أعتقد أنه يجب عليك بالفعل تجربة كليهما واتخاذ قرار مستنير. لكن ضع في اعتبارك بشدة أن apachesolr لا يزال لا يحتوي على بيتا لـ Drupal 8.
في Search API ، لا يمكنك دمج الكيانات في نفس فهرس SearchAPI. حتى الملفات الشخصية والمستخدمون والعقد على فهارس مختلفة. هناك وحدة تسمح بالبحث المتعدد ، لكنها لم تغط احتياجاتي ، ولكن YMMV. إذا كان لديك العديد من أنواع المحتوى والعديد من الحقول في نفس الفهرس ، فقد يصبح تعريف الفهرس غير عملي تمامًا. (تقارير NB SearchAPI D8 لدعم البحث في الفهارس المتعددة)
يسمح Apachesolr بتحرير الحقول على أساس كل محتوى قد يكون أسهل ، ولكن ليس لديه القدرة على إضافة محتوى ذي صلة إلى مستند ، في الواقع تتوقع أن تضطر إلى كتابة بعض التعليمات البرمجية المخصصة لتضمين معلومات من مجموعات الحقول والمراجع وبعضها الآخر مجالات. Apachesolr D7 لا يدعم ajax ، إلا إذا كنت تستخدم طرق العرض ، ولكن باستخدام طرق العرض تفقد الجوانب. ومع ذلك ... يعد تعديل المعلومات المخزنة في الفهرس أمرًا سهلاً إلى حد ما إذا كنت سعيدًا بالتشفير في الخطافات.
قد تبدو فكرة البحث عن معرّفات الكيانات ثم عرض كل منها على حدة (يمكن استخدامها من قبل كلتا الوحدتين) كابوسًا للأداء ، ولكن إذا عرضت ذاكرة التخزين المؤقت للكيان الخاص بك ، فقد يكون أكثر كفاءة من العرض من استجابة solr.