Bagaimana perusahaan basis data menjaga data mereka tetap lurus

Seiring pengembang mengatasi masalah yang semakin besar, mereka harus menyimpan data dengan cara yang lebih kompleks — menambahkan konstelasi komputer untuk menampung semuanya.

Tetapi menambahkan lebih banyak perangkat keras komputer dapat menyebabkan kebingungan ketika bagian jaringan yang berbeda perlu diakses untuk setiap kueri tertentu, terutama ketika permintaan cepat untuk data sangat umum. Setiap pembaruan basis data harus disiarkan ke semua komputer — terkadang tersebar di berbagai pusat data — sebelum pembaruan selesai.

Data yang kompleks memerlukan solusi yang kompleks

Pengembang ingin memiliki “satu sumber kebenaran” ketika mereka membangun aplikasi, yang merupakan catatan informasi penting. Ini harus dapat memberi tahu mereka nilai terbaru kapan saja.

Memberikan konsistensi ini dengan satu komputer yang menjalankan database itu sederhana. Ketika ada beberapa mesin yang berjalan secara paralel, mendefinisikan satu versi kebenaran bisa menjadi rumit. Jika dua atau lebih perubahan tiba di mesin yang berbeda secara berurutan, tidak ada cara sederhana bagi database untuk memilih mana yang lebih dulu. Ketika komputer melakukan pekerjaan mereka dalam milidetik, urutan perubahan tersebut dapat menjadi ambigu, memaksa database untuk memilih siapa yang mendapatkan kursi pesawat atau tiket konser.

Masalah hanya bertambah dengan ukuran tugas yang diberikan ke database. Semakin banyak pekerjaan membutuhkan database besar yang menjangkau banyak mesin. Mesin ini mungkin ditempatkan di pusat data yang berbeda di seluruh dunia untuk meningkatkan waktu respons dan menambahkan redundansi jarak jauh. Tetapi waktu komunikasi ekstra yang diperlukan sangat meningkatkan kompleksitas ketika pembaruan basis data tiba secara berurutan pada mesin yang berbeda.

Dan masalahnya tidak dapat diselesaikan hanya dengan menyerahkan semuanya kepada yang tinggi -akhir penyedia cloud. Layanan database yang ditawarkan oleh raksasa seperti Amazon AWS, Google Cloud, dan Microsoft Azure semuanya memiliki batasan dalam hal konsistensi, dan mereka mungkin menawarkan beberapa variasi konsistensi untuk dipilih.

Untuk pastikan, beberapa pekerjaan tidak terpengaruh oleh masalah ini. Banyak aplikasi hanya meminta agar basis data melacak nilai yang berkembang perlahan dan tidak berubah — seperti, katakanlah, ukuran tagihan bulanan Anda atau pemenang pertandingan bola musim lalu. Informasi ditulis satu kali, dan semua permintaan berikutnya akan mendapatkan jawaban yang sama.

Pekerjaan lain, seperti melacak jumlah kursi yang terbuka di pesawat, bisa sangat rumit. Jika dua orang mencoba untuk membeli kursi terakhir di pesawat, mereka berdua mungkin menerima jawaban yang mengatakan satu kursi tersisa. Basis data perlu mengambil langkah ekstra untuk memastikan bahwa kursi hanya dijual satu kali. (Maskapai penerbangan masih dapat memilih untuk memesan penerbangan berlebih, tetapi itu adalah keputusan bisnis, bukan kesalahan basis data.)

Basis data bekerja keras untuk menjaga konsistensi saat perubahan diperinci dengan menggabungkan semua sejumlah perubahan rumit menjadi paket tunggal yang dikenal sebagai “transaksi.” Jika empat orang yang terbang bersama menginginkan kursi pada penerbangan yang sama, database dapat menyimpan set bersama dan hanya memproses perubahan jika ada empat kursi kosong yang tersedia, misalnya.

Dalam banyak kasus, pembuat basis data perlu memutuskan apakah mereka ingin menukar konsistensi demi kecepatan. Apakah konsistensi yang kuat layak untuk memperlambat pembaruan hingga mencapai semua sudut basis data? Atau lebih baik membajak ke depan karena kemungkinannya rendah bahwa ketidakkonsistenan apa pun akan menyebabkan masalah yang signifikan? Lagi pula, apakah benar-benar tragis jika seseorang yang membeli tiket lima milidetik lebih lambat dari orang lain yang benar-benar mendapatkan tiketnya? Anda dapat berargumen bahwa tidak ada yang akan menyadarinya.

Masalahnya hanya terjadi dalam waktu singkat yang dibutuhkan versi data baru untuk menyebar ke seluruh jaringan. Basis data akan bertemu pada jawaban yang benar dan konsisten, jadi mengapa tidak mengambil risiko jika taruhannya rendah?

Sekarang ada beberapa versi “akhirnya konsisten” yang didukung oleh basis data yang berbeda. Kebingungan tentang cara terbaik untuk mendekati masalah telah dipelajari secara ekstensif selama bertahun-tahun. Ilmuwan komputer suka berbicara tentang teorema CAP, yang menjelaskan pertukaran antara konsistensi, ketersediaan, dan kemampuan partisi. Biasanya relatif mudah untuk memilih dua dari tiga tetapi sulit untuk mendapatkan ketiganya dalam satu sistem kerja.

Mengapa konsistensi akhirnya penting?

Ide konsistensi akhirnya berkembang sebagai cara untuk melunakkan harapan akurasi di saat-saat paling sulit untuk disampaikan. Ini hanya setelah informasi baru ditulis ke satu node tetapi belum disebarkan ke seluruh konstelasi mesin yang bertanggung jawab untuk menyimpan data. Pengembang basis data sering mencoba untuk lebih tepat dengan mengeja berbagai versi konsistensi yang dapat mereka tawarkan. Chief technology officer Amazon Werner Vogels menjelaskan lima versi berbeda yang dipertimbangkan Amazon saat merancang beberapa database yang mendukung Amazon Web Services (AWS). Daftar ini mencakup versi seperti “konsistensi sesi”, yang menjanjikan konsistensi tetapi hanya dalam konteks sesi tertentu.

Gagasan ini terkait erat dengan database NoSQL karena banyak dari produk ini dimulai dengan hanya menjanjikan konsistensi akhirnya. Selama bertahun-tahun, desainer database telah mempelajari masalah secara lebih rinci dan mengembangkan model yang lebih baik untuk menggambarkan pengorbanan dengan lebih presisi. Idenya masih mengganggu beberapa administrator database, jenis yang memakai ikat pinggang dan suspender untuk bekerja, tetapi pengguna yang tidak membutuhkan jawaban yang sempurna menghargai kecepatannya.

Bagaimana pemain lama mendekati ini?

Perusahaan basis data tradisional seperti Oracle dan IBM tetap berkomitmen pada konsistensi yang kuat, dan produk database utama mereka terus mendukungnya. Beberapa pengembang menggunakan komputer yang sangat besar dengan terabyte RAM untuk menjalankan database tunggal yang mempertahankan satu catatan yang konsisten. Untuk pekerjaan inventaris perbankan dan gudang, ini bisa menjadi cara paling sederhana untuk berkembang.

Oracle juga mendukung cluster database, termasuk MySQL, dan ini mungkin menggunakan konsistensi untuk menyediakan pekerjaan yang akhirnya membutuhkan lebih banyak ukuran dan kecepatan daripada kesempurnaan.

Database Microsoft Cosmos menawarkan lima tingkat jaminan, mulai dari konsistensi yang kuat hingga akhirnya. Pengembang dapat memperdagangkan kecepatan versus akurasi tergantung pada aplikasinya.

---

Apa yang dilakukan para pemula?

Banyak layanan database NoSQL yang muncul secara eksplisit merangkul konsistensi akhirnya untuk menyederhanakan pengembangan dan meningkatkan kecepatan. Startup mungkin telah mulai menawarkan model konsistensi yang paling sederhana, tetapi akhir-akhir ini mereka telah memberi pengembang lebih banyak opsi untuk menukar kecepatan mentah untuk akurasi yang lebih baik saat dibutuhkan.

Cassandra, salah satu penawaran database NoSQL paling awal, sekarang menawarkan sembilan opsi untuk konsistensi penulisan dan 10 opsi untuk konsistensi baca. Pengembang dapat menukar kecepatan untuk konsistensi sesuai dengan permintaan aplikasi.

Couchbase, misalnya, menawarkan apa yang disebut perusahaan sebagai jumlah konsistensi yang “menyesuaikan” yang dapat bervariasi dari satu kueri ke kueri lainnya. MongoDB dapat dikonfigurasi untuk menawarkan konsistensi akhir untuk replika read-only untuk kecepatan, tetapi juga dapat dikonfigurasi dengan berbagai opsi yang menawarkan konsistensi yang lebih kuat. PlanetScale menawarkan model yang menyeimbangkan replikasi yang konsisten dengan kecepatan, dengan alasan bahwa bank bukan satu-satunya yang perlu melawan inkonsistensi.

Beberapa perusahaan sedang membangun protokol baru yang mendekati kuat konsistensi. Misalnya, Google’s Spanner mengandalkan rangkaian jam yang sangat akurat untuk menyinkronkan versi yang berjalan di pusat data yang berbeda. Basis data dapat menggunakan stempel waktu ini untuk menentukan blok data baru mana yang lebih dulu tiba. FaunaDB, di sisi lain, menggunakan versi protokol yang tidak bergantung pada jam yang sangat akurat. Sebagai gantinya, perusahaan membuat stempel waktu sintetis yang dapat membantu memutuskan versi nilai bersaing mana yang harus dipertahankan.

Yugabyte telah memilih untuk merangkul konsistensi dan partisiabilitas dari teorema CAP dan menukar ketersediaan. Beberapa kueri baca akan dijeda hingga database mencapai status yang konsisten. CockroachDB menggunakan model yang dikatakan terkadang menawarkan versi data berseri, tetapi bukan versi linier.

Batas konsistensi akhirnya

Untuk tugas-tugas penting, seperti yang melibatkan uang, pengguna bersedia menunggu jawaban tanpa inkonsistensi. Akhirnya, model yang konsisten dapat diterima untuk banyak pekerjaan pengumpulan data, tetapi tidak sesuai untuk tugas yang memerlukan tingkat kepercayaan yang tinggi. Ketika perusahaan mampu untuk mendukung komputer besar dengan banyak RAM, database yang menawarkan konsistensi yang kuat sesuai untuk semua yang mengontrol sumber daya yang langka.

VentureBeat

Misi VentureBeat adalah menjadi alun-alun kota digital bagi para pengambil keputusan teknis untuk memperoleh pengetahuan tentang teknologi dan transaksi transformatif. Situs kami memberikan informasi penting tentang teknologi data dan strategi untuk memandu Anda saat Anda memimpin organisasi Anda. Kami mengundang Anda untuk menjadi anggota komunitas kami, untuk mengakses:

• informasi terkini tentang subjek yang menarik bagi Anda
• buletin kami

konten pemimpin pemikiran yang terjaga keamanannya dan akses diskon ke acara berharga kami, seperti Transformasi 2021

: Belajarlah lagi

fitur jaringan, dan lainnya

Menjadi anggota

Baca selengkapnya