Właśnie przeczytałem post wspominający o „wyszukiwaniu pełnotekstowym” w SQL.
Właśnie się zastanawiałem, jaka jest różnica między FTS a LIKE. Przeczytałem kilka artykułów, ale nie mogłem znaleźć niczego, co by to dobrze wyjaśniło.
Odpowiedzi:
Ogólnie rzecz biorąc, istnieje kompromis między „precyzją” a „przywołaniem”. Wysoka precyzja oznacza, że prezentowanych jest mniej wyników nieistotnych (brak fałszywych trafień), podczas gdy wysoka powtarzalność oznacza, że brakuje mniej odpowiednich wyników (brak fałszywych wyników negatywnych). Użycie operatora LIKE zapewnia 100% precyzję bez ustępstw na przywołanie. Funkcja wyszukiwania pełnotekstowego zapewnia dużą elastyczność w zmniejszaniu precyzji w celu lepszego przywoływania.
Większość implementacji wyszukiwania pełnotekstowego używa „indeksu odwróconego”. Jest to indeks, w którym klucze są pojedynczymi terminami, a powiązane wartości to zestawy rekordów, które zawierają termin. Wyszukiwanie pełnotekstowe jest zoptymalizowane do obliczania przecięcia, sumy itp. Tych zestawów rekordów i zwykle zapewnia algorytm rankingowy do ilościowego określenia, jak mocno dany rekord pasuje do słów kluczowych wyszukiwania.
Operator SQL LIKE może być wyjątkowo nieefektywny. Jeśli zastosujesz ją do nieindeksowanej kolumny, pełne skanowanie zostanie użyte do znalezienia dopasowań (tak jak każde zapytanie w nieindeksowanym polu). Jeśli kolumna jest indeksowana, dopasowywanie można przeprowadzić względem kluczy indeksu, ale z dużo mniejszą wydajnością niż większość wyszukiwań indeksu. W najgorszym przypadku wzorzec LIKE będzie zawierał wiodące symbole wieloznaczne, które wymagają zbadania każdego klucza indeksu. W przeciwieństwie do tego, wiele systemów wyszukiwania informacji może umożliwić obsługę wiodących symboli wieloznacznych poprzez wstępną kompilację drzew sufiksów w wybranych polach.
Inne cechy typowe dla wyszukiwania pełnotekstowego to
FTS polega na indeksowaniu poszczególnych słów w polu tekstowym w celu szybkiego przeszukiwania wielu rekordów. Korzystanie z funkcji LIKE nadal wymaga wyszukiwania ciągów znaków (liniowych lub podobnych) w polu.
MySQL tworzy indeks na podstawie słów z włączonej kolumny wyszukiwania pełnotekstowego i przeprowadza wyszukiwania w tym indeksie. MySQL używa wyrafinowanego algorytmu do określenia wierszy dopasowanych do zapytania wyszukiwania.
Również z tej odpowiedzi SO :
Wyszukiwanie pełnotekstowe ma kilka zalet.
Indeksowanie:
Coś jak:
WHERE Foo LIKE '%Bar';Nie można skorzystać z indeksu. Musi przyjrzeć się każdemu wierszowi i sprawdzić, czy pasuje. Jednak pełnotekstowy indeks może. W rzeczywistości indeksy pełnotekstowe mogą oferować znacznie większą elastyczność pod względem kolejności dopasowywania słów, stopnia bliskości tych słów itp.
Przybitka:
Wyszukiwanie pełnotekstowe może łączyć słowa. Jeśli wyszukujesz wyrażenie „run”, możesz otrzymać wyniki „run” lub „running”. Większość silników pełnotekstowych ma słowniki macierzyste w różnych językach.
Wyniki ważone:
Indeks pełnotekstowy może obejmować wiele kolumn. Na przykład możesz wyszukać hasło „ciasto brzoskwiniowe”, a indeks może zawierać tytuł, słowa kluczowe i treść. Wyniki pasujące do tytułu mogą być ważone wyżej, jako bardziej trafne i można je posortować tak, aby były wyświetlane u góry.
Niedogodności:
Indeks pełnotekstowy może być potencjalnie ogromny, wielokrotnie większy niż standardowy indeks B-TREE. Z tego powodu wielu hostowanych dostawców, którzy oferują instancje baz danych, wyłącza tę funkcję lub przynajmniej pobiera za nią dodatkową opłatę. Na przykład, ostatnio sprawdzałem, Windows Azure nie obsługuje zapytań pełnotekstowych.
Indeksy pełnotekstowe mogą być również wolniej aktualizowane. Jeśli dane bardzo się zmieniają, może wystąpić opóźnienie w aktualizacji indeksów w porównaniu ze standardowymi indeksami.
Like używa tylko symboli wieloznacznych i nie jest aż tak potężne.
Pełny tekst umożliwia znacznie bardziej złożone wyszukiwanie, w tym And, Or, Not, nawet podobnie brzmiących wyników (SOUNDEX) i wiele innych elementów.
Zacząłbym patrzeć na SQL CONTAINS () FREETEXT () i powiązane elementy wyszukiwania pełnotekstowego, aby lepiej zrozumieć, co jest dostępne.
Prawdziwą różnicą są metodologie skanowania. W przypadku wyszukiwania pełnotekstowego słowa (terminy) są używane jako klucze z krzyżykiem - z których każdy jest powiązany z tablicą dokumentów, w których występują klucze (terminy). Jest to tak:
Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}
Teraz macierz termin-dokument (który termin jest członkiem jakiego dokumentu) można przedstawić jako:
t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}
Kiedy przychodzi prośba o „Pobierz wszystkie dokumenty zawierające słowo / termin t1” - wtedy {d1, d5, d9,.. dnzwracany jest zestaw dokumentów }.
Możesz zhakować zdenormalizowany schemat tabeli w celu przechowywania dokumentów - każdy wiersz w tabeli MySQL będzie traktowany jako „dokument”, a kolumna TEKST może zawierać akapit itp. Odwrócony indeks będzie zawierał terminy w postaci kluczy haszujących i identyfikatorów wierszy jako identyfikatory dokumentu.
Pamiętaj, że to zapytanie SQL będzie miało mniej więcej wydajność O (1). Zapytanie będzie niezależne od
Na przykład ten kod SQL może zostać uruchomiony w celu wyodrębnienia wszystkich wierszy pasujących do podanego słowa XYZ:
SELECT *
FROM my_table
WHERE MATCH (my_text_column) against ('XYZ' IN boolean mode) ;
Uwaga: jeśli dodasz ORDER BY do tego zapytania, Twoje środowiska wykonawcze będą się różnić w zależności od kilku parametrów, z których jednym jest liczba pasujących wierszy / dokumentów. Więc uważaj.
LIKE jednak nic takiego nie ma. Jest zmuszony do liniowego przeszukiwania zdania / łańcucha i znalezienia wszystkich pasujących terminów. Dodanie dzikiej karty pogłębia bałagan. Jak możesz sobie wyobrazić, świetnie sprawdza się w przypadku strun o małej długości, ale nie udaje się przy dłuższych zdaniach. I zdecydowanie nieporównywalne z paragrafem lub całą stroną tekstu itp.
FTS jest wydajniejszy, potężniejszy (szczególnie w przypadku łamaczy słów i funkcji tworzenia rang) ... ale sprawdź swoje wymagania, ponieważ czasami bazy danych nie obsługują wszystkich języków, na przykład MSSQL nie obsługuje greckiego (sprawdź na tej stronie http: // msdn. microsoft.com/en-us/library/ms176076(v=sql.110).aspx )