Search API vs. Apache Solr Search

Korzystam z modułu wyszukiwania Apache Solr w Drupal 6 i szukam API wyszukiwania dla instalacji Drupal 7. Widziałem tutaj trochę dyskusji , ale szukam jakichkolwiek powodów, by wybrać jedną z nich.

Czy istnieje powód, aby wybierać między sobą? Jeśli tak, dlaczego lub dlaczego nie? Słyszałem, że mogą istnieć problemy ze złożonością i / lub problemy z wydajnością w Search API. Czy to prawda?

Od 2015 roku możemy porównać moduły Search API vs moduły Apache Solr Search z liczbami:

                   | 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

co wskazuje na wyraźny wybór. Search API został opracowany 3 lata później i udało mu się wykorzystać swojego konkurenta.

Co więcej, Search API zapewnia zupełnie inną i bardziej elastyczną architekturę i jest aktywniej utrzymywany. Co ważniejsze, ma już obsługę najnowszych Drupal 8 i Solr 5.x, których Apachesolr jeszcze nie ma.

Interfejs API wyszukiwania zaczął się od nowa i jest bardziej elastyczny w konfiguracji, w tym obsłudze widoków (do Apachesolr potrzebujesz dodatkowego modułu). Istnieje również wiele modułów rozszerzających jego funkcjonalność.

Po drugie, aby uniknąć problemów rozwiązywanych przez społeczność dwa razy z powodu różnic w architekturze tych modułów, obecnie istnieją pewne połączone wysiłki między tymi dwoma projektami, takie jak:

• stworzenie wspólnego sposobu wyświetlania bloków aspektów za pomocą Facet API (znanego również jako filtry),
• wspólne pliki konfiguracyjne schematu i solrconfig.xml,
• obaj opiekunowie współpracowali i przeprowadzili migrację klas połączeń z modułu wyszukiwania Apache Solr do interfejsu API wyszukiwania.

^{Źródło: Battleplan for Search & Solr w Drupal 8 w Acquia}

Uwaga: nie zaleca się używania obu modułów w tym samym środowisku.

Aby uzyskać dalszą analizę techniczną różnic, sprawdź szczegóły poniżej.

Wyszukaj API

Przegląd interfejsu API:

• Ramy do łatwego tworzenia wyszukiwań
• Streszczenia ze źródeł danych i implementacji backendu
• Duży ekosystem z rozszerzeniami, np. Backendami
• Integracja interfejsu API Facet

• Mocno oparty na API Entity

  • Dostarcza metadane
  • Używany do konfiguracji indeksu i serwera

Funkcje rozszerzenia:

• Wyszukiwanie autouzupełniania interfejsu API
• Załączniki
• Zapisane wyszukiwania
• Lokalizacja
• Ścieżki Pretty Facets
• Suwak (zakresy API wyszukiwania)
• i wiele więcej.

Podstawowa struktura:

Funkcje indeksu:

• Różne źródła danych
• Jedno źródło danych: podmioty

• Na podstawie interfejsu API jednostki:

  • Każda właściwość może być indeksowana
  • Właściwości powiązanych jednostek można indeksować

Jak skonfigurować indeks - pola:

Widoki interfejsu API wyszukiwania:

• Pełna obsługa widoków
• Wyświetl dowolną właściwość jednostki
• Użyj dowolnego pola indeksowanego jako filtru, argumentu lub sortowania
• Większość kodu opiera się na integracji widoków interfejsu API Entity

• Domyślnie: dane pobierane poprzez ładowanie encji

  • Można go ominąć (ustawienie „Pobierz dane z Solr” na serwerze)
• Alternatywnie: Wyszukaj strony interfejsu API

Przepisy API wyszukiwania:

• Haki CRUD do indeksów i serwerów

• Haczyki do dodawania

  • źródła danych
  • backendy
  • zmiany danych
  • procesory

• Hak wystrzelony podczas indeksowania przedmiotów

• Hak wystrzelony podczas wyszukiwania

Apachesolr

Funkcje rozszerzenia:

• Załączniki (brak obsługi mediów, niestandardowe kodowanie załączników do innych podmiotów)
• Lokalizacja (lokalizacja geograficzna Apachesolr, lokalizacja Apachesolr)

Przepisy Apachesolr:

• Platforma wyszukiwania korporacyjnego Open Source
• Fundacja Apache
• Wyszukiwanie pełnotekstowe, wyróżnianie, wyszukiwanie aspektowe, grupowanie, bogata obsługa dokumentów
• Rozpowszechniane
• Replikacja / skalowalność
• Jawa
• REST HTTP i odpowiedzi w XML / JSON i niektórych innych
• Nie relacyjny

Źródło: Search API vs pokaz slajdów Apachesolr

Zobacz też:

• Kiedy warto skorzystać z podstawowego modułu wyszukiwania Drupal?
• Jakie są zalety używania Apache Solr w porównaniu z podstawowym modułem wyszukiwania?

Próbowałem użyć obu i mogę to powiedzieć: to zależy od twojej sytuacji.

Obecnie stabilna wersja 7 modułu integracji ApacheSolr może indeksować tylko węzły. Jeśli więc masz jednostki inne niż węzeł, które musisz zindeksować, musisz użyć do tego wciąż trwającej poprawki multientity . Integracja ApacheSolr może przechowywać wiele różnych danych treści, jeśli jest odpowiednio skonfigurowana.

Interfejs API wyszukiwania indeksuje wpisy i ma na to wiele wspaniałych rzeczy. Jednak interfejs API wyszukiwania pobiera tylko identyfikator szukanych danych. Oznacza to, że załadowanie jakichkolwiek danych innych niż identyfikator będzie wymagało load_load, uderzenie w bazę danych lub dowolną warstwę buforowania, którą umieściłeś. W przypadku witryn wymagających dużej liczby wyszukiwań może to nie być najbardziej zoptymalizowane rozwiązanie.

Oto świetna prezentacja na drupalcon chicago na temat modułu integracji ApacheSolr, minuta 16 na wzmianki o API wyszukiwania.

Myślę, że naprawdę musisz spróbować obu i podjąć świadomą decyzję. Należy jednak pamiętać, że apachesolr wciąż nie ma wersji beta dla Drupal 8.

W Search API nie można łączyć encji z tym samym indeksem SearchAPI. Profile, użytkownicy i węzły znajdują się w różnych indeksach. Istnieje moduł pozwalający na wyszukiwanie wielu indeksów, nie zaspokajał moich potrzeb, ale YMMV. Jeśli masz wiele typów treści i wiele pól w tym samym indeksie, definicja indeksu może stać się dość dziwnie. (NB Raporty SearchAPI D8 do obsługi wyszukiwania wielu indeksów)

Apachesolr pozwala na edycję pól na podstawie zawartości, co może być łatwiejsze, ale nie ma możliwości dodawania pokrewnych treści do dokumentu, w rzeczywistości oczekuje napisania niestandardowego kodu zawierającego informacje z kolekcji pól, referencji i innych pola. Apachesolr D7 nie obsługuje ajax, chyba że używasz widoków, ale używając widoków tracisz aspekty. To powiedziawszy ... modyfikowanie informacji przechowywanych w indeksie jest dość łatwe, jeśli z przyjemnością kodujesz haczyki.

Pomysł wyszukiwania identyfikatorów encji, a następnie renderowania każdego z nich osobno (może być używany przez oba moduły) wydaje się koszmarem wydajności, ale jeśli buforujesz swoją encję, może być bardziej wydajna niż renderowanie z odpowiedzi solr.