lekkie indeksowanie dokumentów do obsługi mniej niż 250 000 potencjalnych rekordów

10

Ostatnio odkryłem, że ogarnia mnie ograniczenia mechanizmów indeksowania dokumentów. Tworzyłem małą stronę internetową, która wymagała dość solidnych możliwości wyszukiwania, ale z powodu ograniczeń sprzętowych nie mogłem wdrożyć rozwiązania Lucene (takiego jak Solr lub ElasticSearch, jak zwykle), aby zaspokoić tę potrzebę.

I nawet wtedy, gdy musiałem obsługiwać złożone dane i obliczenia, które wymagały dużej ilości danych, nie musiałem obsługiwać więcej niż 250 000 potencjalnych rekordów. Wdrażanie całej instancji Solr lub ES tylko do obsługi tego wydawało się marnotrawstwem.

Po tym, jak o tym pomyślałem, wydaje się to dość dużym problemem. Większość osób obsługuje wymagania wyszukiwania wyłącznie za pomocą SQL. Po prostu uruchamiają zapytania SQL dla swoich danych i to wszystko. Ich możliwości wyszukiwania również są okropne.

  • Wykonywanie kompleksowego wyszukiwania pełnotekstowego symboli wieloznacznych może być boleśnie powolne w niektórych systemach (w szczególności hostów współdzielonych) i zapychać bazę danych, szczególnie jeśli masz skomplikowane zapytania i wiele sprzężeń.

  • W rezultacie wykonujesz wiele zapytań na jednym żądaniu od użytkownika. Możesz obejść ten problem przy użyciu coraz bardziej skomplikowanych zapytań, ale zobacz poprzedni punkt.

  • Brak funkcji zwykle występujących w silnikach pełnotekstowych.

Bazy danych miały ten sam problem z koniecznością wdrożenia jako serwer, a następnie pojawił się SQLite i nagle mogliśmy wdrożyć bazę danych, która jest samodzielna w jednym pliku. Mój Googling nic nie dał - zastanawiam się, czy coś takiego istnieje do indeksowania / wyszukiwania pełnotekstowego.

Jakie czynniki należy wziąć pod uwagę przy podejmowaniu decyzji o wdrożeniu lekkiego indeksowania dokumentów (np. Jak wyjaśniono w odpowiedziach na inne pytanie ) lub nadal używać SQL w takich sytuacjach?

Jarrod Pokrzywy
źródło
5
Nie rób tutaj badań rynku. Pytanie jest tutaj nie na temat. Możesz mieć więcej szczęścia, pytając o to podczas startów , chociaż najpierw powinieneś przeczytać ich FAQ.
Oded
9
Whoa - nie chcę tutaj zakładać firmy ani nic. To jest tylko uczciwe pytanie, szukające technologii do zastosowania w sytuacji lub innego rozwiązania, które nie jest obecnie dostępne.
Jarrod Nettles
16
To jest strona o problemach koncepcyjnych w tworzeniu oprogramowania. Nie pytaj o problemy koncepcyjne związane z tworzeniem oprogramowania.
psr
3
Jest tam dobre pytanie ... Myślę, że należy je po prostu wyczyścić, aby było bardziej jasne i szczegółowe.
GrandmasterB
3
Jeśli jedyną skargą dotyczącą SQLite jest brak indeksowania tekstu, dlaczego po prostu nie skorzystać z modułu rozszerzenia FTS4 SQLite ?
Brian

Odpowiedzi:

2

Wiesz, muszę powiedzieć, że rozważ użycie Redis.

  • Użyj idei kontekstu . Trudno byłoby przejść dogłębnie, nie wiedząc więcej o dokumentach. Często można rozpoznać wiele rzeczy z nagłówków dokumentów. Profilowanie każdego dokumentu jest podstawowym pierwszym krokiem, podobnie jak indeksowanie w Internecie.

  • Policz każdy dokument słów w słowniku słów kluczowych. Śledź popularność każdego słowa dla całego projektu. Dodaj większą wagę do iteratora dla tej liczby, jeśli zdołasz wykryć duże znaczenie w dokumencie lub zestawie.

    Pierwszą rzeczą, jaką to robi, jest podanie kompleksowej listy słów w całym zestawie. Cokolwiek NIE znajduje się na tej liście, automatyczny zwrot „brak wyników”. Sugeruję ranking wyników niższy niż dolny 5-20% popularności (podczas wyszukiwania zapytania w indeksie) również po prostu powiedz „brak wyników”.

  • Jeśli nie iść z czymś REDiS, lub nawet po prostu stworzyć własną strukturę pamięci można powiązać dokumentów z plików deskryptora pliku lub mini-DB i obiektów strony, które opisują każdy konkretny dokument plecy iz powrotem do pamięci. Zachowaj typowe wyszukiwania w pamięci, być może zmuszając ich do rywalizacji o automaty do gier lub dając im czas na życie, który rośnie przy każdym wyszukiwaniu.

  • Aby przejść dalej, zacznij zapisywać dane referencyjne, które grupują link / odnośnik / wskaźnik / indeks / cokolwiek z dwóch lub więcej dokumentów i puli słów kluczowych lub fraz. Zasadniczo dostajesz napompowaną chmurę tagów.

  • Co więcej, wykrywaj frazy, śledząc, kiedy po słowie w słowniku pojawia się lub poprzedza dokładny ciąg znaków zwykle w dokumentach o podobnych metadanych / tytule. Jest to intensywne, ale wymaga tylko jednego przejścia do renderowania danych.

  • Im więcej sposobów segregowania danych i utrzymywania grup powiązanych ze sobą w faktycznym użyciu, tym lepiej.

  • Połącz prawdopodobieństwo poprawności, śledząc za każdym razem, gdy użytkownik kliknie wynik, który nie znajduje się w pierwszej trójce. Ulepsz wykrywanie fraz, obserwując wyszukiwania użytkowników, które nie dały doskonałych wyników. Wymuszaj, aby twoje zapytania stawały się względne względem wyszukiwań klientów.

  • Czy musisz uważać na aktualizacje dokumentów? Chronjobs / skrypt powłoki lub zaplanowane zadania / skrypt partii mogą pomóc. Oczywiście istnieją różne opcje planowania i skryptowania.

  • Marnuj dysk, zyskaj szybkość, utrudnij pracę. Zapisz wiele drzew swoich dokumentów i / lub drzewa linków do dokumentów. Przeszukuj tylko drzewa, dla których kryteria zostały spełnione, lub przynajmniej preferuj je, aby uzyskać wynik w większości przypadków szybciej.

  • Stwórz swój własny lekki silnik permutacyjny lub znajdź taki, który wykorzystuje szybkie wykrywanie znaków i nie ma wyrażeń regularnych. Lub po prostu użyj wyrażenia regularnego w ciągu kilku godzin, ale różnica wydajności będzie tutaj zauważalna dla wystarczającej liczby wyszukiwań.

  • Tak wiele rzeczy.

Są to możliwe rozwiązania umożliwiające wdrożenie solidnego indeksowania i wyszukiwania dokumentów. To nie jest all inclusive. I przy tym prawdopodobnie lepiej byłoby złapać zapasowe pudełko, rzucić na niego sieć neuronową i spędzić kilka dni, tworząc fajny interfejs sieciowy do tej sieci neuronowej.

Garet Claborn
źródło