Mengapa basis data dan kompleksitasnya kini tidak lagi diperlukan

Masalah pada basis data dan mengapa kompleksitasnya tidak diperlukan

• Basis data adalah status global yang dapat berubah, sehingga membuat kode menjadi kompleks dan sulit dipahami.
• Model data bersifat terbatas dan tidak dapat mendukung semua kasus penggunaan, sehingga perlu menggunakan beberapa basis data.
• Masalah normalisasi vs denormalisasi menciptakan hubungan tegang antara konsistensi data dan kinerja.
• Skema yang terbatas menimbulkan kompleksitas karena representasi domain harus disesuaikan dengan basis data.
• Deployment yang kompleks meningkatkan biaya dan kerumitan akibat kombinasi serta integrasi berbagai alat.

Model yang konsisten untuk membangun backend aplikasi

• Fungsi dasar backend adalah menerima data baru dan menjawab pertanyaan tentang data tersebut.
• Desain backend yang ideal harus sedekat mungkin dengan bentuk ideal sambil tetap memenuhi batasan dunia nyata.

Rama

• Rama adalah platform pengembangan backend yang mereimplementasikan Mastodon untuk menyediakan layanan pada skala Twitter.
• Rama mengimplementasikan semua elemen backend seperti data, indeks, ETL, dan kueri dengan cara yang umum.
• Rama menyederhanakan deployment yang kompleks dan mengintegrasikan pemantauan, sehingga secara signifikan menurunkan biaya pengembangan dan pemeliharaan.

Opini GN⁺

• Masalah status global yang dapat berubah pada basis data meningkatkan kompleksitas kode dan kemungkinan kesalahan, dan ini adalah masalah yang sering dihadapi para pengembang.
• Rama menawarkan pendekatan baru yang mengatasi keterbatasan basis data yang ada dan mengurangi kompleksitas pengembangan backend.
• Tulisan ini memberikan informasi yang menarik dan bermanfaat bagi pengembang yang ingin mengurangi kompleksitas basis data dan sistem backend.

[GN⁺]

Komentar Hacker News

• Anda sebaiknya menggunakan satu subsistem yang merepresentasikan sumber kebenaran, dan subsistem lain yang mengimplementasikan berbagai penyimpanan indeks yang diturunkan dari sumber tersebut. Ini adalah gabungan antara event sourcing dan materialized views.

  • Event sourcing dan materialized views: Solusinya adalah memisahkan dan mengelola sistem yang merepresentasikan sumber kebenaran dan penyimpanan indeks yang dibangun berdasarkan sistem tersebut.

• Kami memisahkan model baca dan model tulis: model tulis ("sumber kebenaran") terdiri dari model domain relasional tradisional, dan hampir setiap perintah menghasilkan event yang dipublikasikan ke shared domain event queue. Model baca dibentuk oleh worker yang mengonsumsi event dan membangun view.

  • Pemisahan model baca/tulis: Model tulis terdiri dari model domain relasional, dan perintah menghasilkan event yang dipublikasikan ke domain event queue. Model baca mengonsumsi event untuk membangun view.

• Materializing saat data berubah bisa memberi keuntungan ketika produk harus melakukan satu pekerjaan dengan sangat cepat. Tetapi masalah muncul saat Anda perlu menambahkan fitur baru yang memerlukan transaksi kompleks atau data yang diorganisasi secara berbeda.

  • Batasan materializing data: Berguna bila dioptimalkan untuk satu tugas, tetapi bisa menimbulkan masalah saat menambahkan fitur yang membutuhkan transaksi kompleks atau struktur data baru.

• Mengklaim bahwa ini telah terbukti pada "klien Mastodon berskala Twitter" pada praktiknya tidak mungkin, kecuali Anda benar-benar mengoperasikan situs dengan 40 juta pengguna per hari.

  • Pentingnya skala: Mustahil mensimulasikan lingkungan pengguna berskala besar yang nyata, sehingga sulit membuat klaim semacam itu.

• Pendekatan yang lebih baik adalah gabungan event sourcing dan materialized views.

  • Gabungan event sourcing dan materialized views: Diusulkan sebagai pendekatan yang lebih baik, meski disertai peningkatan kompleksitas.

• Tidak ada satu model data yang bisa mendukung semua use case.

  • Keberagaman model data: Tidak mungkin mendukung semua use case dengan satu model data.

• Saya tidak punya keluhan tentang database.

  • Validitas database: Tidak ada keluhan terhadap database; ini tetap merupakan alat yang valid.

• Apakah konsep seperti konkurensi, isolasi, dan constraint diabaikan? Apakah "query topology" benar-benar lebih unggul untuk lingkungan pengembang?

  • Pertanyaan tentang query topology: Mempertanyakan klaim bahwa query topology lebih unggul bagi lingkungan pengembang, karena konsep penting seperti konkurensi, isolasi, dan constraint tampak diabaikan.

• Saya butuh ELI5 untuk Rama. Dokumentasinya membingungkan, dan jangan gunakan buzzword seperti "pergeseran paradigma" atau "platform".

  • Permintaan penjelasan sederhana tentang Rama: Meminta penjelasan Rama yang mudah dipahami dan jelas tanpa buzzword.

• Event sourcing (+ materialized views dan indeks) bukan berarti membuang RDBMS. Keduanya bisa dipakai bersama.

  • Koeksistensi event sourcing dan RDBMS: Event sourcing dan materialized views bisa digunakan bersama RDBMS; keduanya tidak saling eksklusif.

Pengetahuan latar:

• Event Sourcing: Pola desain yang mencatat perubahan status sistem sebagai event, sehingga status sistem dapat direkonstruksi dengan memutarnya ulang.
• Materialized Views: Teknik untuk meningkatkan performa baca data dengan menyimpan hasil query database secara fisik.
• RDBMS (Relational Database Management System): Sistem untuk mengelola database relasional.