solrfal dla TYPO3: Indeksowanie plików z Apache Solr

Dlaczego standardowe wyszukiwanie TYPO3 zawodzi przy dużych zbiorach dokumentów

Gdy instalacja TYPO3 zarządza więcej niż kilkuset plikami PDF, wbudowane wyszukiwanie napotyka dwie granice: znajduje treści tylko w polach bazodanowych, nie w plikach, a jego logika rankingu ignoruje sygnały trafności, których potrzebują redaktorzy. solrfal wypełnia dokładnie tę lukę, łącząc File Abstraction Layer (FAL) z TYPO3 bezpośrednio z Apache Solr i udostępniając do wyszukiwania każdy plik wraz z jego metadanymi. Rozszerzenie kierowane jest do organizacji, które traktują dokumenty jako rdzeń swojej pracy wiedzy: urzędów z formularzami, wydawnictw z literaturą fachową, uczelni z materiałami dydaktycznymi.

Typowe scenariusze zastosowania

W politechnice z około 40 000 studentów regulamin studiów leży w 180 plikach PDF, rozproszonych po dwunastu wydziałach. Bez solrfal student znajduje przepis dotyczący zgłoszenia na egzamin tylko wtedy, gdy redaktor dodatkowo zapisał ten tekst jako opis meta. Z solrfal Apache Tika indeksuje każdą stronę, a zapytanie wyszukiwania zwraca właściwy akapit wraz z cytatem.

Drugi scenariusz znają urzędy centralne, które dostarczają teksty ustaw, dyrektyw i formularzy przez TYPO3-CMS. Dokumenty często się zmieniają, a uprawnienia dostępu są powiązane z jednostkami organizacyjnymi. solrfal automatycznie synchronizuje przynależność fe_groups plików z indeksem Solr, dzięki czemu pracownik z wydziału V widzi tylko te trafienia, do których ma uprawnienia odczytu.

Trzeci przypadek występuje w wydawnictwach fachowych: wydawnictwo z 12 000 artykułów czasopism w formacie PDF chce udostępnić archiwum do przeszukiwania fasetowego według rocznika, autora i rubryki. solrfal wyodrębnia metadane, wypełnia pola Solr i dostarcza bazę danych dla faset, której klasyczne rozszerzenia TYPO3 takie jak ke_search w tej skali nie są już w stanie obsłużyć.

Architektura techniczna oparta na Apache Tika i EXT:solr

solrfal jest rozszerzeniem kluczowego rozszerzenia EXT:solr od dkd Internet Service i wymaga obowiązkowo działającego serwera Apache Solr, zazwyczaj w wersji 8 lub 9. Samą ekstrakcję tekstu przejmuje Apache Tika, albo jako wbudowana usługa w kontenerze Solr, albo jako samodzielny serwer Tika. solrfal wpina się przez TYPO3-Event-API w cykl życia FAL: każdy wgrany, przeniesiony lub usunięty plik uruchamia zadanie indeksowania, które jest asynchronicznie przetwarzane w TYPO3-Scheduler.

Konfiguracja solrfal odbywa się przez TypoScript i konfigurację rozszerzenia. Schemat Solr można dostosować przez Managed Schema API, dzięki czemu dodatkowe pola jak typ dokumentu, wydział czy język można dodać bez restartu Solr. Tuning trafności odbywa się przez Boosting-Queries i Function Queries, które są definiowane w konfiguracji zapytań EXT:solr. solrfal dziedziczy przy tym wszystkie funkcje językowe EXT:solr, w tym wielojęzyczne analyzery dla niemieckiego, angielskiego, francuskiego i innych standardowych języków.

Częste problemy i rozwiązania

Pierwszy problem pojawia się zwykle przy pierwszym indeksowaniu: Apache Tika zawiesza się przy uszkodzonych lub zaszyfrowanych plikach PDF z błędem OutOfMemoryError i zrywa cały indekser. Rozszerzenie oznacza wtedy plik jako błędny, ale przy kolejnym przebiegu nie pomija go automatycznie. Analizujemy logi Tika, oddzielamy zaszyfrowane od rzeczywiście uszkodzonych plików i ustawiamy pre-check, który sortuje problematyczne pliki, zanim dotrą do indeksera.

Drugi powracający temat to trafność. Zespoły zgłaszają, że wyszukiwanie wprawdzie znajduje wszystkie dokumenty, ale nierelewantne trafienia są na samej górze. Powód leży niemal zawsze w domyślnej wadze pól: solrfal indeksuje całą zawartość pliku w jedno pole, bez rozróżnienia między tytułem, nagłówkami a tekstem głównym. Porządne rozwiązanie wymaga dostosowanego schematu z oddzielnymi polami dla tytułu, metadanych i body oraz regułami boostingu, które wyżej oceniają trafienia w tytułach.

Trzeci problem dotyczy wydajności przy dużych zbiorach. Powyżej około 50 000 zindeksowanych plików scheduler staje się wąskim gardłem, ponieważ solrfal przetwarza każde zadanie pojedynczo. Rozwiązaniem jest indeksowanie wsadowe w połączeniu z dedykowanym procesem workera, który działa równolegle do normalnych zadań schedulera i priorytetowo obsługuje zadania solrfal. Dodatkowo opłaca się indeksowanie różnicowe, które przy każdym przebiegu przetwarza tylko nowe lub zmienione pliki, co znacząco zmniejsza nakład pracy przy stabilnych zbiorach dokumentów.

Czwarty, rzadszy temat pojawia się przy instalacjach wielojęzycznych: solrfal indeksuje pliki niezależnie od języka do wspólnego indeksu, dzięki czemu francuskie opracowanie pojawia się w niemieckiej liście trafień, jeśli słowo kluczowe jest międzynarodowo rozpowszechnione. Czyste rozdzielenie językowe wymaga kilku Solr-Cores lub dodatkowej fasety językowej, którą można sterować przez konfigurację EXT:solr oddzielnie dla każdego site-root.

Migracja i kompatybilność wersji

solrfal podąża za cyklem wydawniczym EXT:solr, który obecnie wspiera TYPO3 v12 i v13. Skok z TYPO3 v9 na v12 to najczęstsza ścieżka migracji i niemal zawsze oznacza też skok z Solr 6 na Solr 9. Przy tym zmienia się format schematu, Managed-Schema-API i niektóre klasy analyzerów, co wymaga pełnego reindeksu. Istniejące reguły boostingu muszą być zwalidowane pod kątem nowego zachowania parsera zapytań, ponieważ Solr 9 inaczej ocenia niektóre domyślne operatory niż Solr 6.

Kto migruje z ke_search lub z wyszukiwania wyłącznie opartego na bazie danych, musi uwzględnić, że solrfal wymaga własnego serwera Solr i tym samym rozszerza wymagania hostingowe. Gosign od lat towarzyszy takim migracjom i w razie potrzeby przejmuje też przejście na konfigurację Solr opartą na kontenerach, która wpasowuje się w istniejące pipeline’y deploymentu.

Warto też zauważyć, że obciążenie utrzymaniem solrfal nie jest do niedocenienia: sam Solr otrzymuje regularne aktualizacje bezpieczeństwa, a schemat musi być sprawdzany przy każdym większym upgrade pod kątem nowych klas analyzerów. Projekt, który raz zdecyduje się na solrfal, przejmuje tym samym odpowiedzialność za własny stos wyszukiwania i powinien to uwzględnić przy początkowym sizingu oraz planowaniu zasobów operacyjnych.