3.4 Arsitektur data dan penyimpanan

Tinjauan dan motivasi

Data hidup lebih lama daripada kode. Aplikasi ditulis ulang setiap beberapa tahun, tetapi data yang dikelolanya (catatan pelanggan, buku besar keuangan, riwayat tunjangan, rekam medis) bertahan puluhan tahun. Sering kali ia aset organisasi yang paling berharga dan paling diatur. Arsitektur data adalah disiplin memutuskan bagaimana data itu dimodelkan, di mana disimpan, bagaimana dijaga konsisten, bagaimana berkembang, dan bagaimana disajikan cukup cepat pada skala besar. Bagi organisasi besar, keputusan ini bersifat fondasional. Pilihan mesin penyimpanan dan model data membatasi apa yang dapat dilakukan bisnis, secepat apa ia bergerak, dan berapa biayanya, sepanjang umur sistem.

Taruhannya paling tinggi di enterprise dan pemerintah karena skala, umur panjang, dan regulasi. Penyimpanan transaksi bank tidak boleh kehilangan atau menghitung ganda satu sen pun. Registri pemerintah harus menyimpan catatan selama masa yang ditetapkan undang-undang dan membuktikan integritasnya kepada auditor. Sistem kesehatan harus menegakkan akses berbutir halus dan aturan residensi. Pada saat yang sama, organisasi ini melayani volume baca dan tulis yang sangat besar dan tidak sanggup membiarkan setiap kueri menghantam satu basis data relasional. Jadi arsitektur data harus mendamaikan kebenaran dan ketahanan dengan kinerja dan skala, sambil skema terus berubah memenuhi mandat baru.

Bab ini membahas paradigma penyimpanan utama dan kapan memakai masing-masing, disiplin polyglot persistence, pemodelan data dan masalah evolusi serta migrasi skema yang sering diremehkan, caching dan CDN (content delivery network) beserta masalah invalidasi yang terkenal sulit, dan bagaimana transaksi, penguncian, dan konkurensi berperilaku saat didorong ke skala besar. Benang merahnya sederhana: tidak ada basis data universal. Yang ada hanya trade-off, dan arsitektur data yang baik berarti memilihnya secara sadar, satu beban kerja demi satu.

Prinsip utama

Modelkan data agar sesuai pola akses, bukan sebaliknya. Rancang penyimpanan di sekitar bagaimana data akan dibaca dan ditulis, bukan di sekitar model “benar” yang abstrak.
Tidak ada satu basis data untuk menguasai semuanya. Beban kerja berbeda menginginkan mesin berbeda; polyglot persistence normal pada skala besar.
Kebenaran lebih dulu untuk sistem pencatat. Untuk data berwenang, ketahanan dan konsistensi tidak dapat ditawar; optimalkan kinerja di sekitarnya, bukan menembusnya.
Skema akan berubah, jadi rencanakan. Migrasi adalah aktivitas rekayasa kelas satu yang berkelanjutan, bukan sekali jalan.
Miliki data Anda di balik batas layanan. Setiap bounded context (model domain mandiri dengan batas eksplisitnya sendiri) memiliki datanya; berbagi basis data mengopel tim dan menghancurkan otonomi.
Caching adalah masalah kebenaran yang menyamar sebagai kemenangan kinerja. Setiap cache memperkenalkan kebasian dan risiko invalidasi; perlakukan dengan sengaja.
Denormalisasi adalah pertukaran, bukan dosa. Menduplikasi data demi kinerja baca sah jika Anda memiliki konsekuensi konsistensinya.
Konsistensi dan skala saling bertukar. Semakin kuat jaminan transaksionalnya, semakin sulit didistribusikan; beli hanya yang dibutuhkan beban kerja.

Rekomendasi

Pilih paradigma penyimpanan dari beban kerja

Cocokkan setiap beban kerja dengan model yang sesuai. Basis data relasional memberi konsistensi kuat, join, dan transaksi matang; ia bawaan untuk sistem pencatat dan apa pun dengan aturan integritas kompleks. Penyimpanan dokumen cocok untuk data hierarkis berskema fleksibel yang dibaca sebagai satu kesatuan (seluruh pesanan, seluruh profil). Penyimpanan key-value memberi kecepatan ekstrem untuk pencarian sederhana (sesi, feature flag, cache). Basis data graf unggul di tempat hubungan adalah kuerinya (jaringan penipuan, bagan organisasi, hak akses, rantai pasok). Penyimpanan kolumnar menggerakkan kueri analitik yang memindai sedikit kolom pada miliaran baris (data warehouse, pelaporan). Basis data deret waktu dioptimalkan untuk data berstempel waktu yang banyak ditambahkan (metrik, telemetri, sensor Internet of Things (IoT), data pasar). Tahan diri dari memaksa satu mesin mengerjakan semua tugas. Memakai basis data relasional sebagai antrean, atau penyimpanan dokumen sebagai buku besar, mengundang rasa sakit.

Adopsi polyglot persistence dengan sengaja

Sistem besar secara sah memakai beberapa penyimpanan: sistem pencatat relasional, indeks pencarian, cache, warehouse analitik, dan mungkin mesin graf atau deret waktu. Ini polyglot persistence, dan ia pola yang tepat ketika beban kerja benar-benar berbeda. Biayanya operasional, karena kini Anda punya lebih banyak mesin untuk dijalankan, diamankan, dicadangkan, dan diisi stafnya. Kelola biaya itu dengan memperlakukan setiap penyimpanan sebagai milik sebuah layanan, membakukan perkakas operasional, dan menjaga jumlah teknologi pada yang pantas mendapat tempat. Waspadai mengadopsi basis data baru untuk setiap kebutuhan kecil. Masing-masing adalah komitmen operasional permanen.

Modelkan data dan perlakukan evolusi skema sebagai berkelanjutan

Investasikan pada pemodelan data di muka untuk sistem pencatat. Normalisasikan untuk melindungi integritas, lalu denormalisasi secara selektif untuk titik panas baca yang terbukti. Apa pun modelnya, skema berkembang selamanya, jadi buat migrasi aman dan rutin. Gunakan skrip migrasi berversi, otomatis, dan maju-saja yang disimpan di kontrol sumber dan diterapkan lewat pipeline deployment. Untuk perubahan tanpa downtime pada tabel besar, gunakan pola expand-contract (parallel change): tambahkan kolom atau tabel baru, isi ulang dan tulis ganda, migrasikan pembaca, lalu hapus bentuk lama. Jangan pernah satu alter yang merusak. Buat perubahan skema kompatibel mundur lintas deploy agar kode lama dan baru berjalan bersamaan. Dalam sistem event-sourced atau berbasis pesan, versikan skema peristiwa dan pesan Anda secara eksplisit dan dukung upcasting peristiwa lama (mengubahnya ke skema saat ini ketika dibaca).

Rancang caching dan invalidasi dengan mata terbuka

Caching dan CDN adalah perkakas kinerja berpengungkit tertinggi. CDN menyajikan konten statis dan yang dapat di-cache dari tepi dekat pengguna, dan cache aplikasi menyelamatkan basis data dari pembacaan berulang. Tetapi bagian sulitnya adalah invalidasi: mengetahui kapan data ter-cache sudah basi. Pilih strategi per kasus. Pakai kedaluwarsa berbasis waktu (TTL) di tempat kebasian ringan dapat diterima dan paling sederhana. Pakai invalidasi eksplisit atau write-through di tempat kesegaran penting. Pakai cache-aside di tempat aplikasi mengelola pengisian. Tetapkan TTL secara sadar, jaga dari cache stampede (banyak klien membangun ulang entri kedaluwarsa yang sama sekaligus) dengan penguncian atau penggabungan permintaan, dan cegah thundering herd pada cache dingin. Jangan pernah meng-cache data yang kebasiannya dapat menyebabkan kegagalan kebenaran atau kepatuhan (hak akses, saldo, persetujuan) tanpa jalur invalidasi yang eksplisit dan teruji. Perlakukan kunci cache, TTL, dan invalidasi sebagai artefak yang dirancang, bukan konfigurasi insidental.

Kelola transaksi, penguncian, dan konkurensi untuk skala

Pahami tingkat isolasi dan pilih yang terlemah yang masih benar untuk setiap transaksi, karena isolasi lebih tinggi memakan konkurensi. Pilih optimistic concurrency (pemeriksaan versi saat menulis) untuk beban kerja berkontensi rendah dan banyak baca, dan raih penguncian pesimistis hanya di bawah kontensi panas sejati, menjaga kunci tetap singkat dan berurutan konsisten untuk menghindari deadlock. Seiring Anda berskala, satu basis data yang dapat ditulis menjadi hambatan. Perkenalkan replika baca untuk penskalaan baca (menerima lag replikasi), dan shard/partisi menurut kunci yang menyebar beban merata dan menjaga data terkait bersama untuk menghindari transaksi lintas shard. Ingat bahwa sharding melepas join lintas shard yang mudah dan transaksi ACID (Atomicity, Consistency, Isolation, Durability) multi-shard, itulah sering alasan saga dan denormalisasi muncul. Masukkan teknik ini hanya sebatas yang dituntut beban kerja. Sharding prematur menambah kompleksitas permanen.

Trade-off: kelebihan dan kekurangan

Jenis penyimpanan	Terbaik untuk	Kekuatan	Kelemahan
Relasional	Sistem pencatat, integritas kompleks	ACID, join, perkakas matang	Lebih sulit menskalakan tulis secara horizontal
Dokumen	Pembacaan agregat, skema fleksibel	Baca/tulis seluruh objek cepat, fleksibel	Join/transaksi lintas dokumen lemah
Key-value	Sesi, cache, pencarian sederhana	Kecepatan dan skala ekstrem	Tidak ada kueri selain kunci
Graf	Kueri padat hubungan	Traversal cepat, ekspresif	Keahlian ops niche, batas skala
Kolumnar	Analitik, pelaporan	Pemindaian agregat cepat, kompresi	Buruk untuk tulis transaksional tingkat baris
Deret waktu	Metrik, telemetri, IoT	Penambahan dan kueri waktu efisien	Tujuan sempit

Trade-off dominannya adalah konsistensi dan kueri kaya versus skalabilitas horizontal dan kecepatan. Sistem relasional memberi jaminan terkuat dan kueri paling fleksibel, tetapi paling sulit menskalakan tulis ke banyak mesin. Keluarga NoSQL (non-relasional) melonggarkan join, transaksi, atau skema demi skala dan kecepatan. Caching menukar kesegaran dengan latensi. Sharding menukar transaksi lintas partisi dengan throughput tulis. Tak satu pun benar secara universal. Seninya adalah menempatkan setiap beban kerja pada titik kurva yang benar-benar dituntut oleh kebutuhan kebenaran dan kinerjanya.

Pertanyaan untuk didiskusikan dengan tim Anda

Untuk setiap dataset kritis, dapatkah semua orang menyebut satu sistem pencatatnya, atau cache dan proyeksi diam-diam diperlakukan sebagai kebenaran? Data hidup lebih lama daripada kode, dan insiden data paling merusak datang dari penyimpangan: cache, indeks pencarian, atau proyeksi baca keliru dianggap berwenang dan diam-diam menyimpang dari sumber sebenarnya. Pada tim besar ini terjadi ketika kepemilikan kabur dan beberapa layanan menulis salinan yang tumpang tindih, sehingga tak seorang pun dapat mengatakan nilai mana yang benar selama insiden. Bawa peta data penting Anda dan, untuk setiap item, satu penyimpanan yang berwenang ditambah salinan turunan yang harus dapat dibangun ulang darinya. Di bidang keuangan dan pemerintah, kemampuan membuktikan catatan mana yang menjadi sumber hukum dan merekonstruksi sisanya sering kali persyaratan regulasi, bukan kenyamanan. Apa pun yang tidak dapat Anda bangun ulang dari sistem pencatat adalah sistem pencatat itu sendiri, Anda bermaksud demikian atau tidak.
Berapa sebenarnya biaya setiap mesin basis data di properti Anda untuk dijalankan, diamankan, dan dicadangkan, dan apakah masing-masing masih pantas mendapat tempatnya? Polyglot persistence tepat ketika beban kerja benar-benar berbeda, tetapi setiap mesin adalah komitmen operasional permanen: penambalan, cadangan, pemantauan, tinjauan keamanan, dan staf yang mengenalnya pukul 3 pagi. Organisasi besar dapat hanyut ke kebun binatang penyimpanan yang diadopsi masing-masing untuk satu fitur, dan yang marjinal menambah biaya selamanya sambil melayani beban kerja yang dapat ditangani penyimpanan yang sudah Anda jalankan. Daftar setiap mesin, beban kerja yang membenarkannya, dan siapa yang on-call untuknya, lalu tandai yang diadopsi untuk kebutuhan yang kini dapat dipenuhi penyimpanan utama. Adopsi basis data baru harus melewati standar tinggi, karena menghapusnya kelak berarti migrasi lagi. Membakukan perkakas operasional di seluruh penyimpanan yang Anda pertahankan adalah cara menekan biaya tanpa memaksa satu mesin mengerjakan semua tugas.
Di mana pengguna dapat membaca nilai basi dari replika tepat setelah tulisannya sendiri, dan apakah itu melanggar janji yang Anda berikan kepadanya? Replika baca menskalakan pembacaan tetapi tertinggal dari primer, sehingga pengguna yang memperbarui profil dan segera memuat ulang dapat melihat nilai lama, yang terbaca sebagai bug atau, untuk saldo atau bendera persetujuan, kegagalan kepatuhan. Putuskan per alur apakah baca-tulisan-sendiri penting, dan arahkan pembacaan itu ke primer atau pakai mekanisme konsistensi sesi. Bawa daftar alur yang dilayani dari replika dan tandai mana yang ditindaklanjuti pengguna segera setelah menulis. Untuk saldo, hak akses, dan persetujuan, perlakukan pembacaan basi sebagai kegagalan kebenaran, bukan kosmetik. Intinya adalah membeli konsistensi yang benar-benar dibutuhkan setiap beban kerja, dan membuat kebasian yang Anda terima eksplisit alih-alih tidak sengaja.
Dapatkah Anda mengubah skema tabel terbesar dan tersibuk Anda hari ini tanpa downtime, dan siapa yang benar-benar pernah berlatih langkah expand-contract? Skema berkembang selamanya, dan kegagalan yang paling menyakitkan adalah alter big-bang yang mengunci tabel besar, membekukan layanan, dan tidak dapat di-rollback dengan bersih. Pada tim besar risikonya berlipat karena beberapa layanan membaca bentuk yang sama, sehingga perubahan yang merusak membutuhkan kode lama dan baru berjalan berdampingan melintasi deploy bertahap. Tarikan yang bersaing adalah kecepatan: satu alter cepat ditulis, sedangkan expand-contract (tambah bentuk baru, isi ulang, tulis ganda, migrasikan pembaca, buang bentuk lama) lebih banyak langkah dan lebih banyak kesabaran. Bawa tabel terbesar Anda, estimasi jujur berapa lama alter naif akan menguncinya, dan migrasi spesifik yang pernah seseorang jalankan dari ujung ke ujung dalam latihan, bukan dalam teori. Dalam sistem enterprise dan pemerintah yang berjalan terus dan membawa target ketersediaan undang-undang, downtime untuk migrasi adalah pelanggaran, sehingga disiplin expand-contract adalah harga untuk diizinkan mengubah skema sama sekali.
Nilai ter-cache atau tereplikasi mana yang, jika disajikan basi, akan menyebabkan kegagalan kepatuhan atau keselamatan alih-alih kosmetik, dan apakah setiap jalur invalidasinya teruji? Caching adalah masalah kebenaran yang mengenakan kostum kinerja: bahayanya bukan kelambatan melainkan menyajikan hak akses, saldo, bendera persetujuan, atau keputusan akses setelah ia berubah. Bagi organisasi besar bahayanya menyebar, karena cache dan lapisan tepi menumpuk lintas tim dan tak seorang pun dapat mendaftar apa yang di-cache di mana atau kapan dibersihkan. Ketegangannya nyata: caching agresif dan TTL panjang membeli latensi dan melindungi basis data, sementara kesegaran ketat memakan keduanya. Bawa inventaris data ter-cache dan yang disajikan CDN, ditandai entri mana yang membawa konsekuensi kepatuhan atau keselamatan, ditambah bukti bahwa jalur invalidasi masing-masing telah dilatih dalam praktik dan bukan sekadar dikonfigurasi. Dalam lingkungan yang diatur dan publik, nilai persetujuan atau kelayakan yang basi adalah kegagalan yang dapat diaudit, sehingga item itu membutuhkan jalur invalidasi eksplisit yang teruji atau tidak boleh di-cache sama sekali.
Apa strategi retensi, pengarsipan, dan residensi data Anda untuk setiap penyimpanan berwenang, dan dapatkah Anda membuktikannya kepada auditor? Data hidup lebih lama daripada kode dan sering lebih lama daripada tim yang menulisnya, sehingga pertumbuhan tak terbatas dan aturan residensi yang kabur diam-diam menjadi masalah yang tak dimiliki siapa pun sampai tabel tak terkelola atau catatan berada di yurisdiksi yang salah. Organisasi besar mencakup banyak penyimpanan dan wilayah, dan pertimbangan yang bersaing adalah biaya (penyimpanan panas mahal, jadi arsipkan dan bertingkat), kinerja (tabel membengkak memperlambat segalanya), dan kewajiban hukum (lantai retensi undang-undang dan batas atas residensi yang dapat berkonflik). Bawa, per dataset berwenang, masa retensi, di mana data secara fisik berada, mekanisme pengarsipan dan penghapusan, dan nama orang yang bertanggung jawab. Untuk sistem enterprise dan terutama pemerintah, retensi dan residensi biasanya mandat hukum dengan persyaratan audit dan kedaulatan, sehingga kemampuan membuktikan di mana setiap catatan berada, berapa lama disimpan, dan kapan dimusnahkan adalah izin beroperasi, bukan basa-basi.

Lensa sektor

Startup. Jalankan satu basis data dan tahan kebun binatang. Satu penyimpanan relasional terkelola memberi Anda transaksi, satu hal untuk dicadangkan, dan satu tempat untuk bernalar tentang konsistensi, yang persis dapat ditampung di kepala tim beranggotakan tiga orang. Tambahkan cache, replika baca, atau indeks pencarian hanya ketika kueri lambat tertentu atau volume baca nyata memaksanya, agar kompleksitas datang dengan alasan yang membayar. Jaga migrasi berversi sejak hari pertama, karena memasang disiplin migrasi pada produk yang sudah hidup jauh lebih sulit daripada memulai dengannya.

Bisnis kecil. Anda tidak punya spesialis basis data dan tidak punya waktu mengoperasikan beberapa mesin, jadi pilih penyimpanan terkelola dan biarkan penyedia platform menangani cadangan, penambalan, dan replikasi. Perlakukan pemilihan penyimpanan sebagai keputusan beli: pilih mesin membosankan yang didukung baik yang sudah terintegrasi dengan perkakas Anda alih-alih yang tercepat di benchmark. Tetapkan kebijakan retensi dan cadangan sederhana yang benar-benar dapat Anda verifikasi, dan jangan pernah meng-cache apa pun yang terkait uang atau izin tanpa cara jelas untuk membersihkannya, karena harga atau hak akses yang basi membuat Anda kehilangan pelanggan.

Enterprise. Tantangan intinya adalah polyglot persistence di banyak tim: sistem pencatat relasional plus pencarian, cache, warehouse, dan mungkin mesin graf atau deret waktu, masing-masing dimiliki sebuah layanan alih-alih dibagi. Bakukan perkakas operasional, cadangan, dan pemantauan di seluruh penyimpanan yang Anda pertahankan, tahan adopsi mesin baru pada standar tinggi, dan jadikan migrasi expand-contract serta invalidasi cache eksplisit sebagai bawaan. Kelola properti sebagai portofolio dengan kepemilikan data yang jelas, agar tidak ada mesin yang bertahan melewati beban kerja yang membenarkannya dan tak ada tim yang terkopel lewat basis data bersama.

Pemerintah. Residensi data, retensi undang-undang, dan integritas yang dapat dibuktikan membentuk setiap pilihan. Sediakan setiap penyimpanan di wilayah berdaulat, konfigurasikan CDN untuk meng-cache hanya data non-pribadi, dan simpan riwayat audit tak berubah untuk catatan yang harus dapat direkonstruksi bagi regulator. Migrasi yang diamanatkan undang-undang baru harus diterapkan secara kompatibel mundur lewat pipeline agar layanan tetap tersedia melewati tenggat legislatif, dan sistem pencatat harus dapat diidentifikasi sehingga Anda dapat membuktikan nilai mana yang menjadi sumber hukum dan membangun ulang setiap salinan turunan darinya.

Contoh

Startup. Sebuah startup tahap benih menjalankan segalanya pada satu instans PostgreSQL terkelola dan menahan dorongan menambah mesin pencarian, cache, dan warehouse terpisah sebelum membutuhkannya. Satu basis data berarti satu hal untuk dicadangkan, satu tempat untuk bernalar tentang konsistensi, dan transaksi yang langsung berfungsi, yang penting ketika seluruh tim terdiri dari tiga insinyur. Mereka menambahkan cache Redis dan replika baca hanya ketika kueri lambat tertentu dan volume baca nyata membenarkannya, sehingga kompleksitas datang dengan alasan yang membayar, bukan mendahuluinya.

Enterprise. Sebuah bank ritel menyimpan buku besar berwenangnya di basis data relasional konsisten kuat: setiap posting adalah transaksi ACID yang layak, di-shard menurut rentang akun untuk skala tulis. Di sekitarnya berdiri properti polyglot: indeks pencarian untuk pencarian pelanggan, cache Redis (write-through, TTL pendek) untuk ringkasan akun di aplikasi seluler, warehouse kolumnar untuk pelaporan regulasi dan analitik, dan basis data graf untuk deteksi penipuan jaringan transaksi. Perubahan skema pada buku besar memakai expand-contract dengan tulis ganda sehingga sistem 24/7 tidak pernah downtime untuk migrasi.

Pemerintah. Registri kendaraan nasional menyimpan catatan berwenang dalam sistem pencatat relasional dengan retensi undang-undang dan riwayat audit penuh. Pencarian “periksa kendaraan” yang menghadap publik dilayani dari replika baca dan cache tepi dengan TTL pendek, karena data publik yang sedikit basi dapat diterima dan volume baca jauh melampaui tulis. Hukum residensi data mewajibkan semua catatan tetap di dalam negeri, jadi setiap penyimpanan disediakan di wilayah berdaulat dan CDN dikonfigurasi untuk meng-cache hanya data non-pribadi. Migrasi untuk menambah bidang baru yang diamanatkan kebijakan transportasi diterapkan secara kompatibel mundur lewat pipeline agar layanan tetap tersedia selama tenggat legislatif.

Kasus bisnis: motivasi, ROI, dan TCO

Keputusan arsitektur data memiliki ekor biaya terpanjang dan terbesar dalam perangkat lunak, karena data dan skemanya adalah hal tersulit diubah begitu sistem dan integrasi bergantung padanya. Biaya adopsi praktik yang baik (pemilihan penyimpanan yang disengaja, migrasi disiplin, caching yang dirancang, dan sharding yang tepat) sebagian besar adalah waktu rekayasa senior dan sedikit perkakas operasional tambahan. Biaya tidak mengadopsinya muncul sebagai satu basis data kelebihan beban yang mencekik seluruh bisnis, re-platforming darurat ketika penyimpanan yang salah ditemukan terlambat, pemadaman berkepanjangan dari migrasi yang kacau, dan, yang paling merusak, kerusakan data atau pelanggaran kepatuhan dari cache yang salah di-invalidasi atau transaksi yang hilang.

Ajukan kasus kepada pimpinan dalam hal ruang skalabilitas, risiko insiden, dan paparan regulasi. Pilihan penyimpanan yang tepat memungkinkan bisnis menumbuhkan volume baca dan tulis tanpa menulis ulang. Migrasi disiplin memungkinkan skema mengimbangi mandat baru tanpa downtime. Caching yang benar memberikan pengalaman pengguna cepat tanpa bug kebasian diam-diam. Kuantifikasi TCO sepanjang umur sistem. Satu arsitektur data yang dipilih dengan baik menghindari biaya berulang untuk menyiasati yang buruk, dan satu insiden kerusakan data yang dicegah biasanya melampaui seluruh biaya melakukannya dengan baik. Di sektor yang diatur, kemampuan membuktikan integritas dan residensi data bukan pusat biaya melainkan izin beroperasi.

Anti-pola dan jebakan

Basis data bersama lintas layanan. Beberapa layanan membaca dan menulis satu skema, mengopel tim dan menjadikan setiap perubahan krisis koordinasi.
Satu basis data untuk segalanya. Memaksa analitik, antrean, pencarian, dan transaksi ke satu mesin relasional sampai ia runtuh.
Migrasi big-bang. Perubahan skema tunggal yang merusak, memerlukan downtime, dan tak dapat di-rollback dengan aman.
Caching tanpa strategi invalidasi. Data basi disajikan tanpa batas, atau bug kebenaran karena tak seorang pun memiliki kapan cache dibersihkan.
Sharding prematur. Mendistribusikan data sebelum beban menuntutnya, kehilangan join dan transaksi secara permanen tanpa manfaat.
Mengabaikan lag replikasi. Membaca tulisan sendiri dari replika yang tertinggal dan mendapat data basi, melanggar ekspektasi pengguna.
Pertumbuhan data tak terbatas. Tanpa strategi pengarsipan atau retensi, tabel tumbuh sampai kinerja dan biaya tak tertahankan.
Menyimpan data turunan sebagai kebenaran. Memperlakukan cache, indeks, atau proyeksi sebagai sistem pencatat, lalu menemukan ia telah menyimpang.

Model kematangan

Tingkat 1: Memulai. Satu basis data dipakai untuk setiap tujuan. Perubahan skema manual dan ad hoc, tanpa disiplin migrasi. Caching insidental dan invalidasi renungan belakangan. Masalah kinerja diselesaikan secara reaktif dengan membeli mesin lebih besar, dan tak seorang pun dapat dengan andal menyebut sistem pencatat untuk dataset tertentu.
Tingkat 2: Mengembangkan. Sebagian pilihan penyimpanan disengaja dan cache atau warehouse telah muncul, tetapi praktik bervariasi menurut tim. Migrasi berversi namun kadang memerlukan downtime, dan expand-contract dipakai oleh siapa pun yang kebetulan tahu. Beberapa layanan masih berbagi basis data, dan strategi caching berbeda dari satu tim ke tim lain.
Tingkat 3: Membakukan. Polyglot persistence dicocokkan dengan beban kerja, setiap penyimpanan dimiliki sebuah layanan dan tidak pernah dibagi. Migrasi expand-contract otomatis, kompatibel mundur, tanpa downtime adalah standar terdokumentasi yang ditegakkan di seluruh organisasi. Strategi caching, TTL, dan jalur invalidasi adalah artefak desain eksplisit, dan satu sistem pencatat untuk setiap dataset terdokumentasi, dengan salinan turunan yang dapat dibangun ulang darinya.
Tingkat 4: Mengelola. Properti data diukur dan dikendalikan terhadap garis dasar. Anda melacak durasi migrasi dan tingkat rollback, lag replikasi terhadap persyaratan baca-tulisan-sendiri, rasio hit cache dan insiden kebasian, biaya operasional per penyimpanan, dan latensi kueri pada persentil target, lalu bertindak atas angka itu. Retensi dan residensi diaudit terhadap persyaratan undang-undang, kebenaran data turunan diverifikasi terus-menerus, dan setiap mesin harus membenarkan biayanya terhadap beban kerja yang dilayaninya.
Tingkat 5: Mengorkestrasi. Arsitektur data terus diperbaiki dan terintegrasi dengan perencanaan kapasitas, biaya, dan risiko di seluruh organisasi. Pilihan sharding, caching, dan konsistensi diseimbangkan ulang per beban kerja seiring bergesernya pola akses dan biaya, dan penyimpanan yang tak lagi pantas mendapat tempat dipensiunkan lewat migrasi terencana. Evolusi skema, pengarsipan, dan residensi sepenuhnya otomatis dan adaptif, sehingga properti membentuk ulang dirinya terhadap mandat dan beban baru tanpa re-platforming darurat.

Gagasan untuk didiskusikan

Penyimpanan Anda saat ini yang mana yang mengerjakan tugas yang tidak dirancang untuknya, dan apa mesin yang tepat?
Dapatkah Anda melakukan perubahan skema pada tabel terbesar Anda hari ini dengan nol downtime? Jika tidak, mengapa?
Di mana sistem Anda meng-cache data yang kebasiannya dapat menyebabkan kegagalan kepatuhan atau kebenaran?
Layanan mana yang berbagi basis data, dan apa yang diperlukan untuk memberi masing-masing basis datanya sendiri?
Di mana satu basis data yang dapat ditulis menjadi batas atas skala Anda, dan apakah replikasi baca atau sharding langkah berikutnya yang tepat?
Apa strategi retensi dan pengarsipan Anda, dan siapa yang bertanggung jawab atasnya?

Poin-poin utama

Data hidup lebih lama daripada kode; keputusan penyimpanan dan pemodelan membatasi bisnis sepanjang umur sistem.
Cocokkan setiap beban kerja dengan paradigma penyimpanan yang sesuai pola aksesnya; harapkan polyglot persistence pada skala besar.
Beri setiap layanan kepemilikan atas datanya; jangan pernah mengopel tim lewat basis data bersama.
Perlakukan evolusi skema sebagai berkelanjutan dan pakai migrasi expand-contract kompatibel mundur tanpa downtime.
Caching adalah masalah kebenaran: rancang TTL, invalidasi, dan perlindungan stampede dengan sengaja, dan jangan pernah meng-cache data kritis-kepatuhan tanpa jalur invalidasi teruji.
Beli hanya jaminan konsistensi dan transaksional yang dibutuhkan setiap beban kerja; sharding dan replikasi menukar transaksi lintas partisi dengan skala.

Referensi dan bacaan lanjutan

Martin Kleppmann, Designing Data-Intensive Applications
Pramod Sadalage dan Martin Fowler, NoSQL Distilled
Pramod Sadalage dan Scott Ambler, Refactoring Databases: Evolutionary Database Design
C. J. Date, An Introduction to Database Systems
Joe Celko, SQL for Smarties
Vlad Mihalcea, High-Performance Java Persistence (transaksi, isolasi, konkurensi)
Eric Evans, Domain-Driven Design (bounded context dan kepemilikan data)
Werner Vogels, “Eventually Consistent”