BASIS vs ASAM

6.1 Pertempuran Singkatan: DASAR vs. ASAM

Basis data relasional populer, seperti MySQL, muncul hanya berdasarkan ACID. Tetapi selama sepuluh tahun terakhir, apa yang disebut database NoSQL, yang menggabungkan beberapa jenis database yang sangat berbeda dengan nama ini, telah berjalan cukup baik tanpa ACID. Faktanya, ada sejumlah besar pengembang yang bekerja dengan database NoSQL dan sama sekali tidak peduli dengan transaksi dan keandalannya. Mari kita lihat apakah mereka benar.

Anda tidak dapat berbicara secara umum tentang database NoSQL, karena ini hanya abstraksi yang bagus. Basis data NoSQL berbeda satu sama lain dalam desain subsistem penyimpanan data, dan bahkan dalam model data: NoSQL adalah CouchDB dan grafik Neo4J yang berorientasi pada dokumen. Tetapi jika kita membicarakannya dalam konteks transaksi, semuanya cenderung serupa dalam satu hal: mereka menyediakan versi atomisitas dan isolasi yang terbatas, dan oleh karena itu tidak memberikan jaminan ACID. Untuk memahami apa artinya ini, mari kita jawab pertanyaannya: apa yang mereka tawarkan, jika bukan ASAM? Tidak ada apa-apa?

Tidak terlalu. Lagi pula, mereka, seperti database relasional, juga perlu menjual dirinya sendiri dalam paket yang indah. Dan mereka membuat singkatan "kimiawi" mereka sendiri - DASAR.

6.2 BASE sebagai antagonis

Dan di sini sekali lagi saya tidak akan mengurutkan huruf, tetapi saya akan mulai dengan istilah mendasar - konsistensi. Saya harus menyamakan efek pengenalan Anda, karena konsistensi ini tidak ada hubungannya dengan konsistensi dari ACID. Masalah dengan istilah konsistensi adalah bahwa hal itu digunakan dalam banyak konteks. Tetapi konsistensi ini memiliki konteks penggunaan yang jauh lebih luas, dan memang konsistensi inilah yang dibahas ketika membahas sistem terdistribusi.

Basis data relasional yang kita bicarakan di atas memberikan tingkat isolasi transaksi yang berbeda, dan yang paling ketat memastikan bahwa satu transaksi tidak dapat melihat perubahan tidak valid yang dibuat oleh transaksi lain. Jika Anda berdiri di kasir di toko, dan pada saat itu uang sewa ditarik dari akun Anda, tetapi transaksi dengan transfer uang sewa gagal dan akun Anda kembali ke nilai sebelumnya (uangnya adalah tidak didebet), maka transaksi pembayaran Anda di kasir tidak akan memperhatikan semua orang isyarat ini - setelah semua, transaksi itu tidak pernah berhasil, dan berdasarkan persyaratan isolasi transaksi, perubahan sementara tidak dapat diperhatikan oleh transaksi lain.

Banyak database NoSQL mengabaikan jaminan isolasi dan menawarkan "konsistensi akhir" di mana Anda pada akhirnya akan melihat data yang valid, tetapi ada kemungkinan transaksi Anda akan membaca nilai yang tidak valid - yaitu, sementara, atau diperbarui sebagian, atau kedaluwarsa. Ada kemungkinan data akan menjadi konsisten dalam mode "malas" saat membaca ("malas saat membaca").

NoSQL disusun sebagai database untuk analitik waktu nyata, dan untuk mencapai kecepatan yang lebih tinggi, mereka mengorbankan konsistensi. Dan Eric Brewer, orang yang sama yang menciptakan istilah BASE, merumuskan apa yang disebut "teorema CAP", yang menurutnya:

Untuk setiap implementasi komputasi terdistribusi, dimungkinkan untuk menyediakan tidak lebih dari dua dari tiga properti berikut:

• konsistensi data ( konsistensi ) - data pada node (instance) yang berbeda tidak saling bertentangan;
• ketersediaan ( ketersediaan ) - setiap permintaan ke sistem terdistribusi diakhiri dengan respons yang benar, tetapi tanpa jaminan bahwa respons dari semua node sistem adalah sama;
• toleransi partisi (toleransi partisi ) - Bahkan jika tidak ada koneksi antar node, mereka terus bekerja secara independen satu sama lain.

Jika Anda ingin penjelasan CAP yang sangat sederhana, maka ini dia.

Ada pendapat bahwa teorema CAP tidak berfungsi, dan umumnya dirumuskan terlalu abstrak. Dengan satu atau lain cara, database NoSQL sering menolak konsistensi dalam konteks teorema CAP, yang menjelaskan situasi berikut: data telah diperbarui dalam cluster dengan beberapa instance, tetapi perubahan tersebut belum disinkronkan pada semua instance. Ingat, saya menyebutkan contoh DynamoDB di atas, yang memberi tahu saya: perubahan Anda menjadi tahan lama - inilah HTTP 200 untuk Anda - tetapi saya baru melihat perubahannya setelah 10 detik? Contoh lain dari kehidupan sehari-hari seorang developer adalah DNS, sistem nama domain. Jika ada yang tidak tahu, maka ini adalah "kamus" yang menerjemahkan alamat http (s) menjadi alamat IP.

Catatan DNS yang diperbarui disebarkan ke server sesuai dengan pengaturan interval caching - sehingga pembaruan tidak segera terlihat. Nah, inkonsistensi temporal serupa (yaitu, pada akhirnya konsistensi) dapat terjadi pada cluster database relasional (katakanlah, MySQL) - lagipula, konsistensi ini tidak ada hubungannya dengan konsistensi dari ACID. Oleh karena itu, penting untuk dipahami bahwa dalam pengertian ini, database SQL dan NoSQL tidak mungkin sangat berbeda jika menyangkut beberapa instance dalam sebuah cluster.

Selain itu, konsistensi end-to-end dapat berarti bahwa permintaan tulis akan dibuat tidak berurutan: yaitu, semua data akan ditulis, tetapi nilai yang pada akhirnya akan diterima tidak akan menjadi yang terakhir dalam antrean tulis. .

Basis data NoSQL non-ACID memiliki apa yang disebut "keadaan lunak" karena model konsistensi end-to-end, yang berarti bahwa keadaan sistem dapat berubah seiring waktu, bahkan tanpa input. Tetapi sistem seperti itu berusaha untuk menyediakan aksesibilitas yang lebih besar. Menyediakan ketersediaan 100% bukanlah tugas yang sepele, jadi kita berbicara tentang “ketersediaan dasar”. Dan bersama-sama ketiga konsep ini: "pada dasarnya tersedia", "keadaan lunak" ("keadaan lunak") dan "konsistensi akhirnya" membentuk akronim BASE.

Sejujurnya, konsep BASE menurut saya lebih merupakan pembungkus pemasaran kosong daripada ACID - karena tidak memberikan sesuatu yang baru dan tidak mencirikan database dengan cara apa pun. Dan melampirkan label (ACID, BASE, CAP) ke database tertentu hanya dapat membingungkan pengembang. Saya memutuskan untuk memperkenalkan istilah ini kepada Anda, karena sulit untuk melewatinya saat mempelajari database, tetapi sekarang setelah Anda tahu apa itu, saya ingin Anda melupakannya secepat mungkin. Dan mari kita kembali ke konsep isolasi.

6.3 Jadi database BASE sama sekali tidak memenuhi kriteria ACID?

Pada dasarnya, di mana database ACID berbeda dari non-ACID adalah bahwa non-ACID sebenarnya tidak melakukan isolasi. Ini penting untuk dipahami. Tetapi yang lebih penting adalah membaca dokumentasi database dan mengujinya seperti yang dilakukan oleh orang-orang dari proyek Hermitage. Tidak begitu penting bagaimana tepatnya pembuat database ini atau itu menyebut gagasan mereka - ASAM atau BASIS, CAP atau bukan CAP. Yang penting adalah apa sebenarnya yang disediakan database ini atau itu.

Jika pembuat database mengklaim bahwa ia memberikan jaminan ACID, maka mungkin ada alasannya, tetapi disarankan untuk mengujinya sendiri untuk memahami apakah demikian dan sejauh mana. Jika mereka menyatakan bahwa database mereka tidak memberikan jaminan tersebut, maka ini dapat berarti hal-hal berikut:

• DB tidak memberikan jaminan atomisitas. Sementara beberapa database NoSQL menawarkan API terpisah untuk operasi atomik (misalnya DynamoDB);

• DB tidak memberikan jaminan isolasi. Ini mungkin berarti, misalnya, database tidak akan menulis data sesuai urutan penulisannya.

Adapun jaminan daya tahan, banyak database berkompromi pada poin ini demi kinerja. Menulis ke disk adalah operasi yang terlalu lama, dan ada beberapa cara untuk mengatasi masalah ini. Saya tidak ingin terlalu banyak membahas teori basis data, tetapi agar Anda secara kasar memahami ke arah mana harus mencari, saya akan menjelaskan secara umum bagaimana basis data yang berbeda memecahkan masalah dengan daya tahan.

Untuk membandingkan database yang berbeda, antara lain, Anda perlu mengetahui struktur data apa yang mendasari subsistem penyimpanan dan pengambilan data dari database tertentu. Singkatnya: basis data yang berbeda memiliki implementasi pengindeksan yang berbeda - yaitu, mengatur akses ke data. Beberapa dari mereka memungkinkan Anda untuk menulis data lebih cepat, yang lain - lebih cepat untuk membacanya. Tetapi tidak dapat dikatakan secara umum bahwa beberapa struktur data membuat durabilitas lebih tinggi atau lebih rendah.

6.4 bagaimana data indeks database yang berbeda, dan bagaimana ini memengaruhi daya tahan, dan banyak lagi

Ada dua pendekatan utama untuk menyimpan dan mengambil data.

Cara termudah untuk menyimpan data adalah menambahkan operasi ke akhir file dengan cara seperti log (yaitu, operasi penambahan selalu terjadi): tidak masalah jika kita ingin menambah, mengubah, atau menghapus data - semua Operasi CRUD hanya ditulis ke log. Mencari log tidak efisien, dan di situlah indeks masuk - struktur data khusus yang menyimpan metadata tentang di mana tepatnya data disimpan. Strategi pengindeksan paling sederhana untuk log adalah peta hash yang melacak kunci dan nilai. Nilai akan menjadi referensi ke byte offset untuk data yang ditulis di dalam file, yang merupakan log (log) dan disimpan di disk. Struktur data ini disimpan seluruhnya di memori, sementara data itu sendiri ada di disk, dan disebut pohon LSM (penggabungan terstruktur log).

Anda mungkin bertanya-tanya: jika kita menulis operasi kita ke jurnal sepanjang waktu, apakah itu akan berkembang pesat? Ya, dan oleh karena itu ditemukan teknik pemadatan, yang "membersihkan" data dengan periodisitas tertentu, yaitu hanya menyisakan nilai yang paling relevan untuk setiap kunci, atau menghapusnya. Dan jika kita memiliki lebih dari satu log pada disk, tetapi beberapa, dan semuanya diurutkan, maka kita akan mendapatkan struktur data baru yang disebut SSTable ("tabel string yang diurutkan"), dan ini pasti akan meningkatkan kinerja kita. Jika kita ingin mengurutkan dalam memori, kita akan mendapatkan struktur yang serupa - yang disebut MemTable, tetapi masalahnya adalah jika terjadi kerusakan database yang fatal, maka data ditulis terakhir (terletak di MemTable, tetapi belum ditulis ke disk) hilang. Sebenarnya,

Pendekatan lain untuk pengindeksan didasarkan pada B-trees (“B-trees”). Dalam B-tree, data ditulis ke disk dalam ukuran halaman yang tetap. Blok data ini seringkali berukuran sekitar 4 KB dan memiliki pasangan kunci-nilai yang diurutkan berdasarkan kunci. Satu node B-tree seperti array dengan tautan ke berbagai halaman. Maks. jumlah link dalam array disebut faktor cabang. Setiap rentang halaman adalah node B-tree lain dengan tautan ke rentang halaman lain.

Akhirnya, pada tingkat lembar, Anda akan menemukan halaman individual. Ide ini mirip dengan pointer dalam bahasa pemrograman tingkat rendah, kecuali referensi halaman ini disimpan di disk daripada di memori. Ketika INSERT dan DELETE terjadi di database, maka beberapa node dapat dipecah menjadi dua subpohon agar sesuai dengan faktor percabangan. Jika database gagal karena alasan apa pun di tengah proses, integritas data dapat dikompromikan. Untuk mencegah hal ini terjadi, database yang menggunakan B-tree mempertahankan "log tulis-depan", atau WAL, di mana setiap transaksi dicatat. WAL ini digunakan untuk mengembalikan keadaan B-tree jika rusak. Dan sepertinya inilah yang membuat database yang menggunakan B-tree lebih baik dari segi durabilitas. Tetapi database berbasis LSM juga dapat memelihara file yang pada dasarnya melakukan fungsi yang sama seperti WAL. Oleh karena itu, saya akan mengulangi apa yang telah saya katakan, dan mungkin lebih dari sekali: pahami mekanisme pengoperasian database yang telah Anda pilih.

Yang pasti tentang B-tree, bagaimanapun, adalah bahwa mereka baik untuk transaksionalitas: setiap kunci hanya terjadi di satu tempat dalam indeks, sementara subsistem penyimpanan jurnal dapat memiliki banyak salinan dari kunci yang sama di pecahan yang berbeda (misalnya, sampai pemadatan berikutnya dilakukan).

Namun, desain indeks secara langsung memengaruhi kinerja basis data. Dengan pohon LSM, penulisan ke disk bersifat berurutan, dan pohon-B menyebabkan beberapa akses disk acak, jadi operasi tulis lebih cepat dengan LSM daripada dengan pohon-B. Perbedaannya sangat signifikan untuk hard disk drive magnetik (HDD), di mana penulisan berurutan jauh lebih cepat daripada penulisan acak. Membaca lebih lambat pada pohon LSM karena Anda harus melihat melalui beberapa struktur data dan tabel SS yang berbeda yang berada pada tahap pemadatan yang berbeda. Secara lebih rinci tampilannya seperti ini. Jika kita membuat kueri database sederhana dengan LSM, pertama-tama kita akan mencari kuncinya di MemTable. Jika tidak ada, kami melihat SSTable terbaru; jika tidak ada, maka kita lihat SSTable kedua dari belakang, dan seterusnya. Jika kunci yang diminta tidak ada, maka dengan LSM kita akan tahu yang terakhir ini. Pohon LSM digunakan di, misalnya: LevelDB, RocksDB, Cassandra dan HBase.

Saya menjelaskan semuanya dengan sangat rinci sehingga Anda memahami bahwa ketika memilih database, Anda perlu mempertimbangkan banyak hal berbeda: misalnya, apakah Anda berharap untuk menulis atau membaca data lebih banyak. Dan saya belum menyebutkan perbedaan dalam model data (apakah Anda perlu melintasi data, seperti yang dimungkinkan oleh model grafik? Apakah ada hubungan antara unit yang berbeda dalam data Anda sama sekali - kemudian database relasional akan membantu?), dan 2 jenis skema data - saat menulis (seperti di banyak NoSQL) dan membaca (seperti di relasional).

Jika kita kembali ke aspek daya tahan, maka kesimpulannya adalah sebagai berikut: basis data apa pun yang menulis ke disk, terlepas dari mekanisme pengindeksan, dapat memberikan jaminan yang baik untuk daya tahan data Anda, tetapi Anda harus menangani setiap basis data tertentu , apa sebenarnya yang ditawarkannya.

6.5 Cara kerja DB dalam memori

Omong-omong, selain database yang menulis ke disk, ada juga yang disebut database "dalam memori" yang bekerja terutama dengan RAM. Singkatnya, database dalam memori biasanya menawarkan daya tahan yang lebih rendah demi kecepatan tulis dan baca yang lebih cepat, tetapi ini mungkin sesuai untuk beberapa aplikasi.

Faktanya adalah bahwa memori RAM telah lama lebih mahal daripada disk, tetapi baru-baru ini mulai menjadi lebih murah dengan cepat, yang memunculkan jenis database baru - yang logis, mengingat kecepatan membaca dan menulis data dari RAM. Tetapi Anda berhak bertanya: bagaimana dengan keamanan data dari database ini? Di sini sekali lagi, Anda perlu melihat detail penerapannya. Secara umum, pengembang database semacam itu menawarkan mekanisme berikut:

• Anda dapat menggunakan RAM yang ditenagai oleh baterai;
• Dimungkinkan untuk menulis log perubahan ke disk (seperti WAL yang disebutkan di atas), tetapi bukan data itu sendiri;
• Anda dapat menulis salinan status basis data ke disk secara berkala (yang, tanpa menggunakan opsi lain, tidak memberikan jaminan, tetapi hanya meningkatkan daya tahan);
• Anda dapat mereplikasi status RAM ke mesin lain.

Misalnya, basis data Redis dalam memori, yang terutama digunakan sebagai antrean pesan atau cache, tidak memiliki daya tahan dari ACID: ini tidak menjamin bahwa perintah yang berhasil dijalankan akan disimpan di disk, karena Redis membuang data ke disk (jika Anda telah mengaktifkan kegigihan) hanya secara asinkron, secara berkala.

Namun, ini tidak penting untuk semua aplikasi: Saya menemukan contoh editor online kooperatif EtherPad, yang memerah setiap 1-2 detik, dan berpotensi pengguna dapat kehilangan beberapa huruf atau kata, yang hampir tidak kritis. Jika tidak, karena database dalam memori bagus karena menyediakan model data yang akan sulit diimplementasikan dengan indeks disk, Redis dapat digunakan untuk mengimplementasikan transaksi - antrean prioritasnya memungkinkan Anda melakukan ini.