Vertailu muihin järjestelmiin

JDBIN ei ole "kopio" mistään yhdestä olemassa olevasta järjestelmästä. Siinä on piirteitä useista eri toteutuksista, mutta arkkitehtoninen lähtökohta on eri.

Lyhyt vastaus

JDBIN ei ole uusi Parquet eikä uusi DuckDB. Se muistuttaa niiden ideoita, kuten segmenttejä, indeksejä, immutable-rakennetta ja selektiivistä lukua, mutta yhdistää ne Cloudflare R2:n, HTTP byte-range -hakujen ja Worker-pohjaisen kyselymoottorin ympärille.

1. Parquet

Parquet on tiedostoformaatti.

CSV
  -> Parquet file
  -> Spark / DuckDB / Athena / BigQuery

Parquet sisältää esimerkiksi:

• columnar storage
• metadataa
• sivuja
• compressionia
• statistics-tietoa

Mutta se ei ole kyselymoottori. Se sanoo vain: "näin data on tallennettu".

JDBIN eroaa tästä siinä, että mukana ei ole vain formaatti vaan myös Workerissa toimiva kyselypolku.

2. Apache ORC

ORC on hyvin saman tyyppinen kuin Parquet.

Se tuo mukaan esimerkiksi:

• bloom filterit
• indeksit
• statistics-tiedon
• predicate pushdown -ajattelun

Mutta sekään ei itsessään ole kyselymoottori.

3. DuckDB storage engine

DuckDB on oikea tietokanta.

SQL
  -> DuckDB parser
  -> optimizer
  -> execution engine
  -> storage engine
  -> Parquet / disk

DuckDB sisältää:

• SQL-parserin
• optimizerin
• execution enginen
• storage enginen

JDBIN-polku näyttää enemmän tältä:

Worker
  -> planner
  -> range reader
  -> JDBIN
  -> R2

Tärkeä ero on, että JDBINissä ei ainakaan nykyrajauksen mukaan ole yleistä SQL-parseria. Dokumentaatio korostaa Workerissa toimivaa query planneria, joka tekee vain tarvittavat byte-range-haut R2:sta.

4. ClickHouse MergeTree

Tämä on yksi lähimmistä vertailukohdista.

MergeTree käyttää esimerkiksi:

• partteja
• indeksejä
• markkeja
• granuleja

jotta voidaan lukea vain pieni osa tiedostosta.

JDBINissä ajatus muistuttaa tätä:

Worker
  -> planner
  -> range read
  -> segment
  -> string pool
  -> manifest

Iso ero on, että MergeTree toimii oman levyn ja oman tietokantaprosessin päällä. JDBIN käyttää object storagea, tässä tapauksessa R2:ta.

5. SSTable

SSTable on erityisen kiinnostava vertailu.

SSTable-ajattelussa on:

• sorted key
• immutable rakenne
• indeksi
• lookup-polku

Kun kirjoitetaan uutta dataa, syntyy uusi SSTable eikä vanhaa ylikirjoiteta.

JDBINin write-path:

delta
  -> manifest
  -> active pointer
  -> new view

on samantyyppinen siinä mielessä, että uutta näkymää rakennetaan ilman vanhan datan suoraa ylikirjoitusta.

6. Lucene

Lucene ei ole tietokanta vaan hakemistomoottori.

Siinä on esimerkiksi:

• inverted index
• segmenttejä
• immutable segmenttejä

JDBIN ei ole inverted index, mutta segmenttiajattelu muistuttaa Lucenea.

Oikea arkkitehtoninen ero

Dokumentaation mukaan JDBIN-arkkitehtuuri näyttää tältä:

Client
  -> Cloudflare Worker
  -> query planner
  -> range reader
  -> R2 object
  -> JDBIN

Worker hakee vain tarvittavat tavualueet R2:sta ilman erillistä tietokantapalvelinta.

Useimmat perinteisemmät järjestelmät taas toimivat enemmän näin:

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

Eli tietokantaprosessi omistaa levyn ja kyselymoottorin.

Tässä mallissa taas:

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

Tämä on arkkitehtonisesti eri lähtökohta.

Yhteenveto

Turvallinen loppumuoto

JDBIN ei ole uusi Parquet eikä uusi DuckDB. Se yhdistää segmentti-, indeksi- ja immutable-ideoita object storage -natiiviin malliin, jossa Cloudflare Worker toimii kyselymoottorina ja R2 toimii kanonisena tallennuskerroksena.