Czy muszę uważać na limit związany z maxBooleanClauses korzystając z filtrów ?

Jedną ze zmiennych konfiguracyjnych, jakie znajdują się w pliku solrconfig.xml jest maxBooleanClauses, która określa maksymalną ilość zapytań boolowskich jaka może być zwarta w ramach pojedynczego zapytania do Solr. Czy muszę uważać na limit związany z tą zmienną korzystając z filtrów w Solr ? Spróbujmy odpowiedź na to pytanie nie wgłębiając się w kod Lucene i Solr.

Zapytanie

Załóżmy, że standardowo zadawaliśmy następujące zapytanie do Solr:

q=category:1 AND category:2 AND category:3 ... AND category:2000

Zadanie takiego zapytania z domyślną konfiguracją Solr będzie skutkowało wyjątkiem i komunikatem „too many boolean clauses„. Oczywiście, moglibyśmy zmodyfikować opcję maxBooleanClauses i pozbyć się wyjątku, jednak spróbujmy zrobić to w inny sposób:

Zmieńmy zapytanie na filtry

Zmieńmy zatem powyższe zapytanie tak, aby wykorzystywało filtry, czyli parametr fq:

q=*:*&fq=category:(1 2 3 ... 2000)

Wysyłamy powyższe zapytanie i … i znów to samo – wyjątek i komunikat „too many boolean clauses„. Dzieje się tak dlatego, iż Solr musi „wyliczyć” zawartość filtra, a co za tym idzie skonstruować odpowiednie zapytanie. Dokonajmy zatem jeszcze jednej modyfikacji:

Kolejna modyfikacja zapytania

Niech nasze zapytanie wygląda w takim wypadku w następujący sposób:

q=*:*&fq=category:1&fq=category:2&fq=category:3&....&fq=category:2000

Po wysłaniu zmodyfikowanego zapytania naszym oczom ukażą się wyniki wyszukiwania (oczywiście, jeżeli w indeksie znajdują się dokumenty odpowiadające warunkom w zapytaniu). Tym razem Solr nie musiał składać jednego dużego zapytania, dlatego też nie przekroczyliśmy limitu związanego z maxBooleanClauses.

Podsumowanie

Jak widać odpowiedź na pytanie zależy od tego, jakie zapytanie chcemy, bądź musimy zadać. W przypadku, kiedy nasze warunki łączy operator logiczny AND możemy pozwolić sobie na zmianę zapytania na wiele parametrów fq ponieważ Solr łączy je automatycznie właśnie tym spójnikiem. Jeżeli natomiast zmuszeni jesteśmy stosować spójnik logiczny OR czekałaby nas zmiana limitu wyznaczonego przez maxBooleanClauses. Należy przy tym pamiętać, iż zwiększanie tego limitu może pociągnąć za sobą spadek wydajności i zwiększone wykorzystanie pamięci.

This entry was posted on poniedziałek, Grudzień 19th, 2011 at 09:28 and is filed under Solr. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

5 komentarzy to “Czy muszę uważać na limit związany z maxBooleanClauses korzystając z filtrów ?”

  1. Rafal Says:

    Witam, bardzo ciekawy blog, na dodatek po polsku
    Aktualnie pracuję nad dodaniem wyszukiwania SOLRem do dosyć dużej aplikacji – działa ona na bazie SQL ale z wielu powodów ten SQL nie jest w stanie zapewnić właściwej wydajności wyszukiwania. Stąd pomysł na outsourcing wyszukiwania do SOLRa.
    Mam w związku z tym pytania
    1. Zapytania do SOLRa mają tendencję do wydłużania się (np gdy łączy się wiele warunków OR-em). Mam nagminne przypadki ORów z ok 30-40 wartościami – czy to nie jest jakoś groźne? Przy jakiej długości zapytania zrobi się groźnie?
    2. Dokumenty w aplikacji są żywe – tzn zmieniają się dość często (dopóki trwa proces ich obsługi), w związku z tym muszę je często re-indeksować żeby wyszukiwanie działało prawidłowo. Jaki to ma wpływ na indeks? Zakładam że na początek będzie ok 50 mln dokumentów, miesięczny przyrost około miliona nowych plus zmiany w ok 1 milionie już istniejących dokumentów (każdy będzie re-indeksowany od 2 do kilkunastu razy w ciągu swojego życia). Czy jakoś specjalnie trzeba dbać żeby reindeksacja nie spowodowała spadku wydajności indeksu albo jego niekontrolowanego rozrostu?

    Pozdrawiam
    RG

  2. gr0 Says:

    Dziękujemy za słowa uznania 🙂

    Co do pierwszego pytania – zapytania z OR’ami, to nie jest co co jest najbardziej optymalne w SOLR, ale czasami nie ma innego wyjścia. Należy pamiętać, że im więcej klauzul boolowskich w pojedynczym zapytaniu, tym więcej pamięci Lucene/Solr będzie potrzebować oraz może ucierpieć na tym wydajność, aczkolwiek nieznacznie.

    Co do drugiego pytania – mówimy tu o dwóch rzeczach. Po pierwsze indeksacja powinna odbywać się na wydzielonej do tego maszynie, czyli na serwerze master. Wtedy jedyne o czym musimy pamiętać, to dobre zapytania rozgrzewające. Co do niekontrolowanego rozrostu – Lucene tworzy segment raz i potem go już nie modyfikuje. Dlatego każda operacja update to tak naprawdę delete, a potem add. Warto w takim wypadku robić co jakiś czas optimize na masterze, przed replikacją indeksów na slave’y.

  3. Rafal Says:

    Słowa uznania się należą, przeglądam Wasze artykuły wstecz i znajduję mnóstwo wskazówek i pomysłów na rozwiązania wykorzystujące SOLRa.

  4. Rafal Says:

    PS a propos pomysłów, niedługo pewnie bedzie wdrożenie produkcyjne mojego ‚solr search’ dla aplikacji a jako wstęp konieczne będzie zaindeksowanie tych 50 mln dokumentów. No i tu pytanie – być może warte całego postu – jak to zrobić żeby nie trzeba było indeksacji powtarzać np za kilka miesięcy?
    Mam tu na myśli
    – rozwój SOLR: jak zrobić żeby indeks był kompatybilny z następnymi wersjami SOLR, może są jakieś pułapki które uwiążą mnie do starej wersji albo utrudnią aktualizację?
    – SOLR 4 (a propos powyższego) – czy trzeba już planować przejście na wersję 4 (a może od razu zacząć z 4)?
    – poprawne indeksowanie pól różnego typu (daty, liczby, tekst w języku polskim)
    – możliwości modyfikowania istniejącego indeksu oraz jakie modyfikacje będą sprawiać trudności a jakie nie

  5. gr0 Says:

    1. Indeks Solr może nie być kompatybilny i należy przygotować aplikację i infrastrukturę tak, aby reindeksacja całości kolekcji była możliwa.
    2. Wersja 4 jest dalej wersją rozwojową i nawet korzystając z niej należy się spodziewać, iż wraz z nadchodzącymi zmianami będzie konieczność reindeksacji.
    3. Poprawne indeksowanie różnego typu pól zależy od danych i przeznaczenia tych pól. Opisanie jednego, złotego środka dla danego typu danych, szczególnie tekstowych, jest średnio możliwe.
    4. Lucene oferuje dwa rodzaje modyfikacji indeksu – dodaj dokument, usuń dokument. Nie więcej, ani nie mniej. Co do trudności, znów odpowiedź – to zależy, od danych, od ruchu, od maszyn i architektury systemu.