Saya relatif baru lulus dari perguruan tinggi sehingga sebagian besar keakraban saya dengan database relasional adalah dari kursus database saya di mana apa pun yang tidak di BCNF atau 3NF adalah sebuah parodi. Tentu saja itu salah satu ujung yang ekstrem, tetapi tim saya di tempat kerja tampaknya benar-benar membawanya ke ujung yang berlawanan.
Dalam skema microservice db kami, entitas jarang memiliki lebih dari satu tabel. Apa pun yang biasanya Anda normalkan ke tabel lain disimpan dalam kolom json. Jika nanti ditemukan bahwa salah satu properti dalam json ini perlu ditanyakan, kolom baru ditambahkan dan data disimpan di kedua tempat (ya, dalam dua kolom berbeda di tabel yang sama).
Dalam banyak kasus, kolom json ini pasti memiliki keunggulan. Jika Anda tidak pernah perlu menanyakan data itu dan jika Anda tidak perlu membuat perubahan unilateral untuk data itu (yang merupakan sesuatu yang jelas tidak dapat Anda prediksi), itu bukan ide yang buruk. Ditambah banyak layanan kami yang tidak melihat server atau dihosting di mesin dengan jumlah ruang disk yang tidak sesuai untuk apa yang mereka butuhkan, sehingga duplikasi data bukan masalah besar. (Meskipun sesuatu yang saya umumnya ingin hindari dari filsafat)
Saat ini kami sedang membangun layanan yang cocok dengan aturan berdasarkan seperangkat kondisi yang mereka miliki dan kemudian melakukan serangkaian tindakan yang terkait dengan aturan tersebut ketika aturan itu benar (misalnya semua persyaratan itu benar). Sub tim saya yang paling cepat membangun layanan ini percaya bahwa ada manfaat besar untuk menormalkan tindakan dan ketentuan yang jauh dari aturan dalam skema. Jelas tabel ini memelihara hubungan kunci asing dengan id aturan. Dari sudut pandang kami, kami dapat menghindari duplikasi data pada kondisi yang memungkinkan kami memastikan bahwa mereka hanya dievaluasi satu kali dan mudah untuk menemukan kondisi dan aturan yang kami butuhkan saat membutuhkannya tanpa harus menarik setiap aturan dan melakukan pencarian dalam memori.
Berbicara dengan salah satu insinyur utama kami hari ini, ia berusaha mendorong saya jauh dari skema ini. Mencoba berdebat dalam segala hal yang kita lakukan sebenarnya tidak membutuhkannya, itu akan menyebabkan masalah kinerja di masa depan, merujuk pada monolit lama yang kita miliki yang merupakan desain yang tidak benar. Dia menyebut apa yang kita lakukan sebagai "jalan lama" dan meja datar dengan json sebagai "jalan baru". Dia berpendapat bahwa di tempat-tempat di mana saya menginginkan atomisitas, kita tidak memerlukannya dan bahwa alih-alih bertanya kita harus melakukan lebih banyak hal dalam memori. Ini adalah prinsip desain yang diikuti oleh banyak layanan kami sekarang. Kami tidak mengantisipasi bahwa volume data kami akan tumbuh secara substansial yang seharusnya menjaga kueri kami dengan cepat. Apa yang kami antisipasi adalah banyak waktu yang dihabiskan dalam evaluasi aturan dan melakukan tindakan.
Saya mengerti bahwa basis data non-relasional telah menjadi lebih populer dalam beberapa tahun terakhir, tetapi bahkan ketika secara aktif mencari informasi tentang implikasi kinerja hubungan kunci asing, saya tidak melihat banyak informasi membuat masalahnya. Saya kira mereka mungkin cenderung untuk memperkenalkan transaksi besar yang dapat menyebabkan masalah, tetapi itu tampaknya seperti masalah yang terlepas dari kunci asing itu sendiri.
Apakah ini kenaifan saya? Atau apakah ini benar-benar ada sesuatu yang saya dan sub-tim saya hilang? Saya secara eksplisit tidak memberikan informasi terperinci tentang masalah kami karena saya belum tentu mencari solusi untuk itu. Mengingat itu adalah tren umum di tim kami yang lebih besar, saya benar-benar ingin tahu apakah mereka melakukan sesuatu dengan ini.
sumber
Jawaban:
Kata kunci di sini untuk memahami dari mana tim Anda berasal adalah "layanan mikro". Sebaiknya baca konsep itu terlebih dahulu, terutama untuk informasi berikut:
Seperti halnya cara yang relatif baru untuk melakukan sesuatu (dan 5-10 tahun relatif baru dalam hal arsitektur perangkat lunak), Anda akan menemukan bahwa cita-cita dan kenyataan agak berbeda.
Salah satu cita-cita adalah bahwa setiap layanan mikro harus memiliki penyimpanan data sendiri. CATATAN: Saya katakan menyimpan data, bukan database. Ada kasus di mana Anda hanya menginginkan mesin pencari, penyimpanan gumpalan, atau caching sederhana sebagai lawan dari database biasa. Bergantung pada siapa Anda berbicara, cita-cita itu bahkan mungkin pergi ke penyimpanan data per instance layanan-mikro!
Intinya adalah bahwa ketika Anda berbicara tentang pergi ke skala internet, keamanan dan keakraban transaksi ACID (Atomicity, Consistency, Isolasi dan Durability) hanya tidak skala ketika Anda memiliki jutaan pengguna pada satu database. Dengan munculnya NoSQL, paradigma telah bergeser lebih ke BASE (Pada dasarnya Tersedia, Soft state, Konsistensi akhirnya). ( referensi )
Ada dampak mengubah PH tentang cara Anda mengelola data:
Saya tidak bisa menjawab rincian tim Anda atau seberapa besar mereka berniat mendapatkan solusi, tetapi biasanya Anda tidak harus memiliki solusi semua atau tidak sama sekali. Saya tidak akan duduk di sini dan menilai apakah tim membuat pilihan yang tepat. Saya hanya memberi Anda beberapa konteks sehingga Anda setidaknya bisa mengerti dari mana mereka berasal.
sumber
Oke, tidak menjadi insinyur prinsip pada proyek Anda benar-benar harus mengikuti arahannya untuk proyek ini.
Saya akan mendorong Anda untuk bekerja melalui desain sistem Anda sendiri dan membuat prototipe di rumah sehingga Anda memahami pengorbanan apa pun. Lakukan ini untuk pendidikan Anda sendiri dan hanya sebutkan di tempat kerja ketika Anda dapat menunjukkan contoh-contoh kerja.
Pengalaman saya adalah bahwa ada klaim yang menyebabkan kendala memperlambat kinerja database. Dan ya, itu harus, Anda harus memeriksa kendala itu. Namun, ini adalah masalah yang jauh lebih besar ketika database tidak konsisten dan ini akan menyebabkan Anda menulis SQL dan lebih banyak kode untuk mengkompensasi, sering meningkatkan kompleksitas sistem serta memperlambatnya.
3nf, ketika dilakukan dengan tepat, akan membuat database lebih cepat karena lebih banyak yang bisa di-cache karena ada lebih sedikit data yang berlebihan yang disimpan. Namun, dalam pekerjaan Anda saat ini, mungkin tidak ada set data yang cukup besar untuk benar-benar melihat perbedaan kinerja antara database yang dinormalisasi dan yang tidak dinormalisasi.
sumber
Saya pikir mereka takut menciptakan kembali "parodi" lama yang sama yang ada di sana, daripada Integritas Referensial itu sendiri.
Jika Anda dapat membuat case yang solid (alias Kebutuhan Non-Fungsional) untuk kebutuhan atomisitas, maka mereka akan membutuhkan argumen yang bagus dan solid untuk keluar dari menyediakannya.
Mari berharap kamu benar. Saya akan menyarankan bahwa mengandalkan data tetap "cukup kecil" untuk tetap tampil berisiko.
Juga, berapa tingkat perubahan pada Aturan ini? Semakin banyak duplikasi yang Anda miliki, semakin banyak waktu (alias uang) yang akan Anda buang untuk memperbarui hal yang sama di banyak tempat.
sumber
Konsep kunci di balik RDBMS sudah berusia lebih dari 40 tahun. Saat itu penyimpanan sangat mahal dan segala jenis redundansi disukai. Sementara konsep di balik RDBMS masih kuat, gagasan denormalisasi kinerja (untuk mengurangi gabungan) telah menjadi umum diterima dalam beberapa dekade terakhir.
Jadi untuk RDBMS dengan ukuran tertentu, Anda biasanya memiliki desain logis (tanpa redundansi) dan desain fisik (dengan redundansi) untuk kinerja.
Maju cepat ke hari ini di mana penyimpanan murah dan prosesor lebih cepat dari sebelumnya, beberapa tekanan desain itu tidak begitu penting. Pada akhirnya itu adalah panggilan penilaian apakah Anda peduli dengan catatan redundansi dan yatim. Untuk beberapa industri seperti perbankan, kebenaran data sangat penting sehingga sulit untuk melihat bagaimana mereka akan pindah dari RDBMS. Untuk industri lain, pemain baru memasuki pasar sepanjang waktu sehingga pilihannya sangat banyak.
Adapun apakah tim Anda tidak nyaman dengan pembatasan yang dapat dibawa oleh RDBMS - siapa yang tahu? Tentu saja pengembang junior yang saya lihat tidak memiliki RDBMS seperti yang dimiliki oleh generasi sebelumnya, tetapi ini mungkin lebih berkaitan dengan proliferasi teknologi pengembang dan platform basis data.
Tidak ada akhir dari teknologi yang dapat dipelajari pengembang dan mungkin sulit untuk membuat punt yang tepat untuk karier Anda. Tentu saja hari-hari pengembang menjadi jack semua perdagangan sudah lama berlalu - ada terlalu banyak yang bisa dipelajari.
Tapi - untuk pertanyaan di tangan. Menurut pengakuan Anda sendiri, Anda tidak berharap volume data bertambah dan sistem berkinerja baik. Ini akan sangat sulit bagi Anda untuk menjual ide hal-hal rekayasa ulang tanpa manfaat yang dapat dirasakan. Mungkin jika Anda bisa melakukan bukti dari konsep di mana pendekatan RDBMS tidak menuai manfaat, itu akan menjadi cerita yang berbeda.
sumber
Tergantung pada basis data apa yang Anda gunakan.
Dalam RDBMS tradisional, Anda benar. Duplikasi data adalah kekejian. Kolom dan kesetaraan json mereka pasti akan keluar dari sinkronisasi karena tidak ada yang menegakkannya. Dukungan kunci asing dikenal, melakukan pekerjaan yang hebat dalam menggambarkan dan menegakkan hubungan. Dan atomicity sangat penting untuk melakukan hampir semua hal dengan data.
Dalam semacam pengaturan nosql, kurang jelas. Karena tidak ada hubungan yang kuat, penegakan hubungan menjadi kurang penting. Jenis konten json dengan indeks kolom jauh lebih umum pada sistem ini karena tidak ada hubungan yang berarti lebih kecil kemungkinannya untuk keluar dari sinkronisasi. Dan atomicity dibatasi ke tabel tunggal karena itulah cara kerja nosql.
Mana yang lebih baik tergantung pada apa yang sebenarnya Anda lakukan, dan apa yang sebenarnya Anda butuhkan.
Tapi kedengarannya seolah-olah rekan kerja Anda dalam kultus kargo. Mereka digigit oleh hal-hal buruk yang lama jadi sekarang hal-hal yang perlu menjadi hal yang mengkilap baru. Dalam beberapa tahun, begitu mereka digigit oleh benda mengkilap yang baru, diharapkan mereka akan menyadari bahwa SQL vs noSQL adalah serangkaian pengorbanan.
Tetapi mereka tidak akan melakukannya. Semoga Anda akan melakukannya.
sumber