5 sposobów na zaimplementowanie wyszukiwania bez rozróżniania wielkości liter w SQLite z pełną obsługą Unicode

Zwróć złożoną kopię ciągu. Łańcuchy złożone z wielkości liter mogą być używane do dopasowywania bez wielkości liter.

Składanie liter jest podobne do małych liter, ale jest bardziej agresywne, ponieważ ma na celu usunięcie wszystkich różnic w wielkości liter w ciągu. Na przykład niemiecka mała litera „ß” jest odpowiednikiem „ss”. Ponieważ jest już małymi literami, lower() nie zrobi nic 'ß'; casefold() konwertuje go na "ss".

Dlatego poniżej użyjemy str.casefold() funkcja dla wszystkich konwersji i porównań.

2. Sortowanie zdefiniowane przez aplikację

Aby przeprowadzić wyszukiwanie bez rozróżniania wielkości liter dla wszystkich symboli Unicode, musimy zdefiniować nowe sortowanie w aplikacji po połączeniu się z bazą danych (dokumentacja). Tutaj masz wybór – przeciąż wbudowany NOCASE lub stwórz własną – omówimy zalety i wady poniżej. Dla przykładu użyjemy nowej nazwy:

import sqlite3

# Custom collation, maybe it is more efficient
# to store strings
def unicode_nocase_collation(a: str, b: str):
    if a.casefold() == b.casefold():
        return 0
    if a.casefold() < b.casefold():
        return -1
    return 1

connection.create_collation(
    "UNICODE_NOCASE", unicode_nocase_collation
)

# Connect to the DB and register the function
connection = sqlite3.connect("your_db_path")
connection.create_collation(
    "UNICODE_NOCASE", unicode_nocase_collation
)

# Or, if you use SQLAlchemy you need to register
# the collation via an event
@sa.event.listens_for(sa.engine.Engine, 'connect')
def sqlite_engine_connect(connection, _):
    connection.create_collation(
    "UNICODE_NOCASE", unicode_nocase_collation
)

Zestawienia mają kilka zalet w porównaniu z kolejnymi rozwiązaniami:

1. Są łatwe w użyciu. Możesz określić sortowanie w schemacie tabeli i będzie ono automatycznie stosowane do wszystkich zapytań i indeksów w tym polu, chyba że określisz inaczej:
   

   CREATE TABLE test (text VARCHAR COLLATE UNICODE_NOCASE);
   

   Dla kompletności przyjrzyjmy się jeszcze dwóm sposobom używania sortowania:
   

   -- In a particular query:
   SELECT * FROM items
       WHERE text = "Text in AnY case" COLLATE UNICODE_NOCASE;
   
   -- In an index:
   CREATE INDEX IF NOT EXISTS idx1 
       ON test (text COLLATE UNICODE_NOCASE);
   
   -- Word of caution: your query and index 
   -- must match exactly,including collation, 
   -- otherwise, SQLite will perform a full table scan.
   -- More on indexes below.
   EXPLAIN QUERY PLAN
       SELECT * FROM test WHERE text = 'something';
   -- Output: SCAN TABLE test
   EXPLAIN QUERY PLAN
       SELECT * FROM test WHERE text = 'something' COLLATE NOCASE;
   -- Output: SEARCH TABLE test USING COVERING INDEX idx1 (text=?)
   

2. Sortowanie zapewnia sortowanie bez rozróżniania wielkości liter za pomocą ORDER BY po wyjęciu z pudełka. Jest to szczególnie łatwe do uzyskania, jeśli zdefiniujesz sortowanie w schemacie tabeli.

Zestawienia pod kątem wydajności mają pewne cechy szczególne, które omówimy dalej.

3. Funkcja SQL zdefiniowana przez aplikację

Innym sposobem uzyskania wyszukiwania bez rozróżniania wielkości liter jest utworzenie zdefiniowanej przez aplikację funkcji SQL (dokumentacja):

import sqlite3

# Custom function
def casefold(s: str):
    return s.casefold()

# Connect to the DB and register the function
connection = sqlite3.connect("your_db_path")
connection.create_function("CASEFOLD", 1, casefold)

# Or, if you use SQLAlchemy you need to register 
# the function via an event
@sa.event.listens_for(sa.engine.Engine, 'connect')
def sqlite_engine_connect(connection, _):
    connection.create_function("CASEFOLD", 1, casefold)

W obu przypadkach create_function akceptuje do czterech argumentów:

• nazwa funkcji, jaka będzie używana w zapytaniach SQL
• liczba argumentów, które funkcja akceptuje
• sama funkcja
• opcjonalny bool deterministic , domyślnie False (dodane w Pythonie 3.8) – ważne dla indeksów, które omówimy poniżej.

Podobnie jak w przypadku sortowania, masz wybór – przeciąż wbudowaną funkcję (np. LOWER ) lub utwórz nowy. Przyjrzymy się temu bardziej szczegółowo później.

4. Porównaj w aplikacji

Innym sposobem wyszukiwania bez uwzględniania wielkości liter byłoby porównywanie w samej aplikacji, zwłaszcza jeśli można zawęzić wyszukiwanie za pomocą indeksu w innych polach. Na przykład, w listOK potrzebne jest porównanie bez rozróżniania wielkości liter dla pozycji na określonej liście. Dlatego mogłem wybrać wszystkie pozycje z listy, znormalizować je do jednego przypadku i porównać je ze znormalizowanym nowym elementem.

W zależności od okoliczności nie jest to złe rozwiązanie, zwłaszcza jeśli podzbiór, z którym będziesz porównywać, jest niewielki. Jednak nie będziesz w stanie wykorzystać indeksów bazy danych na tekście, a jedynie na innych parametrach, których będziesz używać do zawężenia zakresu.

Zaletą tego podejścia jest jego elastyczność:w aplikacji można sprawdzić nie tylko równość, ale np. zaimplementować „rozmyte” porównanie uwzględniające ewentualne błędy drukarskie, formy liczby pojedynczej/mnogiej itp. Taką drogę wybrałem dla listOK ponieważ bot potrzebował rozmytych porównań do tworzenia "inteligentnych" przedmiotów.

Ponadto eliminuje wszelkie sprzężenia z bazą danych – jest to proste przechowywanie, które nie wie nic o danych.

5. Przechowuj znormalizowane pole osobno

Jest jeszcze jedno rozwiązanie:utwórz osobną kolumnę w bazie danych i trzymaj tam znormalizowany tekst, którego będziesz szukać. Na przykład tabela może mieć taką strukturę (tylko odpowiednie pola):

Na pierwszy rzut oka może się to wydawać przesadne:zawsze musisz aktualizować znormalizowaną wersję i skutecznie podwajać rozmiar name pole. Jednak za pomocą ORM lub nawet ręcznie jest to łatwe, a miejsce na dysku i pamięć RAM są tanie.

Zalety tego podejścia:

• Całkowicie oddziela aplikację i bazę danych – możesz łatwo się przełączać.

• Możesz wstępnie przetworzyć znormalizowane pliki, jeśli wymagają tego Twoje zapytania (przycinanie, usuwanie znaków interpunkcyjnych lub spacji itp.).

Czy należy przeciążać wbudowane funkcje i sortowanie?

Używając zdefiniowanych przez aplikację funkcji SQL i sortowania, często masz wybór:użyj unikalnej nazwy lub przeciąż wbudowaną funkcjonalność. Oba podejścia mają swoje zalety i wady w dwóch głównych wymiarach:

Po pierwsze, niezawodność/przewidywalność gdy z jakiegoś powodu (jednorazowy błąd, błąd lub celowo) nie zarejestrujesz tych funkcji lub zestawień:

• Przeciążenie:baza danych będzie nadal działać, ale wyniki mogą nie być poprawne:

  • wbudowana funkcja/porównanie będzie zachowywać się inaczej niż ich niestandardowe odpowiedniki;
  • jeśli użyłeś teraz nieobecnego sortowania w indeksie, będzie wyglądało na to, że działa, ale wyniki mogą być błędne nawet podczas czytania;
  • Jeśli tabela z indeksem i indeksem przy użyciu funkcji niestandardowej/porównania zostanie zaktualizowana, indeks może ulec uszkodzeniu (zaktualizowany przy użyciu wbudowanej implementacji), ale kontynuuj pracę tak, jakby nic się nie stało.

• Nie przeciążanie:baza danych nie będzie działać pod żadnym względem, gdy używane są nieobecne funkcje lub sortowania:

  • jeśli użyjesz indeksu dla nieobecnej funkcji, będziesz mógł użyć go do czytania, ale nie do aktualizacji;
  • indeksy z sortowaniem zdefiniowanym przez aplikację w ogóle nie będą działać, ponieważ używają one sortowania podczas wyszukiwania w indeksie.

Po drugie, dostępność poza główną aplikacją:migracje, analityka itp.:

• Przeciążenie:będziesz mógł bez problemu modyfikować bazę danych, pamiętając o ryzyku uszkodzenia indeksów.

• Nie przeciążanie:w wielu przypadkach będziesz musiał zarejestrować te funkcje lub sortowanie lub podjąć dodatkowe kroki, aby uniknąć części bazy danych, które od nich zależą.

Jeśli zdecydujesz się na przeciążenie, dobrym pomysłem może być przebudowanie indeksów na podstawie niestandardowych funkcji lub sortowania na wypadek, gdyby zostały tam zapisane nieprawidłowe dane, na przykład:

-- Rebuild all indexes using this collation
REINDEX YOUR_COLLATION_NAME;

-- Rebuild particular index
REINDEX index_name;

-- Rebuild all indexes
REINDEX;

Wydajność funkcji i zestawień zdefiniowanych przez aplikację

Funkcje niestandardowe lub sortowanie są znacznie wolniejsze niż funkcje wbudowane:SQLite "powraca" do aplikacji za każdym razem, gdy wywołuje funkcję. Możesz to łatwo sprawdzić, dodając do funkcji licznik globalny:

counter = 0

def casefold(a: str):
    global counter
    counter += 1
    return a.casefold()

# Work with the database

print(counter)
# Number of times the function has been called

Jeśli rzadko wysyłasz zapytania lub Twoja baza danych jest mała, nie zobaczysz żadnej znaczącej różnicy. Jeśli jednak nie użyjesz indeksu dla tej funkcji/porównania, baza danych może wykonać pełne skanowanie tabeli, stosując funkcję/porównanie w każdym wierszu. W zależności od wielkości tabeli, sprzętu i liczby żądań, niska wydajność może być zaskoczeniem. Później opublikuję przegląd funkcji zdefiniowanych przez aplikację i wydajności sortowania.

Ściśle mówiąc, sortowanie jest nieco wolniejsze niż funkcje SQL, ponieważ dla każdego porównania muszą składać dwa łańcuchy zamiast jednego. Chociaż ta różnica jest bardzo mała:w moich testach funkcja casefold była szybsza niż podobne zestawienie dla około 25%, co stanowiło różnicę 10 sekund po 100 milionach iteracji.

Indeksy i wyszukiwanie bez rozróżniania wielkości liter

Indeksy i funkcje

Zacznijmy od podstaw:jeśli zdefiniujesz indeks w dowolnym polu, nie będzie on używany w zapytaniach dotyczących funkcji zastosowanej do tego pola:

CREATE TABLE table_name (id INTEGER, name VARCHAR);
CREATE INDEX idx1 ON table_name (name);
EXPLAIN QUERY PLAN
    SELECT id, name FROM table_name WHERE LOWER(name) = 'test';
-- Output: SCAN TABLE table_name

Do takich zapytań potrzebny jest osobny indeks z samą funkcją:

CREATE INDEX idx1 ON table_name (LOWER(name));
EXPLAIN QUERY PLAN
    SELECT id, name 
        FROM table_name WHERE LOWER(name) = 'test';
-- Output: SEARCH TABLE table_name USING INDEX idx1 (<expr>=?)

W SQLite można to zrobić również na funkcji niestandardowej, ale musi być ona oznaczona jako deterministyczna (co oznacza, że ​​przy tych samych danych wejściowych zwraca ten sam wynik):

connection.create_function(
    "CASEFOLD", 1, casefold, deterministic=True
)

Następnie możesz utworzyć indeks dla niestandardowej funkcji SQL:

CREATE INDEX idx1 
    ON table_name (CASEFOLD(name));
EXPLAIN QUERY PLAN
    SELECT id, name 
        FROM table_name WHERE CASEFOLD(name) = 'test';
-- Output: SEARCH TABLE table_name USING INDEX idx1 (<expr>=?)

Indeksy i zestawienia

Sytuacja z sortowaniem i indeksami jest podobna:aby zapytanie korzystało z indeksu, musi używać tego samego sortowania (dorozumianego lub podanego wprost), w przeciwnym razie nie zadziała.

-- Table without specified collation will use BINARY
CREATE TABLE test (id INTEGER, text VARCHAR);

-- Create an index with a different collation
CREATE INDEX IF NOT EXISTS idx1 ON test (text COLLATE NOCASE);


-- Query will use default column collation -- BINARY
-- and the index will not be used
EXPLAIN QUERY PLAN
    SELECT * FROM test WHERE text = 'test';
-- Output: SCAN TABLE test


-- Now collations match and index is used
EXPLAIN QUERY PLAN
    SELECT * FROM test WHERE text = 'test' COLLATE NOCASE;
-- Output: SEARCH TABLE test USING INDEX idx1 (text=?)

Jak wspomniano powyżej, sortowanie można określić dla kolumny w schemacie tabeli. To najwygodniejszy sposób – zostanie automatycznie zastosowany do wszystkich zapytań i indeksów w odpowiednim polu, chyba że określisz inaczej:

-- Using application defined collation UNICODE_NOCASE from above
CREATE TABLE test (text VARCHAR COLLATE UNICODE_NOCASE);

-- Index will be built using the collation
CREATE INDEX idx1 ON test (text);

-- Query will utilize index and collation automatically
EXPLAIN QUERY PLAN
    SELECT * FROM test WHERE text = 'something';
-- Output: SEARCH TABLE test USING COVERING INDEX idx1 (text=?)

Które rozwiązanie wybrać?

Aby wybrać rozwiązanie, potrzebujemy kilku kryteriów porównawczych:

1. Prostota – jak trudno jest go wdrożyć i utrzymać

2. Wydajność – jak szybko będą Twoje zapytania

3. Dodatkowa przestrzeń – ile dodatkowej przestrzeni bazy danych wymaga rozwiązanie

4. Sprzęganie – jak bardzo Twoje rozwiązanie splata kod i pamięć

Jak zwykle wybór rozwiązania będzie zależał od przypadku użycia i wymagań dotyczących wydajności. Osobiście wybrałbym niestandardowe sortowanie, porównywanie w aplikacji lub przechowywanie znormalizowanego ciągu. Na przykład w listOK najpierw użyłem sortowania i przeszedłem do porównywania w aplikacji po dodaniu wyszukiwania rozmytego.