Nopeat vastaukset

Mikä tämä projekti oikeastaan on?

Todennäköinen kysymys

Mikä te oikein rakensitte?

Lyhyt vastaus

Rakensimme Cloudflareen ajetun uutis- ja briefing-järjestelmän, jossa AI auttaa valitsemaan ja muotoilemaan julkaistavaa sisältöä, mutta julkaistu data toimitetaan versionoidun JDBIN/JDBON + R2 + Worker -polun kautta.

Pidempi vastaus

Projektissa on neljä käytännön kerrosta:

• tutkimuskorpuskerros
• toimitusputki
• tallennuskerros
• jakelukerros

Tutkimuskorpus kokoaa raaka-aineiston RSS-lähteistä. Toimitusputki yrittää muodostaa siitä julkaistavia signaaleja. Tallennuskerros versioi ja julkaisee ne JDBIN/JDBON-mallilla R2:een. Jakelukerros tarjoaa snapshotit ja muut julkiset rajapinnat käyttöliittymälle.

Mitä kannattaa painottaa

• kyse ei ole vain tiedostoformaatista
• kyse on koko object storage -pohjaisesta lukuarkkitehtuurista
• AI ei ole julkisen sivun pyyntöpolussa

Mikä on varsinainen tutkimuskysymys?

Todennäköinen kysymys

Mikä tässä on tutkimusongelma?

Lyhyt vastaus

Tutkimuskysymys ei ole "voiko uusi formaatti tallentaa dataa", vaan voiko immutable object storage toimia kyseltävänä lukukerroksena ilman erillistä tietokantapalvelinta.

Pidempi vastaus

Tarkka tutkimuskysymys on tämä:

Voidaanko immutable object storage -objektista rakentaa lukupolulle optimoitu kyselykerros ilman erillistä tietokantapalvelinta käyttämällä vain byte-range-lukuja, manifest/pointer-versionointia ja Workerissa ajettavaa kyselysuunnittelijaa?

Tavoite ei ole rakentaa yleistä SQL-moottoria, vaan selvittää milloin object storage voi itse toimia kyseltävänä kerroksena lukupainotteisissa, ennalta tunnetuissa kyselypoluissa.

Mikä on tutkimusinnovaatio?

Todennäköinen kysymys

Mikä tässä on oikeasti uutta?

Lyhyt vastaus

Uutta ei ole vain JDBIN-formaatti, vaan tapa käyttää object storagea kyseltävänä kanonisena tallennuskerroksena ilman erillistä tietokantapalvelinta.

Pidempi vastaus

Kontribuutiot ovat yhdessä:

• immutable object storage -pohjainen kyseltävä artefakti
• range-read-kyselysuunnittelija tunnetuille kyselymuodoille
• manifest/pointer-versionointi ilman inplace-mutaatiota base-objektiin
• kanonisen tallennuksen ja snapshot-jakelun erottelu
• deterministinen lukupolku Workerin kautta

Mitä ei pidä väittää

• "keksimme uuden tietokannan"
• "tämä korvaa SQL:n"
• "tämä on uusi SQLite"

Mikä JDBIN on?

Todennäköinen kysymys

Mikä tämä JDBIN oikein on?

Lyhyt vastaus

JDBIN on varsinainen binäärinen tallennusartefakti, jonka yli Worker tekee deterministisiä range-read-hakuja.

Pidempi vastaus

JDBIN ei ole yleinen SQL-tietokanta eikä tietokantapalvelin. Se on lukupolulle optimoitu tallennusmoottori immutable object storagea varten. Tyypillisesti se sisältää segmentit, indeksit, string poolin sekä row payloadit tai niiden materialisoidut versiot.

Mitä kannattaa painottaa

• kanoninen binäärinen julkaisuartefakti
• Worker lukee vain tarvitut byte-alueet
• optimoitu tunnetuille query-poluille

Mikä JDBON on?

Todennäköinen kysymys

Entä JDBON, miksi sitä tarvitaan?

Lyhyt vastaus

JDBON on JSON-pohjainen ohjauskerros, joka kertoo mikä base, mikä delta chain ja mikä manifesti on aktiivinen.

Pidempi vastaus

JDBON hallinnoi:

• mikä base-objekti on aktiivinen
• mitä delta-objekteja ketjuun kuuluu
• mihin database-versioniin ketju viittaa
• mikä manifest on aktiivinen pointerin kautta

JDBIN optimoi lukemisen. JDBON optimoi julkaisemisen, versionhallinnan, rollbackin ja delta chainin ohjauksen.

Miksi kaksi kerrosta: JDBIN + JDBON?

Todennäköinen kysymys

Miksi ette laittaneet kaikkea yhteen formaattiin?

Lyhyt vastaus

Koska lukuoptimointi ja julkaisun hallinta ovat eri vastuita.

Pidempi vastaus

JDBIN on data-artefakti, jonka yli Worker tekee range-readit. JDBON taas hallinnoi base-version, aktiivisen manifestin, järjestetyn delta chainin ja pointer-pohjaisen julkaisuvaihdon. Tällä jaolla lukupolku pysyy tiiviinä, mutta publish, rollback ja retention pysyvät selkeinä.

Mikä on R2:n rooli?

Todennäköinen kysymys

Eikö R2 ole vain bucket?

Lyhyt vastaus

Tässä mallissa R2 on kanoninen immutable storage -kerros, ei vain tiedostojen säilytyspaikka.

Pidempi vastaus

R2:ssa säilytetään:

• aktiivinen base-JDBIN
• deltaobjektit
• JDBON-manifestit
• active pointer
• public snapshotit

R2:n arkkitehtuurinen rooli perustuu immutable objecteihin, byte-range-lukuihin, globaaliin saatavuuteen ja Workerin läheisyyteen tallennuskerrokseen.

Mitä Worker tekee?

Todennäköinen kysymys

Onko Worker vain API-proxy?

Lyhyt vastaus

Ei. Worker toimii suunnittelijana, range-lukijana, parserina ja vastauksen kokoajana.

Pidempi vastaus

Worker ei vain välitä pyyntöjä eteenpäin, vaan ratkaisee osan query-logiikasta itse. Lisäksi sama ympäristö voi hoitaa triggerit, snapshot-päivitykset ja publish-polut.

Miksi juuri Cloudflare?

Todennäköinen kysymys

Miksi tämä toimii juuri Cloudflaressa?

Lyhyt vastaus

Koska Cloudflare tarjoaa saman arkkitehtuurin kannalta tarvittavat primitiivit: Worker, R2, byte-range reads ja edge execution.