Bagaimana memilih database yang tepat untuk aplikasi Anda

Memilih database yang "tepat" sering kali sangat penting untuk keberhasilan aplikasi. Daripada mengikuti saran vendor atau menggunakan database karena Anda sudah memilikinya, sebaiknya pertimbangkan tujuan dan persyaratan dasar penyimpanan data.

Ini adalah pertanyaan paling penting untuk ditanyakan saat Anda memilih database:

  • Berapa banyak data yang Anda harapkan untuk disimpan saat aplikasi sudah matang?
  • Berapa banyak pengguna yang Anda harapkan untuk menangani secara bersamaan pada beban puncak?
  • Ketersediaan, skalabilitas, latensi, throughput, dan konsistensi data apa yang dibutuhkan aplikasi Anda?
  • Seberapa sering skema database Anda berubah?
  • Bagaimana distribusi geografis dari populasi pengguna Anda?
  • Apa "bentuk" alami dari data Anda?
  • Apakah aplikasi Anda memerlukan pemrosesan transaksi online (OLTP), kueri analitik (OLAP), atau keduanya?
  • Berapa rasio pembacaan dan penulisan yang Anda harapkan dalam produksi?
  • Apakah Anda memerlukan kueri geografis dan / atau kueri teks lengkap?
  • Apa bahasa pemrograman pilihan Anda?
  • Apakah Anda memiliki anggaran? Jika ya, apakah itu akan mencakup lisensi dan kontrak dukungan?
  • Apakah ada batasan hukum pada penyimpanan data Anda?

Mari kita kembangkan pertanyaan-pertanyaan itu dan implikasinya.

Berapa banyak data yang akan Anda simpan?

Jika perkiraan Anda dalam gigabyte atau kurang, maka hampir semua database akan menangani data Anda, dan database dalam memori sepenuhnya dapat dilakukan. Masih banyak pilihan database untuk menangani data dalam kisaran terabyte (ribuan gigabyte).

Jika jawaban Anda dalam petabyte (jutaan gigabyte) atau lebih, maka hanya beberapa database yang akan membantu Anda dengan baik, dan Anda perlu bersiap untuk biaya penyimpanan data yang signifikan, baik dalam pengeluaran modal untuk penyimpanan lokal atau dalam pengeluaran operasional untuk penyimpanan awan. Pada skala itu, Anda mungkin menginginkan penyimpanan bertingkat sehingga kueri pada data "langsung" dapat berjalan dalam memori atau terhadap SSD lokal untuk kecepatan, sementara kumpulan data lengkap berada pada disk berputar untuk penghematan.

Berapa banyak pengguna secara bersamaan?

Memperkirakan beban dari banyak pengguna secara bersamaan sering dianggap sebagai latihan ukuran server yang harus dilakukan tepat sebelum menginstal database produksi Anda. Sayangnya, banyak database tidak dapat menangani ribuan pengguna yang meminta data berukuran terabyte atau petabyte, karena masalah penskalaan.

Memperkirakan pengguna secara bersamaan jauh lebih mudah untuk database yang digunakan oleh karyawan daripada untuk database publik. Untuk yang terakhir, Anda mungkin perlu memiliki opsi untuk menskalakan beberapa server untuk muatan yang tidak terduga atau musiman. Sayangnya, tidak semua database mendukung penskalaan horizontal tanpa sharding manual yang memakan waktu untuk tabel besar.

Apa persyaratan '-ility' Anda?

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

Ketersediaan sering kali menjadi kriteria utama untuk database transaksional. Meskipun tidak semua aplikasi perlu dijalankan 24/7 dengan ketersediaan 99,999%, beberapa aplikasi memerlukannya. Beberapa database cloud menawarkan ketersediaan "lima sembilan", selama Anda menjalankannya di beberapa zona ketersediaan. Basis data di lokasi biasanya dapat dikonfigurasi untuk ketersediaan tinggi di luar periode pemeliharaan terjadwal, terutama jika Anda mampu untuk mengatur sepasang server aktif-aktif.

Skalabilitas, terutama skalabilitas horizontal, secara historis lebih baik untuk database NoSQL daripada database SQL, tetapi beberapa database SQL sedang mengejar. Skalabilitas dinamis jauh lebih mudah dicapai di cloud. Database dengan skalabilitas yang baik dapat menangani banyak pengguna secara bersamaan dengan memperbesar atau memperkecil hingga throughput mencukupi untuk beban.

Latensi mengacu pada waktu respons database dan waktu respons ujung ke ujung aplikasi. Idealnya, setiap tindakan pengguna akan memiliki waktu respons sepersekian detik; yang sering kali berarti membutuhkan database untuk merespons dalam waktu kurang dari 100 milidetik untuk setiap transaksi sederhana. Kueri analitik seringkali memerlukan beberapa detik atau menit. Aplikasi dapat menghemat waktu respons dengan menjalankan kueri rumit di latar belakang.

Throughput untuk database OLTP biasanya diukur dalam transaksi per detik. Database dengan throughput tinggi dapat mendukung banyak pengguna secara bersamaan.

Konsistensi data biasanya "kuat" untuk database SQL, yang berarti bahwa semua pembacaan mengembalikan data terbaru. Konsistensi data dapat berupa apa saja mulai dari "akhirnya" hingga "kuat" untuk database NoSQL. Konsistensi akhirnya menawarkan latensi yang lebih rendah, dengan risiko membaca data usang.

Konsistensi adalah "C" dalam properti ACID yang diperlukan untuk validitas jika terjadi kesalahan, partisi jaringan, dan listrik mati. Empat sifat ACID adalah Atomicity, Consistency, Isolation, dan Durability.

Apakah skema database Anda stabil?

Jika skema database Anda tidak mungkin berubah secara signifikan dari waktu ke waktu, dan Anda ingin sebagian besar bidang memiliki tipe yang konsisten dari satu catatan ke catatan lain, maka database SQL akan menjadi pilihan yang baik untuk Anda. Jika tidak, database NoSQL, beberapa di antaranya bahkan tidak mendukung skema, mungkin lebih baik untuk aplikasi Anda. Namun, ada pengecualian. Misalnya, Rockset memungkinkan kueri SQL tanpa memaksakan skema tetap atau tipe yang konsisten pada data yang diimpornya.

Distribusi geografis pengguna

Ketika pengguna database Anda ada di seluruh dunia, kecepatan cahaya memberlakukan batas yang lebih rendah pada latensi database untuk pengguna jarak jauh kecuali Anda menyediakan server tambahan di wilayah mereka. Beberapa database memungkinkan server baca-tulis terdistribusi; yang lain menawarkan server read-only terdistribusi, dengan semua penulisan yang dipaksa melalui satu server master. Distribusi geografis membuat trade-off antara konsistensi dan latensi semakin sulit.

Sebagian besar database yang mendukung node yang didistribusikan secara global dan konsistensi yang kuat menggunakan kelompok konsensus untuk mempercepat penulisan tanpa menurunkan konsistensi secara serius, biasanya menggunakan algoritma Paxos (Lamport, 1990) atau Raft (Ongaro dan Ousterhout, 2013). Database NoSQL terdistribusi yang akhirnya konsisten biasanya menggunakan replikasi non-konsensus, peer-to-peer, yang dapat menyebabkan konflik ketika dua replika menerima penulisan bersamaan ke rekaman yang sama, konflik yang biasanya diselesaikan secara heuristik.

Bentuk data

Database SQL secara klasik menyimpan data yang diketik dengan kuat dalam tabel persegi panjang dengan baris dan kolom. Mereka mengandalkan hubungan yang ditentukan antar tabel, menggunakan indeks untuk mempercepat kueri yang dipilih, dan menggunakan GABUNG untuk membuat kueri beberapa tabel sekaligus. Database dokumen biasanya menyimpan JSON dengan tipe lemah yang mungkin menyertakan array dan dokumen bertingkat. Database grafik menyimpan simpul dan tepi, atau tripel, atau paha depan. Kategori database NoSQL lainnya termasuk penyimpanan nilai-kunci dan kolom.

Terkadang data dibuat dalam bentuk yang juga dapat digunakan untuk analisis; terkadang tidak, dan transformasi akan diperlukan. Terkadang satu jenis database dibangun di atas yang lain. Misalnya, penyimpanan nilai kunci dapat mendasari hampir semua jenis database.

OLTP, OLAP, atau HTAP?

Untuk menguraikan akronim di atas, pertanyaannya adalah apakah aplikasi Anda memerlukan database untuk transaksi, analisis, atau keduanya. Membutuhkan transaksi cepat menyiratkan kecepatan tulis cepat dan indeks minimal. Analisis yang dibutuhkan menyiratkan kecepatan baca yang cepat dan banyak indeks. Sistem hibrid menggunakan berbagai trik untuk mendukung kedua persyaratan, termasuk memiliki penyimpanan transaksional utama yang memberi makan penyimpanan analisis sekunder melalui replikasi.

Rasio baca / tulis

Beberapa database lebih cepat dalam membaca dan membuat kueri, dan yang lainnya lebih cepat dalam menulis. Campuran baca dan tulis yang Anda harapkan dari aplikasi Anda adalah angka yang berguna untuk disertakan dalam kriteria pemilihan database Anda, dan dapat memandu upaya tolok ukur Anda. Pilihan tipe indeks yang optimal berbeda antara aplikasi read-heavy (biasanya B-tree) dan aplikasi write-heavy (seringkali pohon gabungan terstruktur log, alias pohon LSM).

Indeks dan kueri geospasial

Jika Anda memiliki data geografis atau geometris dan Anda ingin menjalankan kueri yang efisien untuk menemukan objek di dalam batas atau objek dalam jarak tertentu dari suatu lokasi, Anda memerlukan indeks yang berbeda dari yang Anda perlukan untuk data relasional biasa. Pohon-R sering kali menjadi pilihan yang disukai untuk indeks geospasial, tetapi ada lebih dari selusin kemungkinan struktur data indeks geospasial lainnya. Ada beberapa lusin database yang mendukung data spasial; sebagian besar mendukung beberapa atau semua standar Konsorsium Geospasial Terbuka.

Indeks dan kueri teks lengkap

Demikian pula, pencarian teks lengkap bidang teks yang efisien memerlukan indeks yang berbeda dari data relasional atau geospasial. Biasanya, Anda membuat indeks daftar kata-kata yang diberi token dan menelusurinya untuk menghindari pemindaian tabel yang mahal.

Bahasa pemrograman yang disukai

Meskipun sebagian besar database mendukung API untuk banyak bahasa pemrograman, bahasa pemrograman yang disukai dalam aplikasi Anda terkadang dapat memengaruhi pilihan database Anda. Misalnya, JSON adalah format data natural untuk JavaScript, jadi Anda mungkin ingin memilih database yang mendukung tipe data JSON untuk aplikasi JavaScript. Saat Anda menggunakan bahasa pemrograman yang diketik dengan kuat, Anda mungkin ingin memilih database yang diketik dengan kuat.

Kendala anggaran

Harga database berkisar dari yang gratis hingga yang sangat mahal. Banyak database memiliki versi gratis dan berbayar, dan terkadang memiliki lebih dari satu tingkat penawaran berbayar, misalnya menawarkan versi Perusahaan dan waktu respons layanan yang berbeda. Selain itu, beberapa database tersedia di cloud dengan ketentuan bayar sesuai pemakaian.

Jika Anda memilih database open source gratis, Anda mungkin harus melepaskan dukungan vendor. Selama Anda memiliki keahlian sendiri, itu mungkin bagus. Di sisi lain, mungkin akan lebih produktif bagi karyawan Anda untuk berkonsentrasi pada aplikasi dan menyerahkan administrasi dan pemeliharaan database kepada vendor atau penyedia cloud.

Pembatasan hukum

Ada banyak hukum tentang keamanan dan privasi data. Di UE, GDPR memiliki implikasi luas untuk privasi, perlindungan data, dan lokasi data. Di AS, HIPAA mengatur informasi medis, dan GLBA mengatur cara lembaga keuangan menangani informasi pribadi pelanggan. Di California, CCPA baru meningkatkan hak privasi dan perlindungan konsumen.

Beberapa database mampu menangani data dengan cara yang sesuai dengan beberapa atau semua peraturan ini, selama Anda mengikuti praktik terbaik. Basis data lain memiliki kekurangan yang membuatnya sangat sulit untuk digunakan sebagai informasi pengenal pribadi, tidak peduli seberapa berhati-hati Anda.

Sejujurnya, itu adalah daftar panjang faktor yang perlu dipertimbangkan saat memilih database, mungkin lebih dari yang ingin Anda pertimbangkan. Namun demikian, ada baiknya mencoba menjawab semua pertanyaan dengan kemampuan terbaik tim Anda sebelum Anda mengambil risiko menyerahkan proyek Anda ke database yang ternyata tidak memadai atau terlalu mahal.