Mengapa Basis Data dan Kompleksitasnya Kini Tidak Lagi Diperlukan

 (blog.redplanetlabs.com)
2 poin oleh GN⁺ 2024-01-11 | 1 komentar | Bagikan ke WhatsApp
  • Penyebab kompleksitas backend bukan terutama cacat produk tertentu, melainkan struktur konseptual yang telah lama dipertahankan basis data terus membatasi desain aplikasi
  • Basis data bertindak seperti status global yang dapat berubah, dan membuat pengembang harus menanggung model data yang kaku, skema yang terbatas, serta ketegangan antara normalisasi dan denormalisasi
  • Alternatif yang diajukan adalah menggabungkan event sourcing dan materialized views untuk memisahkan data sumber dan view indeks, serta memperlakukan indeks sebagai struktur data tahan lama alih-alih model data
  • Rama dari Red Planet Labs menyatukan pengumpulan, pemrosesan, pengindeksan, kueri, deployment, dan pemantauan data dalam satu platform melalui depots, ETL, PStates, dan query topologies
  • Dalam contoh reimplementasi Mastodon pada skala Twitter, Rama disebut selesai dengan 10k baris kode dan 9 orang-bulan, dibandingkan produk konsumen Twitter yang setara dengan 1M baris kode dan sekitar 200 orang-tahun

Titik awal kompleksitas basis data

  • Fokus masalahnya bukan pada API, kesulitan operasional, atau batasan sewenang-wenang dari produk basis data tertentu, melainkan pada struktur konsep kolektif yang masih dipertahankan hingga sekarang
  • Masalah pendekatan lama baru tampak jelas ketika muncul cara yang lebih baik, dan sebagai alternatif diajukan gabungan event sourcing dan materialized views

Basis data sebagai status global yang dapat berubah

  • Programmer diajarkan untuk meminimalkan penggunaan variabel global, tetapi pada dasarnya basis data juga merupakan status global yang dapat berubah
  • Basis data dalam beberapa hal bahkan lebih sulit ditangani daripada variabel global biasa
    • interaksi tersebar di banyak sistem sehingga penalaran terhadap status menjadi sulit
    • status memiliki daya tahan, sehingga meski bug diperbaiki data yang rusak tidak otomatis pulih
    • dalam beberapa kasus sulit mengetahui secara tepat cakupan kerusakan atau memperbaikinya secara sempurna
    • mengembalikan dari backup atau menggabungkan sebagian backup bukan solusi terbaik
  • Dengan event sourcing dan materialized views, view dapat dihitung ulang dari log sumber sehingga ada peluang untuk memperbaiki status indeks yang rusak

Batas model data yang kaku

  • Basis data dirancang berpusat pada model data seperti key/value, document, relational, column-oriented, dan graph
  • Karena satu model data sulit mendukung semua kasus penggunaan, perusahaan sering memakai beberapa basis data sekaligus
  • Abstraksi indeks yang lebih umum bukanlah model data, melainkan struktur data
    • Key/value: map
    • Document: map of maps
    • Relational: map of maps, secondary indexes adalah map tambahan
    • Column-oriented: map of sorted maps
  • Struktur data tahan lama disimpan di disk sehingga bisa sangat besar, dan juga dapat merepresentasikan struktur data bertingkat
  • Jika indeks ditentukan sebagai kombinasi struktur data, kita bisa membuat bukan hanya model data yang sudah ada tetapi juga bentuk indeks yang jauh lebih beragam
  • Jika bentuk penyimpanan dapat disesuaikan dengan model domain alih-alih memelintir model domain aplikasi agar cocok dengan basis data, kompleksitas dasarnya berkurang

Ketegangan antara normalisasi dan denormalisasi

  • Pengguna basis data relasional pada akhirnya akan menghadapi pilihan antara normalisasi dan denormalisasi
  • Penyimpanan yang dinormalisasi menciptakan sumber kebenaran yang jelas dan mengurangi kemungkinan inkonsistensi, tetapi join bertambah dan biaya kueri bisa meningkat
  • Jika demi performa informasi yang sama disimpan dengan beberapa cara, bug dapat memunculkan inkonsistensi data
  • Arsitektur RDBMS menyatukan sumber kebenaran dan penyimpanan indeks untuk kueri cepat dalam datastore yang sama
  • Solusinya adalah arsitektur yang memisahkan dua peran tersebut
    • satu subsistem merepresentasikan sumber kebenaran
    • subsistem lain mematerialisasikan sejumlah penyimpanan indeks yang diinginkan dari sumber tersebut
    • jika sistem kedua dapat menghitung ulang indeks dari data sumber, inkonsistensi bisa dikoreksi

Skema yang terbatas dan representasi domain

  • Jenis nilai yang dapat disimpan basis data sangat berbeda-beda tergantung produknya
    • ada basis data yang hanya mengizinkan blob seperti byte array
    • ada yang mengizinkan banyak tipe seperti integer, floating point, string, dan tanggal
  • Jarang ada yang menyimpan informasi bertingkat di dalam objek domain sebagai representasi kelas satu sehingga bisa langsung dikueri atau diagregasi
  • Bahasa implementasi basis data dan bahasa aplikasi sering berbeda sehingga interoperabilitas sulit, dan ekstensi seperti protobuf extension untuk Postgres pun merepotkan dan terbatas
  • ORM memetakan representasi domain ke representasi basis data, tetapi abstraksinya bisa bocor dan menimbulkan masalah
  • Jika data perlu diindeks dengan cara yang berbeda dari representasi domain yang ideal, diperlukan kode adaptor dan kueri yang bisa dijalankan secara efisien pun dapat menjadi terbatas

Deployment yang rumit dan model à la carte

  • Backend yang lengkap tidak hanya terdiri dari basis data, tetapi memerlukan banyak alat seperti basis data, sistem pemrosesan, alat pemantauan, scheduler, dan lainnya
  • Backend berskala besar bisa memerlukan kombinasi puluhan alat, dan pembaruan aplikasi berkembang menjadi orkestrasi migrasi, pembaruan kode, dan perubahan infrastruktur
  • Kesiapan produksi memerlukan telemetri yang memadai, tetapi karena tiap alat punya cara pengumpulan berbeda, menggabungkannya ke satu dashboard pemantauan juga menjadi tugas rekayasa tersendiri
  • Cara pengembangan yang dominan saat ini mendekati model à la carte, yaitu memilih alat terbaik untuk tiap bagian arsitektur lalu merangkainya
  • Pekerjaan membuat alat-alat yang dirancang secara independen itu bisa berjalan bersama sudah sangat besar, dan karena model data yang kaku serta skema yang terbatas, aplikasi sering dipaksa menyesuaikan diri dengan alat, bukan sebaliknya
  • Karena belum ada model terpadu untuk menyusun backend, model à la carte menjadi dominan; dalam model yang terpadu, peluang abstraksi, otomasi, dan penggunaan ulang jauh lebih besar

Model sederhana untuk melihat backend

  • Fungsi utama backend adalah menerima data baru dan menjawab pertanyaan tentang data tersebut
  • Kueri yang paling umum dapat diekspresikan sebagai menjalankan sebuah fungsi atas seluruh data yang diterima backend
    • query = function(all data)
  • Dalam kenyataan, dataset bisa berukuran 10PB dan jawaban kueri harus keluar dalam hitungan milidetik, sehingga sistem praktis memerlukan indeks
  • Model dengan indeks tambahan dapat dinyatakan seperti berikut
    • indexes = function(data)
    • query = function(indexes)
  • Backend konvensional mengimplementasikan komponen model ini lewat banyak alat sempit yang terpisah
    • backend RDBMS memakai RDBMS untuk data dan indeks, lalu bisa menambah basis data terpisah seperti ElasticSearch untuk pengindeksan tambahan
    • komputasi sering dilakukan di handler server API atau pekerjaan latar belakang berbasis queue dan worker
    • backend skala besar dapat menggabungkan alat seperti Cassandra, MongoDB, Neo4j, Kafka, Hadoop, Storm, dan Kafka Streams
  • Kesimpulannya, jika ada alat yang mengimplementasikan semua komponen ini secara terpadu dan serbaguna, kompleksitas tadi dapat dihindari

Komponen Rama dan contoh Mastodon

  • Rama adalah platform pengembangan backend yang dirancang berdasarkan prinsip-prinsip tersebut
  • Red Planet Labs mengumumkan Rama pada 15 Agustus dengan tagline “the 100x development platform”
  • Sebagai contoh penghematan biaya, mereka menampilkan pekerjaan mereimplementasikan Mastodon pada skala Twitter
    • 100M bot melakukan posting 3.500 kali per detik
    • fanout rata-rata adalah 403
    • produk konsumen Twitter yang setara dibandingkan memiliki 1M baris kode dan memerlukan sekitar 200 orang-tahun
    • implementasi Rama memerlukan 10k baris kode dan 9 orang-bulan
    • implementasinya open-source dan diklaim complete, high-performance, production-ready
  • Twitter, untuk mencapai skala itu, disebut membangun sendiri basis data khusus seperti social graph database dan in-memory timeline database, serta memiliki deployment rumit dengan konfigurasi Puppet saja lebih dari 1M baris
  • Implementasi berbasis Rama dikatakan menyelesaikan masalah performa dan skalabilitas serupa dengan menggabungkan elemen-elemen primitif Rama, alih-alih membangun infrastruktur khusus baru untuk tiap submasalah
  • Performance numbers dari implementasi Mastodon itu disebut setara atau lebih baik daripada angka Twitter

Model pemrograman Rama

  • Konsep Rama berkorespondensi langsung dengan model backend yang dijelaskan sebelumnya
    • Depots: log terdistribusi yang menampung data arbitrer, setara dengan data
    • PStates: singkatan dari partitioned state, setara dengan indeks
    • ETLs: setara dengan function(data)
    • Queries: setara dengan function(indexes)
  • PStates dapat dibuat sebanyak yang diperlukan sebagai kombinasi arbitrer dari struktur data tahan lama
  • ETL dan query diekspresikan dengan API dataflow yang Turing-complete, dan komputasinya dapat dijalankan secara terdistribusi
  • Rama menyediakan tutorial API Java dalam dokumentasi, dan juga memiliki Clojure API

Cara Rama mengurangi kompleksitas basis data

  • PStates pada Rama berperan mirip basis data, tetapi hanya bisa ditulis dari ETL topology yang memiliki PState tersebut
    • karena semua penulisan berada pada kode ETL yang sama, penalaran terhadap status menjadi lebih mudah
    • PStates berfungsi sebagai materialized view di atas log event sourcing
    • karena data depot adalah sumber kebenaran, PState dapat dihitung ulang
  • Batasan model data ditangani dengan cara menentukan PStates sebagai struktur data
    • implementasi Mastodon memakai 33 PStates hanya untuk profiles, statuses, dan timelines
    • ada PState yang menangani 10 kasus penggunaan, dan ada pula yang hanya mendukung satu kasus penggunaan
  • PStates memiliki sifat durable, partitioned, dan incrementally replicated
    • incremental replication berarti saat leader partition gagal, ada partition lain yang siap mengambil alih
    • apa yang terlihat pada leader saat ini dijamin juga terlihat pada leader berikutnya
  • Masalah normalisasi dan denormalisasi ditangani dengan pemisahan eksplisit antara depots dan PStates
  • Masalah skema yang terbatas diringankan dengan memakai representasi domain apa adanya
    • struktur data umum seperti hash map dan list
    • Protocol Buffers
    • definisi objek bertingkat
    • tipe yang tidak dikenali Rama ditangani dengan mendaftarkan custom serializer

Deployment, integrasi, dan pemantauan

  • Aplikasi Rama disebut modules, dan sebuah module dapat mencakup beberapa depots, ETLs, PStates, dan query topologies
  • Rama menyediakan mekanisme bawaan untuk deployment, pembaruan, dan scaling module, dan masing-masing disebut dapat dijalankan dengan one-liner di terminal
  • Rama bukan alat “all or nothing”, tetapi dirancang agar mudah terintegrasi dengan sistem lain sehingga bisa diadopsi secara bertahap ke arsitektur yang sudah ada
  • Karena merupakan platform terintegrasi, Rama juga melakukan pemantauan sendiri
    • pengumpulan data pemantauan
    • pemrosesan
    • pengindeksan
    • visualisasi
  • Cluster UI telemetry digunakan untuk memahami performa module, mendeteksi dan mendiagnosis masalah, serta menentukan kapan perlu melakukan scaling

Jalur belajar dan adopsi

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-11
Komentar Hacker News

  • “Seperti akan dijelaskan nanti, pendekatan yang lebih baik adalah event sourcing dan materialized view”—jadi pada akhirnya solusinya adalah menambah kompleksitas? Ya, tentu saja begitu

    • Jika dilakukan dengan benar, justru arsitektur backend menjadi jauh lebih sederhana. Aplikasi berskala kecil pun biasanya memakai beberapa database seperti Postgres dan ElasticSearch, serta memiliki antrean dan worker untuk pekerjaan latar belakang
      Implementasi Mastodon berskala Twitter yang kami buat adalah contoh langsung. Untuk membuat fungsi yang sama dalam skala besar, kodenya secara harfiah 100 kali lebih sedikit daripada kode yang harus ditulis Twitter, dan juga lebih dari 40% lebih sedikit daripada implementasi resmi Mastodon. Bukan karena ini kedua kalinya kami memakai alat yang sama sehingga desainnya lebih baik, melainkan karena dibuat dengan abstraksi yang secara fundamental lebih baik
    • Kompleksitas tidak hilang, hanya berpindah ke tempat lain. Untuk banyak pekerjaan, trade-off solusi ini bisa buruk
      Namun setelah melewati skala tertentu, semuanya menjadi masalah data engineering, dan dalam konteks keseluruhan sistem, cara ini kadang menjadi solusi yang relatif sederhana. Nasihat “pakai saja mySQL/SQLite/Postgres” bagus hanya sampai tiba saat ketika nasihat itu tidak lagi berlaku
    • Katanya kompleksitas makin bertambah? Penulis membuatnya sangat sederhana. Cukup pakai produk mereka, Rama
    • Di semua perusahaan tempat saya pernah bekerja, event sourcing + materialized view berujung pada kekacauan ekstrem, lebih banyak bug, dan insiden yang lebih lama. Solusi yang lebih sederhana seperti MySQL, PostGres, atau Redis/DynamoDB semuanya bekerja lebih baik
      Saya sungguh percaya akan lebih baik bagi semua orang jika tulisan awal Martin Fowler tentang event sourcing tidak pernah ditulis. Menurut saya, dalam 99% kasus itu ide yang buruk
    • Jika domain program membutuhkan kompleksitas inheren X, bagaimanapun kompleksitas itu harus diimplementasikan. Anda bisa menyerahkannya pada kode orang lain yang sudah ditulis dan teruji di lapangan, atau membuatnya sendiri dari awal; opsi terakhir memakan banyak waktu dan hasilnya bisa lebih buruk. Tidak ada makan siang gratis

  • Entah saya yang melewatkannya, tetapi tulisan ini tampaknya sama sekali menghilangkan konsep seperti concurrency, isolation, constraints. Dan yang disebut “query topology” itu sepertinya tidak deklaratif, serta melempar tanggung jawab perencanaan/optimisasi kueri kepada penulisnya. Apakah ini benar-benar dianggap sebagai pengalaman developer yang lebih baik?

    • Hal-hal seperti ini dibahas cukup lengkap dalam dokumentasi. Tulisan ini membahas kompleksitas pengembangan backend dan bagaimana Rama menanganinya, bukan menjelaskan semua aspek Rama secara tuntas. Kalau semuanya dijelaskan, tulisannya akan terlalu panjang. Jika menggali Rama lebih jauh, Anda akan melihat bahwa properti dan jaminannya sangat kuat
      Dan benar, cara kueri Rama adalah pendekatan yang jauh lebih unggul. Kebutuhan akan query planner yang kompleks biasanya muncul dari keterbatasan cara pengindeksan data, terutama ketegangan antara normalisasi dan denormalisasi. Di Rama, mudah untuk mewujudkan berbagai view secara kokoh dalam bentuk yang sudah siap untuk kebutuhan kueri
      Tutorial yang memperkenalkan konsep Rama secara bertahap ada di sini: https://redplanetlabs.com/docs/~/tutorial1.html

  • Mengenai pernyataan “tidak ada satu model data pun yang bisa mendukung semua use case”, secara teoretis tidak ada domain atau himpunan domain berhingga yang tidak bisa dimodelkan secara tepat sebagai tuple dan relasi antarobjek
    Dalam praktik, cakupan database/skema tertentu biasanya dibatasi pada satu bisnis atau area masalah, tetapi selama tipe-tipe tidak saling tumpang tindih secara tidak tepat, ini juga bukan masalah besar. Asal berhati-hati dengan penamaan, memasukkan peritel web dan perusahaan asuransi ke skema yang sama pun bisa berjalan dengan cukup baik
    Memasukkan semuanya secara tepat ke dalam satu database adalah kekuatan super. Alasan terbesar saya menegaskan hal ini adalah untuk menghindari transaksi terdistribusi di beberapa penyimpanan data. Jika semua bisnis terjadi di dalam satu sistem transaksi, semantiknya menjadi jauh lebih sederhana

    • Saya sangat setuju khususnya dengan pernyataan “memasukkan semuanya ke dalam satu database adalah kekuatan super”
      Begitu orang benar-benar mulai memakai data, server DB besar seharga 1 juta dolar jauh lebih murah daripada susunan database murah yang redundan. Baik developer, analis, maupun manajemen semuanya menghemat waktu, mungkin hanya sebagian DBA yang menjadi pengecualian
    • Database besar bukan hal baru. Kalau hanya itu persoalannya, orang-orang pasti sudah terus melakukannya selama 40 tahun terakhir. Namun itu tidak selalu berhasil, dan kadang sering kali berakhir mengerikan
      Sekalipun secara teoretis hanya itu yang diperlukan, masalah lain yang terus ada adalah implementasi. Saat ini kebanyakan developer tidak memahami dengan baik bagaimana database bekerja dan bagaimana seharusnya digunakan, sehingga mereka menggunakannya dengan buruk. Karena itu, untuk menghindari kenyataan ini, mereka membuat database baru seperti NoSQL, mencoba lebih sedikit berpikir dan lebih banyak menulis kode perekat. Itu pun terbukti menghasilkan hasil yang mengerikan
      Tidak lama lagi arus akan berbalik lagi, dan “cukup satu database besar” kembali tidak populer, lalu paradigma “kesederhanaan” lain akan muncul. Seperti pada masa microservices, alih-alih “satu database besar”, “banyak database kecil” bisa dianggap sederhana. Jika tidak memahami sejarah, kita pasti akan mengulanginya
    • Mengatakan bahwa suatu use case bisa dimodelkan dengan tuple dan relasi bukan berarti database dapat memenuhi kebutuhan performa use case tersebut. Jika kebutuhan performanya tidak terpenuhi, berarti use case itu tidak didukung
      Ini sama seperti dalam pemrograman umum: satu struktur data atau kombinasi struktur data tidak bisa mendukung semua use case. Kadang kita butuh map, kadang list, set, kombinasi, atau sesuatu yang sama sekali berbeda
    • Saya setuju bahwa “memasukkan semuanya ke dalam satu database adalah kekuatan super”. Perusahaan saya sebelumnya memakai konfigurasi microservices bergaya cargo cult dengan DB terpisah untuk setiap aplikasi, yang menjadi rumit dan mahal tanpa manfaat bisnis. Memang mungkin ada manfaat untuk mempercantik CV. Jangan membuatnya rumit sampai memang terpaksa diperlukan
    • Ini ide yang seperti mimpi dan benar-benar indah, tetapi pada praktiknya tidak berjalan. Apakah ada orang yang berhasil? Jika dibawa ke ekstrem, ini berarti seluruh dunia membutuhkan satu database terpadu dan satu sistem hak akses pengguna
      Tentu saja struktur data itu beragam, performa juga dibutuhkan, dan karena terlalu penting, ia bisa menjadi bottleneck yang tidak boleh disentuh orang biasa, sementara setiap perubahan harus sangat aman. Ada juga keamanan. Bagaimana jika seseorang menemukan cara berpindah dari bagian bug pengembangan ke bagian HR atau keuangan khusus eksekutif? Siapa pun yang pernah mengimplementasikan sistem ERM serbaguna akan tahu betapa sulit dan menyakitkannya sistem terpadu
      Namun ini memang kasus ekstrem. Saya penasaran sejauh mana orang-orang telah melangkah dalam mengejar ideal ini dan bagaimana mereka melakukannya. Saya belum pernah melihat bisnis yang dijalankan dengan satu sistem. Bagaimana dengan sistem manajemen pengetahuan pribadi? Apakah semuanya cocok? Bukankah untuk pekerjaan cepat kita masih memakai spreadsheet, dan untuk format bebas masih memakai file teks?

  • Ini terlihat seperti kumpulan buzzword. Saya telah menangani database selama bertahun-tahun di salah satu perusahaan terbesar di dunia, tetapi belum pernah mendengar istilah topologi
    Kalaupun ada waktu yang bisa dihemat dengan ini, waktu itu akan habis untuk mempelajari Java dan framework ini. Database itu sendiri tidak bermasalah

    • Ada implementasi Mastodon yang siap produksi untuk membuat fungsi setara pada skala Twitter dengan kode 100 kali lebih sedikit daripada kode yang ditulis Twitter, jadi sulit bagi saya untuk setuju dengan penilaian “kumpulan buzzword”: https://github.com/redplanetlabs/twitter-scale-mastodon
    • Bagi saya ini terlihat seperti salah satu contoh iklan semacam ini
      Saya mencoba membuat tabel teks di sini, tetapi tampilan halaman benar-benar rusak, jadi saya mengunggahnya sebagai tangkapan layar: https://imgur.com/a/XtwSkyx

  • Kalau menjelaskan Rama seolah-olah kepada anak berusia lima tahun, itu apa? Dokumentasinya juga membingungkan: https://redplanetlabs.com/docs/~/index.html
    Saya harap tanpa buzzword seperti “pergeseran paradigma” atau “platform”. Kalau memang perlu diagram, saya ingin membaca tulisan yang menjelaskannya dengan lebih jelas

    • Ini adalah platform pengembangan backend yang dapat menangani kebutuhan pengumpulan, pemrosesan, pengindeksan, dan kueri data aplikasi pada skala apa pun. Alih-alih menyusun backend dengan mencampur beberapa database, sistem pemrosesan, queue, dan scheduler, semuanya bisa dilakukan di dalam satu platform bernama Rama
      Rama berjalan sebagai cluster, dan beberapa aplikasi dideploy ke cluster itu dalam bentuk “modul”. Telemetri jarak jauh yang mendalam dan terperinci juga sudah bawaan
      Model pemrograman Rama adalah event sourcing dan materialized view. Saat membuat aplikasi Rama, Anda mematerialisasikan indeks sebanyak yang dibutuhkan, dalam bentuk apa pun yang diinginkan, sebagai kombinasi berbagai struktur data persisten. Indeks dimaterialisasikan dengan API aliran data terdistribusi
      Rama begitu berbeda dari hal-hal yang sudah ada sehingga kira-kira hanya sampai di sini penjelasan tingkat tinggi yang bisa saya berikan. Materi terbaik untuk mempelajari dasarnya adalah rama-demo-gallery, yang berisi contoh-contoh singkat, berjalan sampai akhir, dengan komentar terperinci, yang menerapkan Rama ke berbagai use case. Semuanya dapat diskalakan dan toleran terhadap kegagalan: https://github.com/redplanetlabs/rama-demo-gallery
    • Dari yang saya baca, ini adalah arsitektur Kappa, yaitu varian dari event sourcing
      Ada event log append-only bernama “Depot”, lalu di atasnya dibuat view arbitrer yang disebut “P-States”. Perangkat lunak Rama menjanjikan update berlatensi rendah untuk view-view ini. Aplikasi yang dibangun di atasnya melakukan kueri ke view dan mengirim event/perintah baru ke Depot
    • Kelihatannya seperti database event sourcing. Pada dasarnya, alih-alih menulis langsung, Anda menulis pesan, lalu bisa membuat tabel read-only yang diperbarui berdasarkan pesan tersebut. Di domain tertentu ini memang masih dilakukan, tetapi jelas lebih rumit daripada database tradisional
    • Terlihat seperti upaya NoSQL lainnya. “Tapi kali ini berbeda!”

  • Saya pernah mengerjakan proyek setahun untuk membuat mesin materialized view yang fleksibel di atas dataset event live berukuran 1–10 TB, dan sebelum pindah ke proyek lain arsitektur kami juga kurang lebih mulai mengerucut ke ide mengirim kode ke tempat indeks berada
    Saya cukup tertarik pada Rama, tetapi karena alasan yang sepenuhnya tidak rasional, sepertinya saya tidak akan mengadopsinya karena JVM. Saya memang tidak suka Java/JVM. Saya berharap arsitektur ini bisa di-port ke lingkungan lain

  • Di tempat kerja, kami memisahkan model baca dan model tulis. Model tulis, yaitu sumber kebenaran, adalah model domain relasional tradisional dengan invariant/constraint, dan menurut saya tidak sulit dinalar bagi sebagian besar developer yang terbiasa dengan ORM
    Hampir semua perintah juga membuat event dan menerbitkannya ke queue event domain bersama. Model baca dibuat oleh worker yang mengonsumsi event, masing-masing membuat view sesuai kebutuhan mereka, dan bisa dibuat ulang. Misalnya, layanan manajemen pengguna adalah sumber kebenaran, sementara layanan lain adalah layanan view untuk menampilkan UI yang kompleks, yang membangun model baca/indeksnya sendiri berdasarkan event dari layanan pengguna dan layanan lainnya. Tanpa ini, akan diperlukan join yang sangat besar atau panggilan API antar-layanan yang lambat
    Secara teknis, replay event bisa dilakukan. Bahkan kami pernah memutar ulang semua event selama 3 tahun terakhir karena bug di kode platform. Namun menurut saya hampir tidak pernah benar-benar diperlukan. Kadang view perlu dibuat ulang karena bug, tetapi biasanya ditangani dengan cara program sementara seperti skrip khusus atau migrasi SQL. Saya tidak tahu persis apa nama arsitektur kami, dan saya belum pernah mendengar siapa pun menyebutnya “event sourcing”
    Pada akhirnya ini hanyalah MySQL lama + RabbitMQ dan sedikit kode perekat. Namun jika ingin melakukannya dengan benar, ini tidak sepenuhnya sepele karena transactional outbox, jaminan pengiriman setidaknya sekali, eventual consistency, menjaga urutan pemrosesan event yang benar, batching data event, pengelolaan DB, penanganan saat event handler mati, dan sebagainya. Karena ini sudah teruji di produksi, tidak bergantung bahasa, dan kami punya producer/consumer PHP maupun Go, saya penasaran apa yang kami lewatkan tanpa Rama, dan bagaimana Rama menyelesaikan masalah-masalah dalam daftar di atas. Rama terlihat lebih diarahkan ke ekosistem Java

    • Sepertinya Anda telah merekayasa cara yang bagus untuk mengelola kompleksitas sambil memakai RDBMS. Ada beberapa hal yang Rama berikan di atas itu
      Indeks Rama jauh lebih fleksibel. Misalnya, jika Anda membutuhkan nested set dengan 100 juta elemen, itu hal sepele. Contoh umum adalah indeks social graph seperti ID pengguna → himpunan ID follower. Indeks time-series yang dipecah berdasarkan granularitas, yaitu entitas → granularitas → bucket waktu → statistik, juga sama mudahnya
      Tidak ada batasan pada tipe data yang disimpan di Rama. Kueri Rama sangat kuat, dan kueri terdistribusi real-time on-demand di sebagian atau seluruh indeks mudah dilakukan. Telemetri yang mendalam dan terperinci di seluruh aplikasi juga sudah bawaan, sehingga tidak perlu dibuat atau dikelola terpisah
      Deployment juga bawaan. Dalam pendekatan saat ini, update aplikasi bisa melintasi beberapa sistem seperti kode worker dan migrasi skema, dan ini menjadi pekerjaan engineering yang cukup sulit, terutama jika menginginkan tanpa downtime. Karena Rama mengintegrasikan komputasi dan penyimpanan secara end-to-end, rilis, update, dan scaling aplikasi semuanya bisa dilakukan dengan satu baris di terminal
      Rama jauh lebih scalable. Ini Rama dilihat dari perspektif fitur, dan sulit mengungkapkan dengan kata-kata seberapa besar perbedaan yang muncul saat coding dengan Rama tanpa impedance mismatch; Anda perlu mencobanya untuk tahu. Rama dibuat untuk JVM, jadi bisa dipakai dengan bahasa JVM apa pun, dan saat ini menyediakan API Java dan Clojure
    • Untuk perintah seperti “update alamat pelanggan”, apakah setelah SQL dijalankan trigger RDBMS mengirim event ke RabbitMQ, atau ORM yang mengirim SQL lalu memublikasikannya ke RabbitMQ?
      Event disimpan di mana dan dalam format apa? Saya ingin mendengar lebih detail
      Sepertinya yang kurang sekarang hanyalah nama keren untuk ditempelkan ke seluruh ekosistem ini

  • Mewujudkan data pada saat perubahan bisa menguntungkan ketika produk perlu melakukan satu hal dengan sangat cepat. Namun, ini menjadi merepotkan begitu muncul transaksi kompleks yang harus diperbarui bersama lewat penulisan atomik, atau saat ingin menambahkan fitur baru yang perlu menata data dengan cara berbeda
    Saya juga sangat tidak puas dengan cara bagian pembangunan aplikasi melewatkannya begitu saja seolah-olah “tinggal menambahkan satu indeks”. Indeks adalah state global; hanya saja dipindahkan satu lapisan ke bawah

    • Karena “hanya dipindahkan satu lapisan ke bawah”, poin pentingnya adalah kita tidak perlu lagi mengelolanya secara langsung. Yang perlu dilakukan hanyalah memberi tahu sistem apa yang harus diindeks. Itu bukan state atau data, melainkan kode

  • Bahkan setelah membaca dokumen ini, tidak jelas siapa audiens sasarannya dan masalah apa yang ingin diselesaikan: https://redplanetlabs.com/docs/~/why-use-rama.html#gsc.tab=0
    Akan membantu jika ada satu contoh nyata, lalu ditunjukkan bagaimana mengubahnya dengan RAMA dan seberapa mudah serta efisien hasilnya

    • Kami sudah memublikasikan banyak contoh
      Yang pertama adalah implementasi Mastodon berskala Twitter, dengan jumlah kode 100 kali lebih sedikit daripada kode yang ditulis Twitter untuk membuat hal yang sama dalam skala besar. Itu hanya berdasarkan produk konsumen. Kodenya juga lebih dari 40% lebih sedikit daripada implementasi resmi Mastodon yang tidak skalabel: https://github.com/redplanetlabs/twitter-scale-mastodon
      Repositori rama-demo-gallery juga memiliki banyak contoh singkat, mandiri, dan diberi komentar rinci yang menerapkan Rama pada kasus penggunaan yang sangat berbeda. Termasuk pengelolaan profil pengguna, analitik deret waktu, serta transfer bank yang atomik dan toleran terhadap kegagalan: https://github.com/redplanetlabs/rama-demo-gallery

  • Kalau tidak benar-benar menjalankan situs web dengan 40 juta pengguna harian, rasanya tidak bisa mengklaim bahwa ini terbukti lewat “klien Mastodon berskala Twitter”. Mustahil mensimulasikan lingkungan nyata, perubahan kode dan infrastruktur yang menyertainya, pengguna nyata, penggunaan jaringan, dan sebagainya