Cloudflare D1 wyjaśnione: bezserwerowy SQLite na twoją treść

Przyglądasz się EmDash, widzisz hasło „treść leży w D1” i chcesz wiedzieć, co to naprawdę znaczy, zanim powierzysz temu swoją stronę. Czy D1 to prawdziwa baza danych? Czy SQLite jest wystarczająco poważny na produkcję? Jakie są limity i gdzie to się sypie? Słuszne pytania. Odpowiedzmy na nie wprost.

Czym jest D1, w jednym zdaniu

Cloudflare D1 to bezserwerowa baza danych SQLite, czyli prawdziwa baza SQL, którą Cloudflare prowadzi i skaluje za ciebie, mieszkająca tuż obok twoich Cloudflare Workers, żeby kod mógł ją odpytywać bez zarządzania serwerem bazy.

Dwa słowa zasługują tu na rozwinięcie: SQLite i bezserwerowa.

SQLite, tak, ten SQLite, i tak, to poważna rzecz

SQLite ma opinię „małej” bazy, tej wbudowanej w twój telefon, przeglądarkę i samochód. Ta opinia mu krzywdzi. SQLite to jedno z najszerzej wdrożonych i najlepiej sprawdzonych w boju oprogramowań na świecie, jest naprawdę szybki i mówi standardowym SQL-em: tabele, indeksy, złączenia, transakcje, wszystko.

Czym tradycyjnie nie był, to bazą sieciową, rozproszoną na wiele maszyn. Klasyczny SQLite to plik na jednym dysku, czytany i zapisywany przez jeden proces. To idealne do zastosowań wbudowanych i niewygodne dla globalnej aplikacji webowej, i właśnie ten problem rozwiązuje D1.

Bezserwerowość, czyli Cloudflare prowadzi SQLite za ciebie

D1 bierze SQLite i opakowuje go w zarządzaną, bezserwerową usługę:

• Nie ma serwera do prowadzenia. Nie stawiasz ani nie łatasz maszyny z bazą. Tworzysz bazę i odpytujesz ją ze swojego Workera.
• Powstaje na żądanie. Przy EmDash wrangler tworzy bazę D1 za ciebie przy pierwszym wdrożeniu, nie ma osobnego kroku „postaw Postgresa”.
• Skaluje się w dół do zera. Tak jak Workers, bezczynna baza nie kosztuje cię działającego serwera.

Dostajesz więc szybkość i prostotę SQLite plus model operacyjny „nie ma żadnego serwera bazy danych, o którym trzeba myśleć”.

Kiedy D1 pasuje znakomicie

Mocna strona D1 jest jasna, a strona oparta na treści leży dokładnie pośrodku tego obszaru:

• Obciążenia zdominowane przez odczyty. Strony, które obsługują znacznie więcej odczytów niż zapisów, czyli blogi, dokumentacje, witryny marketingowe i większość CMS-ów, są idealne. Odczyty to właśnie to, co D1 robi najszybciej.
• Umiarkowana liczba zapisów. Publikacja wpisu, edycja treści, sporadyczne wysłanie formularza, wszystko w porządku.
• Dane, które wygodnie mieszczą się w pudełku o kształcie SQLite. Uporządkowana, relacyjna treść. Czyli dokładnie to, co trzyma CMS.

Jeśli twoja aplikacja głównie czyta, ma rozsądne tempo zapisów, a baza mieści się w jednej logicznej bazie SQLite, D1 jest mocnym i prostym wyborem.

Limity, bądźmy wobec nich uczciwi

Żadna baza nie jest magiczna, a D1 ma realne granice, które warto znać, zanim postawisz na niego wszystko:

• Sufit rozmiaru na bazę. Pojedyncza baza D1 kończy się w okolicach 10 GB. To bardzo dużo treści tekstowej, myśl o wielu tysiącach artykułów, ale nie jest to nieskończoność. Ogromne zbiory danych wymagają innego planu (albo rozbicia na kilka baz).
• Współbieżność zapisów. Model SQLite sprzyja odczytom, bardzo intensywne równoległe zapisy nie są jego siłą. CMS rzadko na to trafia, ale strumień analityczny pełen zapisów już tak.
• To SQLite, nie Postgres. Żadnych rozszerzeń specyficznych dla Postgresa, żadnych procedur składowanych w duchu PL/pgSQL. Jeśli polegasz na zaawansowanych funkcjach Postgresa, D1 nie jest wymianą jeden do jednego.
• Wciąż dojrzewa. Jak na zarządzane bazy danych D1 jest stosunkowo młody. Jest gotowy na produkcję w swoim obszarze, ale to nie liczona w dekadach instalacja Postgresa.

Szczere podsumowanie: przy stronie opartej na treści żaden z tych limitów raczej cię nie ugryzie. Przy aplikacji z intensywnymi zapisami i wieloma terabajtami danych D1 to złe narzędzie, i to jest w porządku, bo wcale nie próbuje nim być.

Jak EmDash używa D1 do przechowywania treści

EmDash, otwarty CMS Cloudflare, trzyma w D1 swoją treść strukturalną i metadane. Ponieważ treść to przenośny JSON, a nie bryła HTML-a, naturalnie odwzorowuje się na tabele SQL: wpisy, pola, taksonomie, relacje. Gdy czytelnik wchodzi na stronę, Worker odpytuje D1 (tuż obok, bez skoku przez sieć do odległej bazy) i renderuje stronę na brzegu sieci.

Doświadczenie programisty jest celowo nudne i o to właśnie chodzi:

# EmDash tworzy bazę D1 za ciebie przy pierwszym wdrożeniu, ale możesz też
# stworzyć i podejrzeć bazę bezpośrednio przez wrangler:
npx wrangler d1 create my-site-db
npx wrangler d1 execute my-site-db --command "SELECT count(*) FROM posts;"

Przy pierwszym wdrożeniu EmDash automatycznie stosuje migracje schematu podczas pierwszego żądania, więc nie musisz ręcznie odpalać SQL-a, żeby ruszyć.

Dlaczego to połączenie tak dobrze sprawdza się w CMS-ie:

• Treść mieszka obok mocy obliczeniowej. Worker i D1 w tej samej sieci brzegowej oznaczają szybkie zapytania bez podróży do zdalnej bazy.
• Przewaga odczytów to naturalne środowisko D1. Serwowanie treści to w przeważającej mierze odczyty, dokładnie to, pod co D1 jest optymalizowany.
• Sufit 10 GB jest ogromny jak na tekst. Blog albo strona z dokumentacją zmieści lata treści i nawet się do niego nie zbliży.
• Zero utrzymywania bazy. Nie ma Postgresa do skalowania, łatania, ręcznego backupowania ani ratowania o trzeciej nad ranem.

Gdzie D1 mieści się w szerszym obrazie

D1 to jedna z trzech nóg bezserwerowego stosu, na którym stoi EmDash:

• Workers uruchamiają kod na brzegu sieci.
• D1 trzyma treść strukturalną.
• R2 przechowuje pliki i media (bez opłat za transfer wychodzący).

Każdy element jest bezserwerowy i skaluje się do zera, więc mała strona może kosztować prawie nic, a ruchliwa skaluje się bez przebudowy architektury. Z tego samego powodu na tym stosie działa własny blog Cloudflare, który bez dramatu wchłonął atak DDoS o sile 28 000 żądań na sekundę.

Jeśli oceniasz EmDash i martwisz się, że „SQLite nie może być poważny”, szczera odpowiedź brzmi: przy stronie opartej na treści jak najbardziej jest, a D1 daje ci szybkość SQLite bez niańczenia serwera.

Piszemy o tym, bo czytelnicy o to pytają. To, co faktycznie robimy w 2emdash, to odbudowa starzejących się stron na Cloudflare i przekazanie właścicielowi prostego panelu. Jesteśmy niezależnym serwisem, bez powiązania z Cloudflare ani projektem EmDash.