Dengan senang hati kami sampaikan bahwa setelah menambahkan ANSI SQL, indeks sekunder, skema bintang, dan kemampuan tampilan ke Database Operasional Cloudera, kami akan memperkenalkan dukungan transaksi terdistribusi dalam beberapa bulan mendatang.
Apa itu ASAM?
Model ACID dari desain database adalah salah satu konsep yang paling penting dalam database. ACID singkatan dari atomicity, konsistensi, isolasi, dan daya tahan. Untuk waktu yang sangat lama, kepatuhan yang ketat terhadap keempat properti ini diperlukan untuk database yang sukses secara komersial. Namun, model ini menimbulkan masalah ketika harus melakukan penskalaan di luar database satu server. Untuk mengakomodasi batasan ini, pelanggan meningkatkan perangkat keras tempat database digunakan.
Basis data NoSQL melonggarkan satu atau lebih dari 4 properti ini untuk mencapai peningkatan dramatis dalam skalabilitas — Basis Data Operasional Cloudera (Didukung oleh Apache HBase) adalah salah satu basis data tersebut. Kami melakukan trade-off pada atomisitas — khususnya, Cloudera menyediakan atomisitas satu baris. Untuk mengimbanginya, kami mendukung tabel yang sangat luas (dengan potensi jutaan kolom). Hal ini memungkinkan pelanggan untuk mendenormalisasi skema bintang mereka dan menampilkannya sebagai baris tunggal untuk membuat komitmen atomik dalam satu baris dari apa yang dulu direpresentasikan sebagai beberapa tabel.
Sejak kelahiran HBase, kami telah berupaya membangun kemampuan yang mempersempit kesenjangan fitur dengan RDBM tradisional sambil mempertahankan manfaat skalabilitas, konsistensi, daya tahan, dan isolasi NoSQL.
Awal tahun ini, kami memberikan dukungan untuk ANSI SQL, indeks sekunder, skema bintang, dan tampilan di atas Apache HBase, menghadirkan antarmuka dan kemampuan yang akrab bagi semua pengembang aplikasi yang pernah membangun aplikasi yang menggunakan MySQL atau PostGres.
Kami sekarang berada di puncak memberikan kemampuan untuk membuat komitmen atomik ke data yang melintasi baris dan tabel di seluruh cluster.
Apa yang dimaksud dengan transaksi atom?
transaksi terdiri dari satu set operasi dalam database yang dikelola secara atom, sehingga semua operasi harus seluruhnya diselesaikan (komit) atau tidak berpengaruh (dibatalkan).
Saat ini, kami hanya mendukung transaksi atom satu baris. Ini berarti bahwa ketika pengembang ingin mengadopsi Basis Data Operasional Cloudera, mereka perlu berpikir secara berbeda tentang skema mereka.
Kami sekarang memperkenalkan kemampuan untuk memiliki transaksi kompleks yang mencakup beberapa baris dan tabel, yang berarti bahwa pengembang dapat menerapkan skema bintang tradisional atau memanfaatkan kolom lebar atau keduanya tergantung pada kebutuhan mereka. Fleksibilitas ini dikombinasikan dengan pendekatan skema evolusioner Cloudera Operational Database memungkinkan pengembang untuk memanfaatkan database scale-out modern sambil terus mengembangkan keahlian mereka yang ada.
Hal penting yang perlu diperhatikan adalah bahwa dukungan transaksi di Cloudera Operational Database “bebas kunci” dan memberikan jaminan isolasi snapshot. Basis data tradisional menerapkan "kunci" ke semua data yang terkait dengan transaksi sehingga klien lain yang mengakses data tidak mengubahnya sebelum dikomit ke basis data. Namun, ini dapat mengakibatkan kondisi balapan yang akan berakhir dengan dependensi melingkar dan hang. Kunci juga merupakan penyebab kinerja aplikasi yang sangat buruk karena aplikasi saling menunggu sehingga mereka bisa mendapatkan kunci dan melanjutkan.
Pendekatan kami memungkinkan transaksi pertama yang selesai untuk bergerak maju dan transaksi lain yang mencoba membuat perubahan pada kumpulan data yang sama harus mencoba lagi. Ini mencegah perlambatan apa pun ke seluruh ekosistem aplikasi yang berjalan secara bersamaan di database. Dengan kata lain, pendekatan kami memungkinkan skalabilitas linier sambil memberikan atomisitas yang dapat disediakan oleh basis data transaksional tradisional.
Hasil performa awal
Kemampuan dukungan transaksi kami saat ini dalam versi beta dan sedang melalui pengujian kinerja yang ekstensif.
Pengujian saat ini mencakup benchmark TPC-C standar industri menggunakan aplikasi OLTP Bench. Tolok ukur TPC-C mensimulasikan sejumlah pembelian yang dilakukan secara bersamaan di sejumlah gudang. Skema yang digunakan dalam TPC-C direpresentasikan dalam diagram hubungan entitas berikut:
Angka-angka dalam blok entitas mewakili kardinalitas tabel (jumlah baris). Angka-angka ini difaktorkan oleh W, jumlah Gudang, untuk menggambarkan penskalaan basis data. Angka-angka di sebelah panah hubungan mewakili kardinalitas hubungan (jumlah rata-rata anak per orang tua). + simbol mewakili jumlah variasi kecil dari populasi basis data.
Penempatan pesanan memerlukan 10 kueri berikut untuk dijalankan sebagai transaksi atom tunggal:
1.SELECT c_discount, c_last, C_creditFROM customerWHERE c_w_id =? DAN c_d_id =? DAN c_id =? 2. PILIH w_taxFROM warehouseWHERE w_id =?3. PILIH d_next_o_id, D_taxFROM districtWHERE d_w_id =? DAN d_id =?4. UPSERT INTO district (d_next_o_id, d_w_id, d_id)PILIH d_next_o_id + 1, d_w_id, D_ ROM DAN d_id =? 5. UPSERT INTO new_order (no_o_id, no_d_id, no_w_id)VALUES (?,?,?)6. Upsert ke dalam urutan (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) nilai (?,?,?,?,?,?,?) Ulangi pertanyaan berikut untuk setiap item yang dipilih untuk pesanan. 7. PILIH i_price, i_name, i_data FROM item WHERE i_id =? 8. Pilih s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 dari stok di mana s_i =s_dist_09, s_dist_10 dari stok s_dist_i =s_dist_09, s_dist_10 dari stok s_dist_id =DAN s_w_id =? 9. Upsert ke dalam stok (s_quantity, s_ytd, s_order_cnt, s_remote_cnt, s_i_id, s_w_id) pilih?, S_ytd +?, S_order_cnt + 1, s_remote_cnt +?, S_i_id, s_w_idfrom stockherwhere diwhere schore_cnt +?, S_i_i_id, s_w_idfrom wherewhere soalwhere =_i =S_i_i_id, s_w_idfrom diwhere =DAN s_w_id =?10. Masukkan ke order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) nilai (?,?,?,?,?,?,?,?)Transaksi pembayaran memerlukan 6 kueri berikut untuk dijalankan sebagai transaksi atom tunggal:
1. UPSERT INTO warehouse (w_ytd, w_id) PILIH w_ytd + ?, w_id DIMANA DARI AWAL ? 2. PILIH w_street_1, w_street_2, w_city, w_state, w_zip, w_nameFROM warehouseWHERE w_id =?3. Upsert ke distrik (d_ytd, d_w_id, d_id) pilih d_ytd +?, D_w_id, d_id dari distrik di mana d_w_id =? DAN d_id =? 4. PILIH d_street_1, d_street_2, d_city, d_state, d_zip, nama_ID = _nama DAN d_id =? 6. Upsert menjadi Pelanggan (C_BALANCE, C_YTD_PAYMENT, C_PAYMENT_CNT, C_W_ID, C_D_ID, C_ID) SELECT?,?,?, C_W_ID, C_D_ID, C_IDFrom Pelanggan di mana C_W_ID =? DAN c_d_id =? DAN c_id =? 7. Masukkan ke dalam riwayat (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) nilai (?,?,?,?,?,?,?)Dengan 3 server wilayah yang berjalan pada node Dell PowerEdge R440, kami dapat mencapai hasil berikut:
Dalam grafik ini, sumbu Y mewakili jumlah pesanan yang dapat diproses sepenuhnya (termasuk pembuatan pesanan baru, pembayaran, pengiriman, dll.) per menit dan dinyatakan dalam tolok ukur tpm-C. Sumbu X mewakili jumlah entitas yang mengeksekusi transaksi secara paralel.
Hasil awal ini menunjukkan bahwa sistem mencapai throughput transaksi puncak di suatu tempat antara 150 dan 300 transaksi dan pengujian lebih lanjut diperlukan untuk mengidentifikasi puncak itu.
Saat kemampuan ini matang, throughput OpDB dan kemampuan kami untuk mengukur throughput akan meningkat.
Kesimpulan
Sebagian besar aplikasi memanfaatkan transaksi untuk mendukung berbagai kebutuhan yang dihadapi perusahaan. Namun, ketika RDBMS tradisional tidak dapat diskalakan, pelanggan terpaksa melakukan sharding database secara manual dan mengelola setiap database sharding sebagai database independen sendiri.
Ketika hal ini menjadi terlalu rumit untuk dikelola, pelanggan harus mempertimbangkan untuk memigrasikan aplikasi tersebut ke Basis Data Operasional Cloudera. Dukungan transaksi yang kompleks dikombinasikan dengan dukungan ANSI SQL dan sifat skala-out Apache HBase memberikan kombinasi yang dapat secara signifikan mengurangi kompleksitas operasional dalam mengelola pertumbuhan.
Jika Anda lelah mengelola basis data sharding dan ingin menurunkan TCO basis data, hubungi tim akun Cloudera Anda untuk mengetahui bagaimana kami dapat membantu.
