Kisah seorang pembangun mengenai ekstrem pangkalan data telah mencetuskan perdebatan sengit tentang pendekatan yang betul untuk penyimpanan data dan logik perniagaan. Kisah ini mengisahkan perjalanan sebuah pasukan dari mimpi ngeri prosedur tersimpan kepada penyelesaian stor nilai-kunci yang sama bermasalah, menonjolkan bagaimana keputusan seni bina boleh berayun dari satu ekstrem ke ekstrem lain tanpa menemui titik manis.
Masalah Asal: Prosedur Tersimpan Menjadi Liar
Sistem warisan mengalami kes klasik kejuruteraan berlebihan pangkalan data. Logik perniagaan hidup sepenuhnya dalam prosedur tersimpan yang menampilkan gabungan kompleks merangkumi beberapa pangkalan data SQL Server . Prosedur-prosedur ini menjadi kesesakan prestasi, menghabiskan masa CPU pada pelayan pangkalan data yang terhad dan mewujudkan isu latensi yang tidak dapat diramal apabila pelan pertanyaan berubah secara tidak dijangka. Sistem ini juga sangat bergantung pada MSDTC ( Microsoft Distributed Transaction Coordinator ), yang kerap menyebabkan kebuntuan dan gangguan sistem.
MSDTC: Perkhidmatan Microsoft yang menyelaras transaksi merentasi beberapa pangkalan data atau sistem, tetapi terkenal kerana menyebabkan kebuntuan dan isu kebolehpercayaan.
Isu Sistem Asal:
- Logik perniagaan tertanam dalam prosedur tersimpan yang kompleks
- Pelbagai pangkalan data SQL Server merentasi pelayan yang berbeza
- Pergantungan berat pada MSDTC menyebabkan deadlock
- Perubahan pelan pertanyaan yang tidak dapat diramal menyebabkan timeout
- Masa pembinaan 15-30 minit memerlukan persekitaran pembangunan VM
Pembetulan Berlebihan: Ekstremisme Stor Nilai-Kunci
Sebagai tindak balas kepada masalah SQL mereka, pasukan seni bina membuat ayunan dramatik ke arah yang bertentangan. Mereka memutuskan untuk meninggalkan pangkalan data hubungan sepenuhnya, memilih stor nilai-kunci primitif yang hanya menawarkan empat operasi asas: baca, masuk, kemas kini, dan padam kunci tunggal. Tiada transaksi, tiada kumpulan, tiada pertanyaan kompleks dibenarkan.
Pendekatan ini mewujudkan masalah baru hampir serta-merta. Data perniagaan yang sangat berhubungan terpaksa diratakan menjadi dokumen JSON yang besar, kadangkala mencapai ratusan kilobait. Memandangkan stor nilai-kunci tidak mempunyai ciri pangkalan data dokumen, walaupun kemas kini kecil memerlukan pembacaan keseluruhan dokumen, membuat perubahan dalam kod aplikasi, kemudian menulis semula semuanya. Pasukan akhirnya menambah pemampatan untuk mengurangkan overhed rangkaian, tetapi ini menjadikan data mustahil untuk diperiksa dengan alat pangkalan data standard.
Batasan Stor Kunci-Nilai:
- Hanya 4 operasi: Baca, Masukkan, Kemas kini, Padam kunci tunggal
- Tiada sokongan transaksi atau pemprosesan kelompok
- Dokumen JSON mencapai ratusan kilobait
- Memerlukan pembacaan/penulisan dokumen penuh untuk kemas kini separa
- Pemampatan Gzip diperlukan, merosakkan alatan standard
Ledakan Kerumitan: Sistem Titik Periksa
Tanpa transaksi pangkalan data, pasukan membina sistem titik periksa yang rumit untuk mengendalikan konsistensi data. Setiap operasi tulis memerlukan penjanaan UUID dan menyimpannya sebagai titik periksa, kemudian membenamkan UUID ini dalam dokumen sasaran untuk mencegah operasi berganda semasa percubaan semula. Pendekatan ini hampir menggandakan bilangan perjalanan pangkalan data berbanding sistem asal, menjadikan masalah latensi lebih teruk dan bukannya lebih baik.
Dalam praktiknya, penulisan ke dalam pangkalan data yang sama yang sebelum ini memerlukan 5-10 perjalanan, kini memerlukan hampir dua kali ganda bilangan perjalanan untuk operasi titik periksa tambahan.
Overhed Sistem Checkpointing:
- Penjanaan UUID untuk setiap operasi penulisan
- Penyimpanan checkpoint dalam sistem berasingan
- Pembenaman UUID dalam dokumen sasaran
- Hampir menggandakan perjalanan pulang pergi pangkalan data (5-10 menjadi ~20)
- Logik percubaan semula yang kompleks untuk idempotency
Perspektif Komuniti: Perdebatan Jalan Tengah
Komuniti pembangunan kekal terbahagi mendalam mengenai pilihan seni bina pangkalan data. Ramai pembangun berkongsi kisah ngeri tentang prosedur tersimpan yang menjadi raksasa yang tidak dapat dikekalkan, dengan logik perniagaan bertaburan merentasi sistem dan bahasa pangkalan data yang berbeza. Yang lain berhujah bahawa prosedur tersimpan masih mempunyai tempatnya, terutamanya untuk operasi data pukal dan apabila beberapa aplikasi perlu mengakses pangkalan data yang sama dengan peraturan perniagaan yang konsisten.
Perdebatan ORM berbanding SQL mentah juga muncul dengan kuat dalam perbincangan. Sesetengah pembangun melihat ORM sebagai penggalak produktiviti yang menjimatkan masa walaupun kos prestasi, manakala yang lain melihatnya sebagai abstraksi yang menyembunyikan peluang pengoptimuman pangkalan data yang penting. Konsensus nampaknya ialah kepatuhan beragama kepada mana-mana pendekatan tunggal sering membawa kepada masalah.
ORM: Alat Object-Relational Mapping yang menterjemah antara jadual pangkalan data dan objek bahasa pengaturcaraan, menjadikan operasi pangkalan data lebih mudah tetapi kadangkala kurang cekap.
Pelajaran dalam Keseimbangan Seni Bina
Kisah ini menggambarkan corak biasa dalam pembangunan perisian: menyelesaikan satu masalah ekstrem dengan berayun ke ekstrem yang bertentangan. Pendekatan prosedur tersimpan asal mempunyai isu yang sah, tetapi penyelesaian nilai-kunci membuang dekad pengoptimuman pangkalan data bersama-sama dengan masalah. Pendekatan yang lebih terukur mungkin melibatkan pemfaktoran semula prosedur tersimpan, menambah baik strategi pengindeksan, atau menggunakan ORM moden dengan pemantauan prestasi yang teliti.
Kisah ini berfungsi sebagai peringatan bahawa keputusan seni bina harus berdasarkan keperluan teknikal khusus dan bukannya reaksi kepada titik kesakitan masa lalu. Kadangkala penyelesaian terbaik bukan terletak pada perubahan revolusioner, tetapi dalam penambahbaikan evolusi kepada sistem sedia ada.
Rujukan: Wrong ways to use the databases, when the pendulum swung too far