Mësime për Database scaling nga dizajni i Cloudflare D1
Database scaling është mësimi qendror në përshkrimin që Cloudflare i bën D1, shërbimit të saj SQL database të ndërtuar rreth shumë databazave të vogla, në vend të një databaze të madhe të përbashkët. Dizajni ndan Control plane, që do të thotë ana e menaxhimit që krijon, fshin dhe gjurmon databazat, nga Hot path, që do të thotë rruga live që ndjek një user query kur një aplikacion pret një përgjigje.
Kur një përdorues krijon një D1 database, Cloudflare thotë se ndodhin disa hapa përpara se queries të mund të ekzekutohen. Sistemi kontrollon nëse account lejohet të krijojë një databazë tjetër sipas free tier ose account limits. Më pas gjeneron një D1 database UUID unik, që është një identifikues unik, krijon një Durable Object ID unik duke përdorur newUniqueId(), inicializon Durable Object bazë, ruan një metadata row në Postgres dhe shkruan një mapping nga database ID te Durable Object ID në Workers KV. Durable Objects janë objektet stateful compute të Cloudflare, të përdorura këtu si pika e ekzekutimit për çdo databazë. Workers KV është një key-value store i shpërndarë globalisht, i përdorur për routing data.
Vendosja e këtyre hapave ka rëndësi. Cloudflare thotë se Edge API Worker fillestar ekzekutohet afër kërkesës hyrëse, por creation requests që bëjnë disa round trips drejt Postgres dërgohen te data centers pranë Postgres cluster. Arsyeja është latency: një round trip nga larg mund të zgjasë qindra milisekonda, ndërsa një i afërt mund të zgjasë vetëm disa milisekonda. Si parazgjedhje, një D1 database krijohet pranë request location, megjithëse përdoruesi mund të japë një location hint ose jurisdiction, duke përdorur të njëjtat opsione që mbështeten nga Durable Objects. Për ta mbajtur databazën pranë përdoruesit, ndërkohë që ende ulet Postgres latency, Cloudflare e përcjell ekzekutimin brenda sistemit pranë Postgres, pastaj thërret Durable Object nga një data center afër vendndodhjes origjinale të kërkesës.
Cloudflare e trajton Postgres write si creation checkpoint. Pasi Durable Object inicializohet, database metadata shkruhet në Postgres primary qendror përmes Hyperdrive, database connectivity layer i Cloudflare. Nëse Durable Object initialization ose Postgres write dështon, worker provon përsëri me identifikues të ndryshëm. Pasi row është në Postgres, databaza konsiderohet e krijuar edhe nëse përgjigjja përfundimtare nuk arrin te përdoruesi. Një final confirmation call te Durable Object ekzekutohet në waitUntil(), ndaj mund të dështojë pa bllokuar krijimin. Ajo call i tregon Durable Object se databaza është aktive dhe i lejon të përditësojë Workers KV, në mënyrë që queries të mëvonshme të gjejnë shpejt routing metadata.
Një alternativë joshëse do të ishte vendosja e të gjithë creation flow në një Postgres transaction, që është një database operation që ose përfundon plotësisht, ose kthehet plotësisht mbrapsht. Cloudflare thotë se kjo nuk do të shkallëzohej, sepse database connections do të mbaheshin të hapura ndërsa një Durable Object inicializohet, potencialisht në anën tjetër të botës. Mësimi më i gjerë është se një databazë qendrore nuk duhet të detyrohet të presë për long-distance external work kur platforma duhet të krijojë numra të mëdhenj resources.
D1 përdor gjithashtu heartbeats për të riparuar state pas partial failures. Çdo D1 Durable Object kontakton periodikisht Control plane për të marrë database state më të fundit, active ose deleted, dhe account limits. Cloudflare thotë se intervali është 30 sekonda, me jitter për çdo databazë, dhe se ka kontrolle për të ndryshuar intervalin për databazë ose account, ose për t’i çaktivizuar plotësisht heartbeats. Meqë heartbeats mund të tolerojnë të dhëna paksa të vjetruara, ato mund të shërbehen nga Hyperdrive caches ose Postgres read replicas, që janë kopje read-only të databazës kryesore.
Dizajni i retry shpjegon pse përdoren identifikues të rinj pas një përpjekjeje të dështuar krijimi. Nëse Cloudflare do të ripërdorte të njëjtin database UUID me një Durable Object ID të ri, më shumë se një Durable Object mund të besonte se zotëronte të njëjtën databazë. Në shembullin e Cloudflare, Durable Object A mund të inicializohet me sukses, por të dështojë përpara Postgres write. Retry inicializon Durable Object B dhe shkruan me sukses B në Postgres. Përdoruesit mund të bëjnë query vetëm te B, sepse Postgres është source of truth. Brenda 30 sekondave, A bën heartbeat, mëson se databaza e tij nuk ekziston dhe e shënon veten si deleted. I njëjti model vetërregullues zbatohet edhe për deletion, dhe heartbeats në fund riparojnë Workers KV nëse një best-effort update dështon.
Për live SQL queries, rregulli kryesor i Cloudflare është të shmanget Postgres ose çdo komponent tjetër i centralizuar në një single-region. Një query i bërë përmes HTTP API fillimisht arrin te Edge API Worker, i cili merret me authentication, authorization, rate limiting, request validation dhe entitlement checks. Më pas përpiqet të ngarkojë database mapping nga Workers KV. Nëse ai item mungon, sistemi kalon si fallback te Hyperdrive kundrejt Postgres replicas. Hyperdrive fillimisht kontrollon një cache në vendndodhjen e thirrësit, pastaj një cache pranë Postgres cluster dhe vetëm më pas bën query te replicas.
Pasi gjendet mapping, Edge API Worker thërret Eyeball Worker përmes Worker Service Bindings, një mekanizëm që një Worker të thërrasë një tjetër. Eyeball Worker validon kërkesën dhe e përcjell te D1 Durable Object, i cili ekzekuton SQL query dhe kthen rezultatin. Queries nga një user Worker me një D1 Binding nuk kanë nevojë të zgjidhin D1 UUID mapping, sepse binding tashmë mban informacionin e nevojshëm, ndaj shkojnë drejtpërdrejt te Eyeball Worker dhe Durable Object.
Cloudflare shpjegon gjithashtu pse D1 përdor Workers KV edhe pse Hyperdrive ka caching. Workers KV përdoret si durable datastore, jo vetëm si temporary cache. Nëse një item largohet nga KV’s edge cache, leximi vjen nga storage vetjak i KV, jo nga Postgres. Cloudflare paralajmëron se në një skenar katastrofik cache purge, një milion databaza që marrin routing information nga Postgres mund të krijojnë metastable failures, ku load i shkaktuar nga recovery e pengon recovery të ketë sukses.
Usage limits trajtohen në mënyrë asinkrone. Cloudflare thotë se D1 ka, në kohën e shkrimit, një storage limit prej 5 GB për account në planin Free dhe 1 TB në Workers Paid, me paid limit që mund të rritet me kërkesë. Çdo Durable Object publikon storage usage updates në një queue të ngjashëm me Kafka, që është një sistem për buffer events në mënyrë që consumers t’i përpunojnë më vonë. Queue consumers ekzekutohen në data centers qendrore të Cloudflare, ndërsa Durable Objects janë të shpërndarë në edge. Kjo i zbut dhe i grupon writes përpara se të arrijnë te Postgres.
Për enforcement, D1 ka nevojë për account-wide storage totals, jo vetëm madhësi për databazë. Cloudflare thotë se ekzekutimi i SELECT sum(storage) në çdo databazë për një account do të shkallëzohej në mënyrë lineare dhe nuk do të funksiononte për accounts me miliona D1 databases. Në vend të kësaj, D1 shkruan madhësitë për databazë në database_stats, përdor një trigger për të shkruar deltas në account_database_stats_changes dhe ekzekuton një scheduled job çdo sekondë për t’i agreguar ato deltas në account_database_stats. Query përdor DELETE ...