Pangkalan Data Relasi vs NoSQL: Cara Memilih Asas yang Betul untuk Sistem Anda

Setiap pangkalan data menyimpan data. Di situlah persamaannya berakhir. Pangkalan data relasi dan pangkalan data NoSQL mewakili falsafah yang berbeza secara asas tentang bagaimana data harus disusun, disimpan, dan ditanya — dan perbezaan-perbezaan itu mengalir ke setiap lapisan sistem yang dibina di atasnya.

Ini bukan soal lama berbanding baru, atau mudah berbanding canggih. Kedua-dua kategori mengandungi sistem yang matang dan terbukti kukuh digunakan pada skala yang luar biasa. Persoalannya ialah kesesuaian untuk tujuan: model mana yang sesuai dengan bentuk data anda, corak capaian aplikasi anda, dan jaminan konsistensi yang diperlukan pengguna anda.

Apa sebenarnya database relasi itu

Pangkalan data relasi mengatur data ke dalam jadual — baris dan lajur dengan hubungan yang ditakrifkan secara eksplisit di antara mereka. Perkataan "relasi" dalam namanya bukan merujuk kepada fakta bahawa jadual saling berkaitan (walaupun ia berkaitan), tetapi kepada konsep matematik relasi: satu set tupel yang berkongsi atribut yang sama. Asas teori ini, yang dibangunkan oleh Edgar Codd di IBM pada tahun 1970, terbukti sangat tahan lama.

Ciri teras pangkalan data relasi adalah:

Skema tetap. Sebelum anda memasukkan data, anda mentakrifkan struktur: jadual mana yang wujud, lajur mana yang terdapat dalam setiap jadual, jenis data apa yang diterima oleh setiap lajur, dan sekatan mana yang terpakai (NOT NULL, UNIQUE, CHECK, dan sebagainya). Skema adalah kontrak antara aplikasi dan pangkalan data anda.

Penormalan. Data diatur untuk menghapuskan lebihan. Nama pelanggan muncul sekali, dalam jadual pelanggan. Setiap pesanan merujuk kepada pelanggan itu melalui ID. Jika nama berubah, ia berubah di satu tempat sahaja. Ini bukan sekadar kemas — ia adalah jaminan konsistensi.

Transaksi ACID. Atomikiti, Konsistensi, Pengasingan, dan Ketahanan. Satu transaksi sama ada diselesaikan sepenuhnya atau langsung tidak. Jika anda memindahkan wang dari satu akaun ke akaun lain, debit dan kredit berlaku serentak atau tiada satu pun yang berlaku. Pangkalan data menguatkuasakan ini di peringkat enjin.

SQL. Structured Query Language adalah antara muka sejagat untuk pangkalan data relasi. Ia bersifat deklaratif — anda menerangkan apa yang anda mahukan, bukan bagaimana untuk mendapatkannya — dan ia sangat ekspresif. Sambungan, pengagregatan, fungsi tetingkap, anak pertanyaan, CTE: keluasan penuh SQL memberi anda alat untuk mengajukan soalan kompleks kepada data anda tanpa menulis kod aplikasi untuk melakukan kerja tersebut.

Pangkalan data relasi utama — PostgreSQL, MySQL, SQL Server, Oracle — berkongsi ciri-ciri ini sambil berbeza dari segi set ciri khusus mereka, ciri prestasi, dan model pelesenan. PostgreSQL khususnya telah menjadi pilihan lalai untuk projek baharu, menggabungkan pematuhan piawaian yang ketat dengan set ciri yang luar biasa.

Apa sebenarnya pangkalan data NoSQL itu

"NoSQL" adalah istilah umum yang merangkumi beberapa kategori pangkalan data yang berbeza, yang disatukan terutamanya oleh apa yang mereka bukan: mereka bukan relasi, dan mereka tidak menggunakan SQL sebagai antara muka utama mereka (walaupun sesetengahnya menyokong bahasa pertanyaan seperti SQL). Istilah ini lebih baik difahami sebagai "bukan hanya SQL" — satu pengiktirafan bahawa model relasi bukanlah satu-satunya pendekatan yang sah.

Kategori utama NoSQL ialah:

Pangkalan data dokumen menyimpan data sebagai dokumen — biasanya JSON atau BSON — di mana setiap dokumen boleh mempunyai struktur yang berbeza. MongoDB adalah yang paling meluas digunakan; lain-lain termasuk CouchDB dan Firestore. Tiada jadual dan tiada skema tetap; satu "koleksi" dokumen boleh mengandungi rekod dengan medan yang sama sekali berbeza.

Penyimpanan kunci-nilai adalah model paling mudah: setiap rekod adalah satu nilai yang boleh dialamatkan oleh kunci unik. Redis adalah contoh dominan, digunakan secara meluas untuk pengeksesan, penyimpanan sesi, dan papan pendahulu masa nyata. DynamoDB juga beroperasi terutamanya sebagai penyimpanan kunci-nilai, dengan keupayaan dokumen dilapiskan di atasnya.

Simpanan keluarga lajur mengatur data mengikut lajur dan bukannya baris, yang membolehkan bacaan lajur tertentu yang sangat cekap merentasi jutaan baris. Apache Cassandra dan HBase adalah contoh utama. Model ini direka untuk beban kerja yang banyak menulis dan berisikan volum tinggi di mana corak pertanyaan diketahui terlebih dahulu.

Pangkalan data graf memodelkan data sebagai nod dan tepi — entiti dan hubungan di antara mereka. Neo4j adalah contoh terkemuka. Apabila hubungan antara entiti menjadi subjek utama pertanyaan anda — rangkaian sosial, enjin cadangan, pengesanan penipuan — pangkalan data graf boleh menyatakan pertanyaan tersebut secara semula jadi dengan cara yang memerlukan SQL yang sangat rekuratif.

Pangkalan data siri masa dioptimumkan untuk data yang diindeks mengikut masa: InfluxDB, TimescaleDB, Prometheus. Bacaan sensor, tick kewangan, metrik aplikasi — data di mana cop masa sentiasa menjadi kunci utama dan pertanyaan julat mengikut masa adalah corak akses yang dominan.

Perbezaan struktur yang memacu segala-galanya

Perbezaan paling mendalam antara pangkalan data relasi dan NoSQL bukanlah sintaks atau skala — ia adalah hubungan antara struktur data dan fleksibiliti pertanyaan.

Pangkalan data relasi memberikan anda fleksibiliti pertanyaan maksimum sebagai pertukaran untuk disiplin skema awal. Kerana data dinormalisasi dan bertipe, anda boleh mengemukakan hampir sebarang soalan kepadanya semasa pertanyaan. Anda boleh menggabungkan jadual dengan cara yang tidak pernah anda jangkakan semasa anda mereka bentuk skema. Anda boleh mengagregat merentas dimensi yang anda tambah berbulan-bulan selepas reka bentuk awal. Skema mengehadkan data, tetapi bahasa pertanyaan memberi anda kebebasan.

Pangkalan data NoSQL membuat pertukaran yang sebaliknya. Ia memberi anda fleksibiliti dalam cara anda menyusun dan menulis data, sebagai pertukaran untuk corak pertanyaan yang lebih terhad. Pangkalan data dokumen membolehkan anda menyimpan data dalam apa jua bentuk tanpa migrasi. Tetapi, pertanyaan merentas dokumen dengan cekap memerlukan anda mengetahui corak akses anda terlebih dahulu dan mereka bentuk struktur data anda berdasarkan corak tersebut.

Inilah ketegangan teras: fleksibiliti skema lwn. fleksibiliti pertanyaan. Anda boleh mempunyai kedua-duanya, tetapi hanya sehingga tahap tertentu. Model pangkalan data yang anda pilih mencerminkan penukaran yang mana lebih boleh diterima untuk kes penggunaan anda.

Teorem CAP dan mengapa ia penting

Sistem teragih tidak dapat menjamin Konsistensi, Ketersediaan, dan Ketahanan Pemisahan secara serentak — ia hanya dapat mencapai maksimum dua daripada tiga. Inilah teorem CAP, dan ia adalah asas teori untuk memahami mengapa pangkalan data relasi dan NoSQL berkelakuan berbeza di bawah keadaan kegagalan.

Pangkalan data relasi secara tradisional mengutamakan Konsistensi dan Ketoleransi Pemisahan. Setiap bacaan mencerminkan penulisan terkini. Jika pemisahan rangkaian berlaku dan pangkalan data tidak dapat menjamin konsistensi, ia akan menolak untuk menyajikan data lapuk — ia menjadi tidak tersedia dan bukannya tidak tepat.

Banyak pangkalan data NoSQL — terutamanya yang direka untuk pengagihan mendatar seperti Cassandra dan DynamoDB — mengutamakan Ketersediaan dan Ketahanan Pemisahan. Mereka akan menyajikan data walaupun semasa pemisahan rangkaian, menerima bahawa beberapa bacaan mungkin mengembalikan nilai lapuk. Ini adalah "konsistensi akhirnya": semua nod akan akhirnya bersepakat pada nilai yang sama, tetapi terdapat satu jendela di mana mereka mungkin tidak bersetuju.

Implikasi praktikalnya: jika aplikasi anda tidak boleh menerima kemungkinan membaca data lapuk — baki bank, kiraan inventori, rekod perubatan — anda memerlukan konsistensi kukuh. Jika aplikasi anda boleh bertolak ansur dengan ketidakseragaman ringkas sebagai pertukaran untuk sentiasa tersedia — suapan media sosial, katalog produk, profil pengguna — ketidakseragaman akhirnya boleh diterima dan memberi anda kebebasan seni bina.

Contoh sebenar: apabila pilihan yang betul membuat perbezaan

GitHub: PostgreSQL di tengah platform global

GitHub menjalankan salah satu platform kerjasama perisian terbesar di dunia menggunakan PostgreSQL — berjuta-juta repositori, berbilion peristiwa, pertanyaan relasi kompleks merentas pengguna, organisasi, repositori, permintaan tarik, isu, dan komen. Model relasi sesuai dengan domain ini: hubungan antara entiti-entiti ini adalah produk. Pull request dimiliki oleh repositori, dihasilkan oleh pengguna, disemak oleh pengguna lain, menutup isu, dan mencetuskan saluran CI.

Selama bertahun-tahun, GitHub mengendalikan satu instans PostgreSQL utama dengan replika baca. Apabila skala berkembang, mereka memperkenalkan Vitess (lapisan pemecahan MySQL untuk beberapa beban kerja) dan ProxySQL untuk pengurusan sambungan — tetapi teras relasional kekal. Pengajarannya bukan bahawa PostgreSQL berskala tanpa had tanpa usaha. Ia adalah bahawa model relasi adalah sesuai untuk domain yang ditakrifkan oleh hubungan, dan usaha yang dilaburkan untuk mengeskalakannya berbaloi kerana migrasi ke model data yang berbeza akan menjadi lebih mahal.

Twitter: migrasi menyakitkan daripada MySQL ke seni bina campuran

Twitter bermula dengan MySQL dan menghadapi krisis penskalaan yang banyak didokumenkan apabila pertumbuhan pengguna melebihi apa yang boleh dilayani oleh satu pangkalan data relasi. Masalah teras ialah graf sosial — hubungan pengikut/dipengikut antara ratusan juta pengguna — dan masalah penyebaran garis masa: apabila seorang pengguna dengan 10 juta pengikut men-tweet, tweet itu perlu muncul dalam 10 juta garis masa hampir serta-merta.

Model relasi, seperti yang telah dilaksanakan oleh Twitter, tidak dapat memenuhi fanout penulisan ini pada kelajuan yang diperlukan. Twitter memindahkan graf sosial ke storan khusus dalam memori dan akhirnya mengguna pakai Manhattan (storan nilai-kunci teragih dalaman mereka) untuk garis masa dan Cassandra untuk beban kerja lain yang banyak menulis.

Pengajaran di sini adalah halus. Data teras Twitter — ciapan, pengguna, hubungan — pada dasarnya adalah relasional. Masalahnya bukan model data; ia adalah jumlah penulisan dan penyebaran pada skala yang memerlukan pengagihan. Pemindahan itu mahal, kompleks dari segi teknikal, dan memerlukan pelaburan kejuruteraan selama bertahun-tahun. Pada skala Twitter, ia adalah keputusan yang tepat. Pada skala hampir mana-mana aplikasi lain, ia akan terlalu awal.

MongoDB: kisah amaran tentang fleksibiliti skema

Pada awal 2010-an, apabila MongoDB semakin popular dengan pantas, banyak pasukan menggunakannya terutamanya kerana fleksibiliti skema — keupayaan untuk mula menyimpan data tanpa mentakrifkan skema terlebih dahulu. Untuk prototaip dan pembangunan peringkat awal, ini benar-benar mempercepatkan iterasi.

Masalah timbul apabila sistem menjadi matang. Tanpa penguatkuasaan skema, ketidakkonsistenan data terkumpul secara beransur-ansur. Medan yang sepatutnya diwajibkan kadangkala tiada. Nilai yang sepatutnya adalah integer kadangkala adalah rentetan. Carian yang menganggap struktur konsisten akan mengembalikan keputusan yang tidak dijangka. Pasukan mendapati diri mereka menulis pengesahan peringkat aplikasi yang meluas yang sepatutnya dikuatkuasakan secara percuma oleh pangkalan data.

Ini bukan kegagalan MongoDB sebagai pangkalan data — ia adalah alat yang sesuai untuk banyak kes penggunaan. Ia adalah kegagalan andaian bahawa fleksibiliti skema semestinya baik tanpa syarat. Fleksibiliti itu menangguhkan kos untuk memikirkan tentang struktur data; ia tidak menghapuskan kos tersebut. Pasukan yang menggunakan MongoDB tanpa disiplin mendapati diri mereka melaksanakan versi lemah skema relasi dalam kod aplikasi, tanpa jaminan yang akan disediakan oleh pangkalan data relasi.

Amazon DynamoDB: kisah kejayaan untuk kes penggunaan yang betul

Keret bakul beli-belah Amazon adalah salah satu contoh rujukan NoSQL yang dilaksanakan dengan betul. Keperluan adalah jelas: troli beli-belah perlu sentiasa tersedia (pelanggan harus sentiasa dapat menambah barangan, walaupun semasa kerosakan di peringkat serantau), ia perlu mengendalikan jumlah penulisan yang besar (beratus juta pengguna menambah dan mengeluarkan barangan), dan corak capaian adalah mudah serta diketahui terlebih dahulu (sentiasa capaian melalui ID pelanggan).

Pasukan kejuruteraan Amazon, dalam kertas kerja 2007 yang memberi inspirasi kepada DynamoDB, menerangkan bagaimana mereka sengaja memilih konsistensi beransur-ansur untuk troli tersebut: jika dua peranti menambah barangan pada masa yang sama semasa pemisahan rangkaian, kedua-dua penambahan akan dikekalkan apabila pemisahan itu pulih, walaupun ia bermakna memaparkan keadaan yang sedikit tidak konsisten buat seketika. Troli beli-belah yang sentiasa boleh ditulis — walaupun dengan kos ketidakkonsistenan seketika — lebih bernilai daripada troli yang kadang-kadang tidak tersedia.

Reka bentuk DynamoDB untuk kes penggunaan ini — capaian kunci-nilai yang mudah, corak pertanyaan yang diketahui, ketersediaan berbanding konsistensi — adalah apa yang menjadikannya cemerlang. Aplikasi yang cuba menggunakan DynamoDB sebagai pangkalan data relasi guna umum, menjalankan pertanyaan kompleks merentas pelbagai entiti, sering menghadapi kesukaran.

Airbnb: Elasticsearch untuk carian, PostgreSQL untuk kebenaran

Carian Airbnb — menapis senarai mengikut lokasi, tarikh, harga, kemudahan, dan ketersediaan — adalah pertanyaan yang tiada pangkalan data relasi dapat layan dengan cekap pada skala besar. Gabungan carian geografi, padanan teks penuh, dan penapisan berbilang atribut kompleks merentasi jutaan penyenaraian adalah kes penggunaan yang tepat bagi Elasticsearch.

Airbnb menggunakan Elasticsearch sebagai lapisan carian sambil mengekalkan PostgreSQL sebagai sistem rekod. Apabila sesuatu penyenaraian dikemas kini, perubahan itu ditulis ke PostgreSQL (sumber kebenaran, dengan jaminan ACID penuh) dan kemudian disebarkan secara asinkron ke Elasticsearch (indeks carian, dioptimumkan untuk corak pertanyaan khusus pengalaman carian).

Ini adalah corak seni bina yang matang: gunakan pangkalan data yang tepat untuk setiap keperluan, kekalkan sumber kebenaran yang jelas, dan terima kerumitan operasi dalam mengekalkan pelbagai storan agar selari. Ia berfungsi kerana sempadannya jelas dan komprominya difahami.

Bila hendak memilih pangkalan data relasi

Pangkalan data relasi adalah pilihan lalai yang tepat untuk kebanyakan aplikasi. Kes di mana ia jelas merupakan pilihan yang tepat:

Data anda mempunyai hubungan yang bermakna. Jika entiti dalam sistem anda saling berkaitan antara satu sama lain dengan cara yang penting — pengguna dan kiriman mereka, pesanan dan butiran pesanan mereka, projek dan tugasan mereka — model relasi mewakili hubungan tersebut secara langsung dan membolehkan anda membuat pertanyaan merentasnya dengan cekap.

Anda memerlukan konsistensi yang kukuh. Transaksi kewangan, pengurusan inventori, sistem tempahan, rekod kesihatan — mana-mana bidang di mana bacaan yang salah mempunyai akibat sebenar memerlukan jaminan ACID. Pangkalan data relasi menyediakan ini di peringkat enjin.

Corak pertanyaan anda tidak diketahui sepenuhnya. Jika aplikasi anda perlu menjawab soalan tentang data anda yang tidak dapat anda jangkakan sepenuhnya pada masa reka bentuk, fleksibiliti SQL adalah berharga. Keupayaan untuk menulis pertanyaan ad-hoc terhadap skema yang dinormalisasi dengan baik adalah aset operasi yang penting.

Pasukan anda menguasai SQL. Ini kedengaran remeh tetapi ia tidak. SQL adalah salah satu kemahiran teknikal yang paling meluas difahami dalam kejuruteraan perisian. Setiap pembangun yang anda upah akan mengetahuinya pada tahap tertentu. Pengetahuan operasi — cara menambah indeks, cara membaca pelan pertanyaan, cara mengurus sandaran — mudah diperoleh. Ekosistem alat sudah matang.

Anda tidak pasti apa yang anda perlukan. Apabila ragu-ragu, mulakan dengan PostgreSQL. Adalah lebih mudah untuk memperkenalkan storan khusus kemudian, setelah anda memahami corak akses sebenar anda, daripada memigrasikan daripada storan dokumen kembali ke model relasi apabila data anda ternyata lebih berstruktur daripada yang anda sangka.

Bila hendak memilih NoSQL

NoSQL adalah pilihan yang tepat apabila keperluan khusus tidak dapat dipenuhi oleh model relasi tanpa usaha yang tidak seimbang:

Jumlah tulisan melebihi apa yang boleh ditangani oleh satu nod. Jika aplikasi anda perlu mengekalkan ratusan ribu tulisan setiap saat merentasi sistem yang diedarkan secara geografi, penskalaan mendatar merentasi banyak nod menjadi perlu. Penyimpanan keluarga lajur seperti Cassandra direka untuk tujuan ini; pangkalan data relasi boleh diedarkan tetapi ia bukan mod semula jadi mereka.

Data anda benar-benar tanpa skema atau sangat berubah-ubah. Katalog produk di mana jenis produk yang berbeza mempunyai atribut yang sama sekali berbeza, CMS di mana jenis kandungan berkembang dengan pesat, sistem log di mana skema peristiwa ditakrifkan oleh sistem luaran — kes-kes ini mendapat manfaat daripada penyimpanan dokumen di mana struktur tidak dikuatkuasakan oleh pangkalan data.

Corak akses utama anda ialah carian nilai-kunci pada skala yang melampau. Penyimpanan sesi, penimbal, papan pendahulu masa nyata, bendera ciri — beban kerja di mana anda sentiasa mengakses data dengan satu kunci dan tidak pernah perlu menyambung atau mengagregat akan mendapat manfaat daripada kesederhanaan dan prestasi penyimpanan nilai-kunci.

Anda memodelkan graf. Jika pertanyaan utama anda adalah mengenai menelusuri hubungan — cari semua kawan kepada kawan, kenal pasti laluan terpendek antara dua nod, mengesan kebergantungan bulat — pangkalan data graf akan menyatakan pertanyaan tersebut dengan lebih semula jadi dan melaksanakannya dengan lebih cekap berbanding SQL rekursif.

Anda memerlukan pengoptimuman siri masa. Jutaan bacaan penderia, tick kewangan, atau metrik aplikasi setiap saat, dengan pertanyaan terutamanya merentasi julat masa, lebih sesuai dilayani oleh pangkalan data siri masa khusus berbanding simpanan relasi dengan lajur cop masa.

Realiti berbilang pangkalan data

Perkara paling penting untuk difahami tentang persoalan relasional berbanding NoSQL ialah ia bukan, dalam kebanyakan sistem yang matang, satu pilihan sama ada/atau. Sistem berskala besar secara rutin menggunakan berbilang pangkalan data, setiap satu dipilih untuk beban kerja khusus yang dilayaninya.

PostgreSQL untuk sistem rekod. Redis untuk penimbalan sesi dan had kadar. Elasticsearch untuk carian teks penuh. InfluxDB untuk metrik aplikasi. Setiap pangkalan data dalam susunan ini melakukan apa yang paling mahir, dan lapisan aplikasi menguruskan keseragaman di antara mereka.

Kos operasi bagi kerumitan ini adalah nyata. Setiap pangkalan data tambahan adalah satu lagi sistem untuk dipantau, dicadang, diskalakan, dan difahami. Disiplin kejuruteraan yang diperlukan untuk memastikan pelbagai storan konsisten — menangani senario kegagalan di mana penulisan ke PostgreSQL berjaya tetapi kemas kini Elasticsearch seterusnya gagal — adalah sesuatu yang tidak mudah.

Titik permulaan untuk hampir setiap aplikasi sepatutnya adalah satu pangkalan data relasi tunggal. Tambah storan khusus apabila keperluan tertentu yang difahami dengan baik tidak dapat dipenuhi tanpa mereka. Diversifikasi pangkalan data yang terlalu awal adalah satu bentuk pengoptimuman awal: ia menambah kerumitan sebelum anda memahami sama ada kerumitan itu perlu.

Membuat keputusan

Soalan yang benar-benar penting apabila memilih pangkalan data:

Apakah keperluan konsistensi anda? Jika jawapan kepada "apa yang berlaku jika pengguna membaca data lapuk" adalah "itu adalah masalah serius," anda memerlukan ACID. Jika jawapannya "itu agak menjengkelkan tetapi boleh diterima," anda mempunyai pilihan.

Apakah corak pertanyaan anda? Jika anda tahu dengan tepat bagaimana data anda akan diakses dan corak akses itu mudah serta berkuantiti tinggi, anda boleh mengoptimalkannya. Jika corak akses anda kompleks atau tidak diketahui sepenuhnya, fleksibiliti SQL adalah berharga.

Apakah jumlah penulisan anda? Bagi kebanyakan aplikasi, satu instans PostgreSQL yang ditala dengan baik pada perkakasan yang munasabah boleh mengendalikan beribu-ribu penulisan setiap saat tanpa kesulitan. Kes di mana ini benar-benar tidak mencukupi adalah lebih jarang daripada yang disarankan oleh sensasi NoSQL pada tahun 2010-an.

Apakah bentuk data anda? Data yang sangat seragam dan saling berkaitan rapat sesuai dengan model relasi. Data yang sangat berubah-ubah dan berkaitan secara longgar mungkin lebih sesuai dengan model dokumen.

Apa yang pasukan anda tahu? Kebiasaan operasi itu penting. Pasukan yang memahami PostgreSQL dengan mendalam akan membina sistem yang lebih boleh dipercayai pada PostgreSQL berbanding pangkalan data NoSQL yang sedang mereka pelajari, walaupun pangkalan data NoSQL itu secara teori lebih sesuai.

Pangkalan data relasi telah bertahan lima puluh tahun perubahan teknologi bukan kerana ia sentiasa alat terbaik, tetapi kerana ia adalah pilihan lalai yang sangat baik — fleksibel, boleh dipercayai, difahami dengan baik, dan disokong oleh puluhan tahun pengetahuan operasi. Menjauhinya secara sengaja, dengan pemahaman yang jelas tentang apa yang anda peroleh dan apa yang anda korbankan.