Czym jest SQLite? Wbudowana baza danych SQL w pigułce

SQLite to baza danych wewnątrz twojego programu

Większość znanych baz danych, takich jak MySQL, Postgres czy SQL Server, działa jako osobny program. Uruchamiasz serwer, on nasłuchuje na porcie, a twoja aplikacja łączy się z nim przez sieć, żeby zadawać mu pytania. SQLite wyrzuca cały ten model.

SQLite to biblioteka. Dołączasz ją do swojego programu, a ona daje ci bazę danych SQL, która mieszka w jednym pliku na dysku. Nie ma serwera, portu, demona ani pg_ctl start. Twoja aplikacja otwiera plik i ten plik jest bazą danych.

sqlite3 mydata.db

To polecenie otwiera (albo tworzy) plik o nazwie mydata.db i daje ci wiersz poleceń SQL. Wszystko, co robisz (tabele, wiersze, indeksy), zapisuje się w tym jednym pliku. Skopiuj go na inną maszynę, a baza pojedzie razem z nim. Usuń go, a bazy nie ma.

Szybki przegląd SQL

Sam SQL wygląda jak SQL w każdym innym miejscu. Jeśli znasz inną bazę danych, prawie wszystko wyda ci się znajome:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

Standardowy SQL: CREATE TABLE, INSERT, SELECT, ORDER BY. SQLite obsługuje te części standardu SQL, których faktycznie używasz na co dzień, a do tego nowoczesne udogodnienia, takie jak CTE, funkcje okna i funkcje JSON. Różnice względem Postgresa czy MySQL dotyczą głównie typów i kilku dziwactw składni, które omówimy później.

Co naprawdę znaczy „wbudowana” i „bezserwerowa”

Przy SQLite ciągle pojawiają się dwa słowa. Warto dobrze je zrozumieć.

Wbudowana (embedded) oznacza, że SQLite działa w tym samym procesie co twoja aplikacja. Nie ma osobnego procesu bazy danych. Gdy twój skrypt w Pythonie wywołuje sqlite3.connect("data.db"), silnik SQL działa wewnątrz procesu Pythona i bezpośrednio czyta oraz zapisuje plik.

Bezserwerowa (serverless) oznacza, że nie ma serwera, który trzeba instalować, konfigurować, uruchamiać, zabezpieczać i archiwizować. Porównaj kroki potrzebne, żeby zacząć korzystać z bazy danych:

• Postgres: zainstaluj Postgresa, uruchom usługę, utwórz użytkownika, utwórz bazę, skonfiguruj pg_hba.conf, połącz się przez TCP.
• SQLite: otwórz plik.

Na tym polega cała różnica. Mniej mocy, znacznie mniej ceremonii.

Cała baza to jeden plik

To zaskakuje ludzi najbardziej. Format pliku jest udokumentowany i stabilny: to plik .db (albo .sqlite, albo .sqlite3, rozszerzenie to tylko konwencja), który możesz:

• Wysłać mailem koledze z pracy.
• Dodać do repozytorium git (przynajmniej te małe).
• Skopiować przez cp, żeby mieć natychmiastową kopię zapasową.
• Otworzyć w dowolnym narzędziu SQLite na dowolnym systemie operacyjnym.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

Ten jeden plik zawiera twoje tabele, indeksy, schemat i dane. Bazy SQLite na dysku są identyczne bajt w bajt na Windowsie, macOS, Linuksie, iOS i Androidzie. Format jest tak stabilny, że Biblioteka Kongresu USA zaleca go do długoterminowego przechowywania danych.

Gdzie już używasz SQLite

Na urządzeniu, na którym to czytasz, niemal na pewno są setki baz SQLite. SQLite napędza:

• Pamięć systemową iOS i Androida oraz wiele aplikacji na obu platformach.
• Firefoksa, Chrome i Safari (historia, zakładki, ciasteczka).
• macOS (Mail, Zdjęcia, Dock).
• Większość aplikacji desktopowych na Linuksie, które potrzebują lokalnego magazynu danych.
• Historię czatów w Skype, WhatsAppie i Signalu.
• Katalogi Adobe Lightroom, metadane Dropboxa, biblioteki Steama.

Nazywa się ją najszerzej wdrożonym silnikiem baz danych na świecie i to prawdopodobnie prawda. Powód jest prosty: gdy aplikacja potrzebuje ustrukturyzowanego lokalnego magazynu danych, SQLite to droga najmniejszego oporu.

Czym SQLite nie jest

To nie jest baza danych typu klient-serwer. Dwa programy na różnych maszynach nie mogą jednocześnie połączyć się z bazą SQLite przez sieć, bo nie ma warstwy sieciowej, z którą można by się połączyć. Jeśli tego potrzebujesz, wybierz Postgresa albo MySQL.

Nie jest stworzona do wysokiej współbieżności zapisów. SQLite używa blokad na poziomie pliku (z kilkoma sprytnymi optymalizacjami w trybie WAL), więc choć wielu czytelników może działać równolegle, zatwierdzać zmiany może tylko jeden piszący naraz. W aplikacji dla jednego użytkownika albo na stronie o małym ruchu to żaden problem. W wielodostępnym SaaS, który przyjmuje tysiące zapisów na sekundę, to złe narzędzie.

Nie zarządza użytkownikami ani uprawnieniami. Dostęp do bazy to dostęp do pliku: kto może odczytać plik, ten może odczytać dane. To w porządku w aplikacji, która ma własny plik bazy. Nie w porządku we współdzielonej konfiguracji dla wielu klientów.

Dlaczego warto ją wybrać

To wymiana: prostota w zamian za zapas skalowalności, którego może nigdy nie będziesz potrzebować:

• Zero konfiguracji. Żadnej usługi do uruchamiania. Żadnych niezgodności wersji między środowiskiem deweloperskim a produkcją. Żadnego „baza danych leży”, bo nie ma serwera bazy danych.
• Szybkość. Przy większości obciążeń, zwłaszcza zdominowanych przez odczyty, SQLite jest szybsza niż sieciowa baza danych: nie ma podróży przez gniazdo sieciowe przy każdym zapytaniu.
• Niezawodność. Jest testowana obsesyjnie. Projekt SQLite ma zdecydowanie więcej kodu testów niż kodu źródłowego, a format jest stabilny od 2004 roku.
• Domena publiczna. Darmowa do każdego zastosowania, także komercyjnego. Żadnej licencji do czytania.
• Przenośność. Jeden plik, każda platforma.

W aplikacjach lokalnych, prototypach, urządzeniach wbudowanych, narzędziach CLI, zestawach testów, skryptach do analizy danych oraz małych i średnich stronach internetowych SQLite to często właściwy domyślny wybór, a nie przystanek w drodze do „prawdziwej” bazy danych.

Dalej: SQLite vs MySQL

Naturalne kolejne pytanie brzmi: jak SQLite wypada na tle serwerów baz danych, o których pewnie słyszysz częściej? Zaczniemy od MySQL: gdzie wygrywa każda z nich i jak ocenić, która pasuje do twojego projektu.