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?