Penyimpanan SQLite berlatensi nol di setiap Durable Object

 (simonwillison.net)
2 poin oleh GN⁺ 2024-10-15 | 1 komentar | Bagikan ke WhatsApp

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda memperkenalkan versi berikutnya dari platform Durable Object milik Cloudflare. Platform ini baru-baru ini ditingkatkan dari penyimpanan key/value menjadi sistem relasional penuh berbasis SQLite
    • Untuk latar belakang yang berguna tentang versi pertama Durable Objects, lihat Cloudflare’s durable multiplayer moat karya Paul Butler. Ini populer untuk membangun aplikasi kolaborasi real-time berbasis WebSocket
    • Durable Objects baru berbasis SQLite menghadirkan aspek menarik dari desain sistem terdistribusi yang mengusulkan cara menarik untuk merancang aplikasi berskala besar

  • Ide inti Durable Objects

    • Durable Object menempatkan logika aplikasi bersama datanya pada host fisik yang sama sehingga memberikan performa baca dan tulis yang sangat cepat
    • Satu objek berjalan pada satu thread di satu mesin, sehingga throughput-nya terbatas. Untuk menangani trafik yang lebih besar, dibuat lebih banyak objek. Ini paling mudah ketika tiap unit status memiliki trafik yang cukup rendah sehingga bisa ditangani oleh satu objek tunggal

  • Contoh sistem reservasi penerbangan

    • Setiap penerbangan dapat dipetakan ke Durable Object khusus dengan database SQLite miliknya sendiri. Ribuan database baru dibuat setiap hari untuk tiap maskapai
    • Setiap DO memiliki nama unik, dan jaringan Cloudflare merutekan permintaan ke objek tersebut di mana pun lokasinya di seluruh dunia

  • Detail teknis

    • Terinspirasi oleh Litestream, setiap DO terus-menerus melakukan streaming urutan entri WAL ke object storage. Ini dibatch setiap 16MB atau setiap 10 detik
    • Untuk menjamin durabilitas dalam jendela 10 detik, write diteruskan ke lima replika di data center terdekat segera setelah commit, dan write diakui setelah tiga replika memberikan konfirmasi

  • Desain API JavaScript

    • Dirancang dengan pola blocking, bukan asynchronous. Tujuannya adalah untuk menyediakan operasi persistensi single-thread yang cepat
    • Termasuk contoh yang dengan sengaja menampilkan pola kueri N+1 yang dapat ditangani dengan baik oleh SQLite

  • Storage Relay Service

    • Ini adalah sistem dasar di balik Durable Objects, dan telah mendukung sistem D1 SQLite milik Cloudflare selama lebih dari satu tahun

  • Lokasi pembuatan Durable Objects

    • Setelah dibuat, Durable Objects tidak berpindah lokasi. Secara default, objek diinstansiasi di data center tempat permintaan get() pertama dilakukan
    • Untuk membuat Durable Objects secara manual di lokasi lain, berikan parameter opsional locationHint pada get()

  • Situs where.durableobjects.live

    • Situs ini melacak lokasi pembuatan DO di jaringan Cloudflare

Ringkasan GN⁺

  • Durable Objects milik Cloudflare berbasis SQLite dan membuka kemungkinan baru untuk merancang aplikasi berskala besar. Ini memberikan performa cepat dengan menempatkan data dan logika aplikasi pada host fisik yang sama
  • Sistem ini sangat berguna khususnya untuk aplikasi kolaborasi real-time, serta menawarkan fleksibilitas untuk menangani berbagai unit status
  • Durable Objects membuat replika di beberapa data center untuk menjamin durabilitas data, sehingga meningkatkan stabilitas dan keandalan
  • Teknologi ini dapat menarik bagi pengembang yang tertarik pada desain sistem terdistribusi berskala besar. Sistem dengan fungsi serupa antara lain Amazon’s DynamoDB dan Google’s Firestore

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-15
Komentar Hacker News

  • API penulisan bersifat sinkron, tetapi ada mekanisme tunggu asinkron tersembunyi. Jika penulisan gagal, runtime akan mengganti respons menjadi kegagalan HTTP sehingga penulisan bisa dibatch secara otomatis dan keberhasilannya dapat diasumsikan

    • Tidak ada transaksi baca, sehingga sulit mendapatkan snapshot pada titik waktu tertentu
    • Setiap instance runtime dibatasi hingga 128MB RAM
    • WebSocket dapat dihibernasi, dan dalam keadaan ini tidak menimbulkan biaya. Ini memungkinkan klien tetap mempertahankan koneksi saat DO sedang tidur
    • Ada fitur RPC otomatis sehingga dapat berkomunikasi dengan DO atau worker lain seperti pemanggilan JS biasa. Runtime menangani serialisasi dan parsing

  • Setiap DO melakukan streaming urutan entri WAL ke object storage, yang dibatch setiap 16MB atau setiap 10 detik

    • Secara global, penulisan dapat memerlukan hingga 10 detik untuk bisa dibaca
    • Sulit menggantikan klaster database yang ditempatkan secara regional

  • Menyukai desain Durable Object. Cara kerja internalnya mudah dipahami

    • DO bagus untuk membangun pengalaman real-time yang cepat dan berbiaya rendah, tetapi sulit untuk analitik dan pembuatan ikhtisar
    • Jika data dimasukkan ke SQLite, harus melakukan kueri ke banyak instance SQLite kecil lalu menggabungkan hasilnya

  • Sulit memahami lokasi fisik Durable Objects berada

    • Penasaran apakah lokasinya mengikuti wilayah tempat panggilan API terjadi
    • Penasaran apakah DO bisa otomatis berpindah ke lokasi lain

  • Sulit memahami teknologi cloud baru

    • Memiliki pengalaman pengembangan web lebih dari 15 tahun, tetapi merasa teknologi seperti ini tidak cocok untuk dirinya

  • Penasaran bagaimana migrasi skema akan ditangani

    • Jika database ada per tenant, akan sulit menerapkan perubahan skema ke setiap DO

  • Desain DO menarik, tetapi terasa hanya cocok untuk sistem berbeban tinggi atau proyek main-main

    • Dalam praktik kerja, dibutuhkan sistem yang sudah terbukti, dan DO masih belum matang

  • Terkesan dengan desain DO. Menganggap cara ini menangani pekerjaan kompleks dalam skala kecil mirip dengan struktur produk nyata

  • Mencermati bahwa CF mendorong developer untuk menggunakan DO

    • Koneksi WebSocket pada worker akan timeout setelah 30 detik, dan penggunaan DO direkomendasikan

  • Penasaran apakah DO setara dengan "model" dalam arsitektur MVC

    • Penasaran tentang penggunaan DO per tenant, serta cara melakukan kueri atau join ke semua DO