Cara memilih pangkalan data yang sesuai untuk aplikasi anda

Memilih pangkalan data "betul" seringkali penting untuk kejayaan aplikasi. Daripada mengambil nasihat vendor atau menggunakan pangkalan data kerana anda sudah pernah memilikinya, lebih baik mempertimbangkan tujuan dan keperluan asas penyimpanan data.

Ini adalah soalan yang paling penting untuk ditanyakan semasa anda memilih pangkalan data:

  • Berapa banyak data yang anda harapkan dapat disimpan semasa aplikasinya matang?
  • Berapa banyak pengguna yang anda jangkakan untuk mengendalikan secara serentak pada waktu puncak?
  • Apakah ketersediaan, skalabilitas, latensi, throughput, dan konsistensi data yang diperlukan oleh aplikasi anda?
  • Berapa kerapkah skema pangkalan data anda berubah?
  • Apakah taburan geografi populasi pengguna anda?
  • Apakah "bentuk" semula jadi data anda?
  • Adakah aplikasi anda memerlukan pemprosesan transaksi dalam talian (OLTP), pertanyaan analitik (OLAP), atau keduanya?
  • Apakah nisbah bacaan dan tulisan yang anda harapkan dalam pengeluaran?
  • Adakah anda memerlukan pertanyaan geografi dan / atau pertanyaan teks penuh?
  • Apakah bahasa pengaturcaraan pilihan anda?
  • Adakah anda mempunyai belanjawan? Sekiranya demikian, adakah ia akan merangkumi lesen dan kontrak sokongan?
  • Adakah terdapat sekatan undang-undang pada penyimpanan data anda?

Mari kembangkan persoalan dan implikasinya.

Berapa banyak data yang akan anda simpan?

Sekiranya anggaran anda dalam gigabait atau kurang, maka hampir semua pangkalan data akan mengendalikan data anda, dan pangkalan data dalam memori dapat dilaksanakan sepenuhnya. Masih banyak pilihan pangkalan data untuk menangani data dalam julat terabyte (ribuan gigabait).

Sekiranya jawapan anda terdapat dalam petabyte (berjuta-juta gigabyte) atau lebih, maka hanya beberapa pangkalan data yang akan memberi anda perkhidmatan yang baik, dan anda perlu bersedia untuk kos penyimpanan data yang besar, sama ada dalam perbelanjaan modal untuk penyimpanan di tempat atau dalam perbelanjaan operasi untuk penyimpanan awan. Pada skala itu, anda mungkin memerlukan penyimpanan berjenjang sehingga pertanyaan mengenai data "langsung" dapat berjalan dalam memori atau menentang SSD tempatan untuk kelajuan, sementara set data lengkap terletak pada cakera berputar untuk ekonomi.

Berapa banyak pengguna serentak?

Mengira beban dari banyak pengguna serentak sering dianggap sebagai latihan ukuran pelayan yang harus dilakukan sebelum memasang pangkalan data pengeluaran anda. Sayangnya, banyak pangkalan data tidak dapat menangani ribuan pengguna yang menanyakan terabyte atau petabyte data, kerana masalah penskalaan.

Mengira pengguna serentak jauh lebih mudah untuk pangkalan data yang digunakan oleh pekerja daripada pangkalan data awam. Untuk yang terakhir, anda mungkin perlu mempunyai pilihan untuk memperbanyak pelayan untuk beban yang tidak dijangka atau bermusim. Sayangnya, tidak semua pangkalan data menyokong penskalaan mendatar tanpa penyusunan manual dari jadual besar.

Apakah syarat-syarat '-ility' anda?

Dalam kategori ini saya memasukkan ketersediaan, skalabilitas, latensi, throughput, dan konsistensi data, walaupun tidak semua istilah diakhiri dengan "-ility."

Ketersediaan sering menjadi kriteria utama untuk pangkalan data transaksi. Walaupun tidak setiap aplikasi perlu berjalan 24/7 dengan ketersediaan 99,999%, ada yang melakukannya. Beberapa pangkalan data awan menawarkan ketersediaan "lima-sembilan", selagi anda menjalankannya di banyak zon ketersediaan. Pangkalan data di premis biasanya dapat dikonfigurasi untuk ketersediaan tinggi di luar jangka masa penyelenggaraan yang dijadualkan, terutama jika anda mampu menyediakan sepasang pelayan yang aktif.

Skalabiliti, terutama skalabiliti mendatar, secara historis lebih baik untuk pangkalan data NoSQL daripada pangkalan data SQL, tetapi beberapa pangkalan data SQL semakin meningkat. Skalabiliti dinamik jauh lebih mudah dicapai di awan. Pangkalan data dengan skalabilitas yang baik dapat menangani banyak pengguna serentak dengan meningkatkan atau keluar sehingga throughput mencukupi untuk muatan.

Latensi merujuk kepada masa tindak balas pangkalan data dan masa tindak balas dari hujung ke hujung aplikasi. Sebaik-baiknya setiap tindakan pengguna mempunyai masa tindak balas sub-detik; yang sering kali memerlukan pangkalan data untuk bertindak balas dalam lingkungan 100 milisaat untuk setiap transaksi mudah. Pertanyaan analitik boleh memakan masa beberapa saat atau minit. Aplikasi dapat mengekalkan masa tindak balas dengan menjalankan pertanyaan rumit di latar belakang.

Throughput untuk pangkalan data OLTP biasanya diukur dalam transaksi sesaat. Pangkalan data dengan throughput yang tinggi dapat menyokong banyak pengguna serentak.

Konsistensi data biasanya "kuat" untuk pangkalan data SQL, yang bermaksud bahawa semua bacaan mengembalikan data terkini. Konsistensi data mungkin dari "akhirnya" hingga "kuat" untuk pangkalan data NoSQL. Konsistensi akhirnya menawarkan latensi yang lebih rendah, dengan risiko membaca data basi.

Konsistensi adalah "C" dalam sifat ACID yang diperlukan untuk kesahan sekiranya berlaku kesalahan, partisi rangkaian, dan kegagalan daya. Keempat sifat ACID adalah Atomisiti, Ketekalan, Pengasingan, dan Ketahanan.

Adakah skema pangkalan data anda stabil?

Sekiranya skema pangkalan data anda tidak mungkin berubah secara signifikan dari masa ke masa, dan anda mahukan kebanyakan bidang mempunyai jenis yang konsisten dari rekod ke rakaman, maka pangkalan data SQL akan menjadi pilihan yang baik untuk anda. Jika tidak, pangkalan data NoSQL, beberapa di antaranya bahkan tidak menyokong skema, mungkin lebih baik untuk aplikasi anda. Terdapat pengecualian, namun. Sebagai contoh, Rockset memungkinkan untuk pertanyaan SQL tanpa mengenakan skema tetap atau jenis yang konsisten pada data yang diimportnya.

Taburan pengguna secara geografi

Apabila pengguna pangkalan data anda berada di seluruh dunia, kecepatan cahaya memberikan had yang lebih rendah pada latensi pangkalan data untuk pengguna jauh kecuali anda menyediakan pelayan tambahan di wilayah mereka. Beberapa pangkalan data membolehkan pelayan baca-tulis diedarkan; yang lain menawarkan pelayan hanya baca yang diedarkan, dengan semua penulisan terpaksa melalui pelayan induk tunggal. Taburan geografi menjadikan pertukaran antara konsistensi dan kependaman semakin sukar.

Sebilangan besar pangkalan data yang menyokong nod yang diedarkan secara global dan konsistensi yang kuat menggunakan kumpulan konsensus untuk mempercepat penulisan tanpa merosakkan konsistensi secara serius, biasanya menggunakan algoritma Paxos (Lamport, 1990) atau Raft (Ongaro dan Ousterhout, 2013). Pangkalan data NoSQL yang diedarkan yang akhirnya konsisten biasanya menggunakan replikasi peer-to-peer yang tidak sepakat, yang boleh menyebabkan konflik apabila dua replika menerima penulisan serentak ke catatan yang sama, konflik yang biasanya diselesaikan secara heuristik.

Bentuk data

Pangkalan data SQL secara klasik menyimpan data yang ditaip kuat dalam jadual segi empat dengan baris dan lajur. Mereka bergantung pada hubungan yang ditentukan antara jadual, menggunakan indeks untuk mempercepat pertanyaan yang dipilih, dan menggunakan BERGABUNG untuk meminta beberapa jadual sekaligus. Pangkalan data dokumen biasanya menyimpan JSON bertaip lemah yang mungkin merangkumi tatasusunan dan dokumen bersarang. Pangkalan data grafik sama ada menyimpan bucu dan tepi, atau tiga kali ganda, atau quad. Kategori pangkalan data NoSQL yang lain merangkumi kedai nilai-kunci dan kolumnar.

Kadang kala data dihasilkan dalam bentuk yang juga berfungsi untuk analisis; kadang-kadang tidak, dan transformasi akan diperlukan. Kadang-kadang satu jenis pangkalan data dibina di atas yang lain. Sebagai contoh, kedai nilai utama dapat mendasari hampir semua jenis pangkalan data.

OLTP, OLAP, atau HTAP?

Untuk menguraikan akronim di atas, persoalannya adalah apakah aplikasi anda memerlukan pangkalan data untuk transaksi, analisis, atau keduanya. Memerlukan urus niaga pantas menunjukkan kelajuan menulis cepat dan indeks minimum. Analisis yang memerlukan menunjukkan kelajuan membaca yang cepat dan banyak indeks. Sistem hibrid menggunakan pelbagai muslihat untuk menyokong kedua-dua keperluan, termasuk memiliki kedai transaksional utama yang memberi makan kepada kedai analisis sekunder melalui replikasi.

Nisbah baca / tulis

Sebilangan pangkalan data lebih pantas membaca dan bertanya, dan yang lain lebih cepat menulis. Gabungan bacaan dan tulisan yang anda harapkan dari aplikasi anda adalah nombor berguna untuk dimasukkan dalam kriteria pemilihan pangkalan data anda, dan dapat memandu usaha penanda aras anda. Pilihan jenis indeks yang optimum berbeza antara aplikasi baca-berat (biasanya B-tree) dan aplikasi tulis-berat (selalunya pohon gabungan berstruktur log, alias pohon LSM).

Indeks dan pertanyaan geospatial

Sekiranya anda mempunyai data geografi atau geometri dan anda ingin melakukan pertanyaan yang cekap untuk mencari objek di dalam sempadan atau objek dalam jarak tertentu dari lokasi, anda memerlukan indeks yang berbeza daripada yang anda lakukan untuk data hubungan biasa. R-tree sering menjadi pilihan utama untuk indeks geospasial, tetapi terdapat lebih dari selusin struktur data indeks geospasial yang mungkin. Terdapat beberapa dozen pangkalan data yang menyokong data spatial; kebanyakan menyokong sebilangan atau semua standard Open Geospatial Consortium.

Indeks dan pertanyaan teks penuh

Begitu juga, carian penuh teks bidang yang cekap memerlukan indeks yang berbeza daripada data hubungan atau geospasial. Biasanya, anda membina indeks senarai terbalik dari kata-kata bertanda dan mencari untuk mengelakkan melakukan imbasan jadual yang mahal.

Bahasa pengaturcaraan pilihan

Walaupun kebanyakan pangkalan data menyokong API untuk banyak bahasa pengaturcaraan, bahasa pengaturcaraan pilihan dalam aplikasi anda kadang-kadang dapat mempengaruhi pilihan pangkalan data anda. Sebagai contoh, JSON adalah format data semula jadi untuk JavaScript, jadi anda mungkin ingin memilih pangkalan data yang menyokong jenis data JSON untuk aplikasi JavaScript. Apabila anda menggunakan bahasa pengaturcaraan yang ditaip dengan kuat, anda mungkin ingin memilih pangkalan data yang ditaip kuat.

Kekangan belanjawan

Pangkalan data merangkumi harga dari percuma hingga sangat mahal. Banyak pangkalan data mempunyai versi percuma dan berbayar, dan kadang-kadang mempunyai lebih dari satu tahap penawaran berbayar, misalnya menawarkan versi Perusahaan dan masa respons perkhidmatan yang berbeza. Di samping itu, beberapa pangkalan data tersedia di cloud dengan syarat bayar-semasa-anda-pergi.

Sekiranya anda memilih pangkalan data sumber terbuka yang percuma, anda mungkin harus melepaskan sokongan vendor. Selagi anda mempunyai kepakaran di dalam rumah, itu mungkin tidak mengapa. Sebaliknya, mungkin lebih produktif bagi orang anda untuk menumpukan perhatian pada aplikasi dan menyerahkan pentadbiran dan penyelenggaraan pangkalan data kepada vendor atau penyedia awan.

Sekatan undang-undang

Terdapat banyak undang-undang mengenai keselamatan dan privasi data. Di EU, GDPR mempunyai implikasi luas untuk privasi, perlindungan data, dan lokasi data. Di AS, HIPAA mengatur maklumat perubatan, dan GLBA mengatur cara institusi kewangan menangani maklumat peribadi pelanggan. Di California, CCPA baru meningkatkan hak privasi dan perlindungan pengguna.

Beberapa pangkalan data mampu menangani data dengan cara yang mematuhi beberapa atau semua peraturan ini, selagi anda mengikuti amalan terbaik. Pangkalan data lain mempunyai kekurangan yang menjadikannya sangat sukar untuk menggunakannya untuk maklumat yang dapat dikenal pasti secara peribadi, tidak kira seberapa berhati-hati anda.

Jujur, itu adalah senarai panjang faktor yang perlu dipertimbangkan ketika memilih pangkalan data, mungkin lebih banyak daripada yang anda ingin pertimbangkan. Walaupun begitu, perlu untuk menjawab semua soalan dengan sebaik mungkin dari pasukan anda sebelum anda berisiko melaksanakan projek anda dengan pangkalan data yang ternyata tidak mencukupi atau terlalu mahal.