Arkkitehtuurin yleiskuva

Tämä on se sivu, joka kannattaa lukea ensin ennen JDBIN, JDBON, R2 + Worker Runtime ja vertailuja muihin järjestelmiin.

30 sekunnin vastaus

Tämän arkkitehtuurin kiinnostavin ero ei ole vain uusi binääriformaatti. Kiinnostavin ero on se, että kyselypolku on rakennettu Cloudflare Workerin ja R2 Object Storagen ympärille ilman erillistä tietokantapalvelinta.

Ydinajatus yhdellä kuvalla

Client
  -> Cloudflare Worker
  -> query planner
  -> range reader
  -> R2 object
  -> JDBIN / JDBON
  -> JSON response

Worker ei lataa koko objektia, vaan hakee vain tarvittavat tavuvälit R2:sta.

Mikä tässä on eri kuin perinteisessä tietokantamallissa?

Moni perinteinen arkkitehtuuri näyttää tältä:

Disk
  -> database process
  -> query engine
  -> client

Siinä tietokantaprosessi omistaa levyn, kyselyoptimoinnin ja suorituksen.

Tässä mallissa lähtökohta on toinen:

Object Storage (R2)
  -> HTTP Range GET
  -> Cloudflare Worker
  -> planner
  -> JSON

Rinnakkaisvertailu yhdellä silmäyksellä

Perinteinen DB-malli

Client
  -> SQL query
  -> database process
  -> optimizer / execution engine
  -> local disk pages
  -> rows back to client

Ominaispiirteet:

• tietokantaprosessi omistaa levyn
• kyselymoottori ja suoritus ovat samassa palvelimessa
• levyä luetaan tietokannan omasta runtime-kontekstista
• object storage ei ole varsinainen ensisijainen lukukerros

R2 + Worker + JDBIN -malli

Client
  -> HTTP request
  -> Cloudflare Worker
  -> query planner
  -> HTTP Range GET
  -> R2 object
  -> JDBIN segmentit
  -> JSON response

Ominaispiirteet:

• kanoninen data on object storagessa
• Worker toimii kyselymoottorina julkisen rajapinnan äärellä
• lukeminen tapahtuu tavuväleittäin koko objektin lataamisen sijaan
• tietokantapalvelinta ei tarvita erillisenä kerroksena

Taulukkoero

Eli:

• kanoninen tallennuskerros on object storage
• kyselylogiikka elää Workerissa
• lukeminen tapahtuu byte-range-hakuina
• lopputulos toimitetaan snapshot- tai JSON-vastauksena käyttöliittymälle

Miksi Cloudflare on tässä olennainen?

Cloudflare ei ole tässä vain hosting-paikka, vaan osa itse arkkitehtuuria.

Keskeiset rakennuspalikat ovat:

• R2, joka toimii kanonisena immutable object storage -kerroksena
• Worker, joka toimii query plannerina, range readerina, parserina ja vastausten kokoajana
• HTTP Range GET, joka mahdollistaa selektiivisen luvun ilman koko objektin lataamista
• edge-runtime, joka pitää kyselypolun lähellä julkista rajapintaa

Mitä JDBIN ja JDBON tekevät tässä jaossa?

Yksinkertaistettuna:

• JDBIN on lukupolulle optimoitu binäärinen data-artefakti
• JDBON on julkaisu-, manifesti- ja ohjauskerros
• Worker ratkaisee mitä osia luetaan
• R2 säilyttää aktiivisen tilan, baset, deltat ja snapshotit

Tämä tarkoittaa, että kyselypolku ja julkaisupolku on erotettu toisistaan tietoisesti.

Mitä tämä ei tarkoita?

Tätä ei pidä kuvata niin, että kyse olisi jo yleisestä SQL-tietokannasta tai täydestä tietokantamoottorista.

Nykyinen turvallinen rajaus on:

• ei yleinen SQL-parseri
• ei yleinen execution engine kaikkeen
• ei yleiskäyttöinen OLTP-tietokanta
• ei perinteinen database server, joka omistaa levyn ja suorituksen

Mikä tästä tekee kiinnostavan tutkimuskysymyksen?

Tutkimuskysymys ei ole vain "voiko binääriformaatti tallentaa dataa", vaan:

Voiko immutable object storage toimia kyseltävänä lukukerroksena ilman erillistä tietokantapalvelinta, jos tunnetut kyselypolut toteutetaan Workerissa byte-range-lukuina?

Suositeltu lukujärjestys

1. JDBIN
2. JDBON
3. R2 + Worker Runtime
4. Vertailu muihin järjestelmiin

Turvallinen loppumuoto

Arkkitehtuurin varsinainen uutuus ei ole vain formaatti, vaan se että Cloudflare Worker toimii kyselymoottorina object storage -natiivin R2-kerroksen päällä ilman erillistä tietokantapalvelinta.