Tim saya takut pada entitas basis data relasional dengan hubungan kunci asing dan saya tidak mengerti mengapa


12

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.


Jawaban atas pertanyaan Anda dalam judul adalah "Mereka takut karena monolit lama di perusahaan Anda". Tetapi tubuh pertanyaan Anda tampaknya menanyakan sesuatu yang sama sekali berbeda, yaitu "Apakah kunci asing memperkenalkan masalah kinerja?"
Christian Hackl

2
Saya ingin tahu berapa% dari RDBMS yang mereka buat dalam kode "app"
Caleth

Apakah pendekatan itu baik atau tidak tergantung pada jenis aplikasi yang Anda bangun, kebutuhannya, dan arahnya (persyaratan, kendala arsitektur) - sesuatu yang tidak dapat kita nilai di sini. Adapun NoSQL - semuanya tentang mendukung salability horisontal besar, dan tentang pengakuan bahwa tidak semua aplikasi memerlukan kendala ketat RDBMS. Untuk mempelajari lebih lanjut, gunakan 3 jawaban teratas di sini sebagai titik awal (ke-2 dan ke-3 lebih mendalam).
Filip Milovanović

2
Jika saya dapat menawarkan beberapa saran non-teknis: nada sedikit turun. Anda melewati banyak penilaian ("ya, dalam dua kolom berbeda dalam tabel yang sama", "desain parodi") pada pekerjaan di mana Anda tidak terlibat dalam keputusan desain dan melakukannya dari posisi pengalaman dunia nyata minimal. . Saya tidak bisa mengatakan Anda benar atau salah karena saya belum melihat proyek, tetapi sistem cenderung menjadi serangkaian kompromi yang mengakibatkan produk jadi fungsional tetapi kurang murni dari konsepsi. Ini akan menjadi lebih jelas ketika karier Anda berkembang dan membuat keputusan itu menjadi bagian dari pekerjaan Anda.
Blrfl

@ Blrfl Sangat baik menempatkan
Robbie Dee

Jawaban:


8

Kata kunci di sini untuk memahami dari mana tim Anda berasal adalah "layanan mikro". Sebaiknya baca konsep itu terlebih dahulu, terutama untuk informasi berikut:

  • Bagaimana seharusnya data disimpan?
  • Prinsip desain?
  • Bagaimana mereka dirancang untuk skala?

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:

  • Hal-hal yang digunakan basis data untuk Anda harus dikelola dalam kode sekarang
  • Lebih mudah untuk menskala dengan melempar lebih banyak contoh layanan mikro ke masalah daripada menambahkan sumber daya "tak terbatas" ke server
  • Anda meningkatkan keandalan dengan biaya peningkatan kompleksitas

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.


+1 Hal-hal hebat - ada banyak seluk-beluk di sekitar layanan microser pasti itu berarti itu bukan hanya kasus pertukaran database.
Robbie Dee

@RobbieDee, setuju. Ada banyak kerumitan di dunia itu, dan tidak semua orang menyetujui detailnya.
Berin Loritsch

Ini seharusnya jawabannya. Sedikit tentang masing-masing microservice yang memiliki penyimpanan data sendiri adalah faktor pembeda. Itu membuat perubahan besar dalam kebutuhan dan solusi penyimpanan data Anda, dan penyimpanan data yang sesuai dengan ACID tidak sebanyak manfaatnya seperti dulu.
Greg Burghardt

7
Ini jawaban yang bagus, dan saya membukanya. Saya hanya akan menunjukkan bahwa apa yang Anda sebut sebagai "skala internet" hanya berlaku untuk perusahaan terbesar ; untuk sebagian besar database perusahaan dan situs web (saya akan mengatakan 95% dari mereka), "normal" database SQL dinormalisasi masih sangat layak.
Robert Harvey

@RobertHarvey, saya setuju dengan sepenuh hati. Saya telah membaca beberapa artikel tentang layanan microser yang menjelaskan tentang apa yang saya tulis. Dalam proyek kami sendiri, kami menggunakan database SQL dengan normalisasi dan batasan yang tepat. Itu akan melukai hati purist, tetapi kenyataannya basis pengguna kami agak kecil (ratusan atau pengguna) dan database belum menjadi masalah kinerja bagi kami.
Berin Loritsch

3

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.


+1 Ide bagus. Dan jika volume terlalu besar untuk mesin dev, sampel 1 dalam N sering dapat menghasilkan wawasan yang bagus juga.
Robbie Dee

2

Saya pikir mereka takut menciptakan kembali "parodi" lama yang sama yang ada di sana, daripada Integritas Referensial itu sendiri.

Dia berpendapat bahwa di tempat-tempat di mana saya menginginkan atomisitas, kita tidak membutuhkannya ...

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.

... alih-alih pertanyaan, kita harus melakukan lebih banyak hal dalam memori. Ini adalah prinsip desain ... Kami tidak mengantisipasi bahwa volume data kami akan tumbuh secara substansial ...

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.


1

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.


1
mengapa ini diturunkan? ini jawaban yang seimbang. pragmatism +1
Dirk Boer

Pragmatisme itu baik, tetapi Anda harus tetap berhati-hati. Mendenormalkan data atas nama kinerja pada awal proyek berbau optimasi prematur. Bukan merekayasa ulang sistem lama yang berfungsi jelas merupakan pilihan pragmatis yang baik, tetapi menolak untuk merancang sistem baru hingga standar industri atas nama "kami selalu melakukan yang sebaliknya dan berfungsi" jauh dari argumen yang bagus .
Vincent Savard

Mendenormalkan data atas nama kinerja pada awal proyek ... Petunjuk: Anda tidak :)
Robbie Dee

1
Nilai RDBMS tidak berasal dari efisiensi disk.
TehShrike

0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.