MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Bagaimana MariaDB Mencapai Skala Global dengan Xpand

Artikel ini pertama kali muncul di InfoWorld . Itu dicetak ulang dengan izin. © IDG Communications, Inc., 2020. Semua hak dilindungi undang-undang Bagaimana MariaDB mencapai skala global dengan Xpand. Xpand sekarang tersedia di MariaDB SkySQL menambahkan SQL terdistribusi untuk skalabilitas dan elastisitas di cloud.

Seiring dengan berkembangnya kebutuhan informasi dan pemrosesan, masalah seperti kinerja dan ketahanan memerlukan solusi baru. Basis data perlu menjaga kepatuhan dan konsistensi ACID, menyediakan ketersediaan tinggi dan kinerja tinggi, serta menangani beban kerja yang besar tanpa menguras sumber daya. Sharding telah menawarkan solusi, tetapi bagi banyak perusahaan, sharding telah mencapai batasnya, karena kompleksitas dan persyaratan sumber dayanya. Solusi yang lebih baik adalah didistribusikan SQL.

Dalam implementasi SQL terdistribusi, database didistribusikan ke beberapa sistem fisik, memberikan transaksi pada tingkat yang dapat diskalakan secara global. MariaDB Platform X5, rilis utama yang mencakup peningkatan ke setiap aspek Platform MariaDB, menyediakan SQL terdistribusi dan skalabilitas besar-besaran melalui penambahan mesin penyimpanan pintar baru yang disebut Xpand. Dengan arsitektur apa-apa yang dibagikan, transaksi ACID yang terdistribusi sepenuhnya, dan konsistensi yang kuat, Xpand memungkinkan Anda menskalakan hingga jutaan transaksi per detik.

Mesin pintar pluggable yang dioptimalkan

MariaDB Enterprise Server dirancang untuk menggunakan mesin penyimpanan yang dapat dipasang (seperti Xpand) untuk mengoptimalkan beban kerja tertentu dari satu platform. Tidak perlu database khusus untuk menangani beban kerja tertentu. MariaDB Xpand, mesin pintar kami untuk SQL terdistribusi, adalah tambahan terbaru untuk jajaran kami. Xpand menambahkan kemampuan transaksional terdistribusi yang skalabel secara besar-besaran ke opsi yang disediakan oleh mesin kami yang lain. Engine pluggable kami yang lain memberikan pengoptimalan untuk beban kerja analitis (kolom), beban kerja berat baca, dan beban kerja tulis berat. Anda dapat mencampur dan mencocokkan tabel yang direplikasi, didistribusikan, dan berbentuk kolom untuk mengoptimalkan setiap database untuk kebutuhan spesifik Anda.

Menambahkan MariaDB Xpand memungkinkan pelanggan perusahaan mendapatkan semua manfaat SQL terdistribusi – kecepatan, ketersediaan, dan skalabilitas – sambil mempertahankan manfaat MariaDB yang biasa mereka dapatkan.

Mari kita lihat bagaimana MariaDB Xpand menyediakan SQL terdistribusi.

Mendistribusikan SQL ke indeks

Xpand menyediakan SQL terdistribusi dengan mengiris, mereplikasi, dan mendistribusikan data di seluruh node. Apa artinya ini? Kami akan menggunakan contoh yang sangat sederhana dengan satu tabel dan tiga node untuk mendemonstrasikan konsepnya. Tidak ditampilkan dalam contoh ini adalah bahwa semua irisan direplikasi.

Pada Gambar 1 di atas, kita memiliki tabel dengan dua indeks. Tabel memiliki beberapa tanggal dan kami memiliki indeks di Kolom Dua, dan satu lagi di Kolom Tiga dan Satu. Indeks dalam arti tabel itu sendiri. Mereka adalah bagian dari tabel. Kunci Utama adalah id , indeks pertama dalam tabel. Itulah yang akan digunakan untuk hash dan menyebarkan data tabel di sekitar database.

Sekarang kita tambahkan pengertian irisan . Slice pada dasarnya adalah partisi horizontal dari tabel. Kami memiliki lima baris di meja kami. Pada Gambar 2, tabel telah diiris dan didistribusikan. Node #1 memiliki dua baris. Node #2 memiliki dua baris, dan Node #3 memiliki satu baris. Tujuannya adalah agar data didistribusikan secara merata di seluruh node.

Indeks juga telah diiris dan didistribusikan. Ini adalah perbedaan utama antara Xpand dan solusi terdistribusi lainnya. Biasanya, database terdistribusi memiliki indeks lokal, sehingga setiap node memiliki indeks datanya sendiri. Di Xpand, indeks didistribusikan dan disimpan secara independen dari tabel. Ini menghilangkan kebutuhan untuk mengirim kueri ke semua node (menyebarkan/mengumpulkan). Pada contoh di atas, Node #1 berisi baris 2 dan 4 dari tabel, dan juga berisi indeks untuk baris 32 dan 35 serta baris April dan Maret. Tabel dan indeks secara independen diiris, didistribusikan, dan direplikasi di seluruh node.

Mesin kueri menggunakan indeks terdistribusi untuk menentukan di mana menemukan data. Itu hanya mencari partisi indeks yang diperlukan dan kemudian mengirimkan kueri hanya ke lokasi di mana data yang dibutuhkan berada. Pertanyaan didistribusikan semua. Mereka dilakukan secara bersamaan dan paralel. Ke mana mereka pergi sepenuhnya bergantung pada data dan apa yang diperlukan untuk menyelesaikan kueri.

Semua irisan direplikasi setidaknya dua kali. Untuk setiap irisan, ada replika yang berada di node lain. Secara default, akan ada tiga salinan data itu – irisan dan dua replika. Setiap salinan akan berada di node yang berbeda, dan jika Anda berjalan di beberapa zona ketersediaan, salinan tersebut juga akan berada di zona ketersediaan yang berbeda.

Penanganan baca dan tulis

Mari kita ambil contoh lain. Pada Gambar 3, kami memiliki lima instance MariaDB Enterprise Server dengan Xpand (node). Ada meja untuk menyimpan profil pelanggan. Irisan dengan profil Shane ada di Node #1 dengan salinan di Node #3 dan Node #5. Kueri dapat masuk pada simpul mana pun dan akan diproses secara berbeda bergantung pada apakah kueri tersebut dibaca atau ditulis.

Penulisan dibuat ke semua salinan secara sinkron di dalam transaksi terdistribusi. Setiap kali saya memperbarui profil "Shane" saya karena saya mengubah email saya atau saya mengubah alamat saya, tulisan itu pergi ke semua salinan pada saat yang sama dalam suatu transaksi. Inilah yang memberikan konsistensi yang kuat.

Pada Gambar 3, pernyataan UPDATE pergi ke Node #2. Tidak ada apa pun di Node #2 tentang profil saya tetapi Node #2 tahu di mana profil saya dan mengirimkan pembaruan ke Node #1, Node #3, dan Node #5, kemudian melakukan transaksi itu dan kembali ke aplikasi.

Bacaan ditangani secara berbeda. Dalam diagram, irisan dengan profil saya ada di Node #1 dengan salinan di Node #3 dan Node #5. Ini menjadikan Node #1 sebagai replika peringkat. Setiap irisan memiliki replika peringkat, yang dapat dikatakan sebagai simpul yang “memiliki” data. Secara default, tidak peduli node mana yang membaca, selalu menuju replika peringkat, jadi setiap SELECT yang menyelesaikan saya akan pergi ke Node #1.

Memberikan elastisitas

Database terdistribusi seperti Xpand terus berubah dan berkembang tergantung pada data dalam aplikasi. Proses rebalancer bertanggung jawab untuk mengadaptasi distribusi data dengan kebutuhan saat ini dan mempertahankan distribusi irisan yang optimal di seluruh node. Ada tiga skenario umum yang memerlukan redistribusi:menambahkan node, menghapus node, dan mencegah beban kerja yang tidak merata atau "hot spot".

Misalnya, katakanlah kami menjalankan dengan tiga node tetapi menemukan lalu lintas meningkat dan kami perlu menskalakan – kami menambahkan simpul keempat untuk menangani lalu lintas. Node #4 kosong saat kita menambahkannya seperti yang ditunjukkan pada Gambar 4. Penyeimbang ulang secara otomatis memindahkan irisan dan replika untuk menggunakan Node #4, seperti yang ditunjukkan pada Gambar 5.

Jika Node #4 gagal, penyeimbang ulang secara otomatis bekerja kembali; kali ini membuat ulang irisan dari replikanya. Tidak ada data yang hilang. Replika juga dibuat ulang untuk menggantikan yang berada di Node #4, jadi semua irisan kembali memiliki replika di node lain untuk memastikan ketersediaan tinggi.

Gambar 6. Jika sebuah node gagal, Xpand rebalancer membuat ulang irisan dan replika yang berada di node yang gagal dari data replika di node lain.

Menyeimbangkan beban kerja

Selain penskalaan dan ketersediaan tinggi, penyeimbang ulang mengurangi distribusi beban kerja yang tidak merata – baik hot spot atau kurang dimanfaatkan. Bahkan ketika data didistribusikan secara acak dengan algoritma hash yang sempurna, hot spot dapat terjadi. Misalnya, bisa saja terjadi secara kebetulan bahwa 10 produk yang dijual bulan ini berada di Node #1. Data terdistribusi secara merata tetapi beban kerjanya tidak (Gambar 7). Dalam skenario jenis ini, penyeimbang ulang akan mendistribusikan ulang irisan untuk menyeimbangkan pemanfaatan sumber daya (Gambar 8).

Gambar 7. Xpand telah mendistribusikan data secara merata tetapi beban kerja tidak merata. Node 1 memiliki beban kerja yang jauh lebih tinggi daripada tiga node lainnya.

Gambar 8. Xpand rebalancer mendistribusikan kembali irisan data untuk menyeimbangkan beban kerja di seluruh node.

Skalabilitas, kecepatan, ketersediaan, keseimbangan

Kebutuhan informasi dan pemrosesan akan terus berkembang. Itu sudah pasti. MariaDB Xpand memberikan solusi penskalaan yang konsisten dan sesuai dengan ACID untuk perusahaan dengan persyaratan yang tidak dapat dipenuhi dengan alternatif lain seperti replikasi dan sharding.

SQL Terdistribusi menyediakan skalabilitas, dan MariaDB Xpand menyediakan fleksibilitas untuk memilih seberapa besar skalabilitas yang Anda butuhkan. Bagikan satu tabel atau beberapa tabel atau bahkan seluruh database Anda, pilihan ada di tangan Anda. Secara operasional, kapasitas mudah disesuaikan untuk memenuhi tuntutan beban kerja yang berubah pada waktu tertentu. Anda tidak perlu menyediakan terlalu banyak.

Xpand juga secara transparan melindungi terhadap pemanfaatan sumber daya yang tidak merata, mendistribusikan ulang data secara dinamis untuk menyeimbangkan beban kerja di seluruh node dan mencegah hot spot. Untuk pengembang, tidak perlu khawatir tentang skalabilitas dan kinerja. Xpand elastis. Xpand juga menyediakan redundansi dan ketersediaan tinggi. Dengan data yang dipotong, direplikasi, dan didistribusikan di seluruh node, data dilindungi dan redundansi dipertahankan jika terjadi kegagalan perangkat keras.

Dan, dengan arsitektur MariaDB, tabel terdistribusi Anda akan berfungsi dengan baik – termasuk GABUNG lintas mesin – dengan tabel MariaDB Anda yang lain. Buat solusi database yang Anda butuhkan dengan mencampur dan mencocokkan tabel yang direplikasi, didistribusikan, atau berbentuk kolom semua pada satu database di Platform MariaDB.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Memberikan Inovasi Lebih Cepat ke Komunitas MariaDB

  2. MariaDB ROUND() vs LANTAI()

  3. Cara Melakukan Perubahan Skema di MySQL &MariaDB dengan Cara yang Aman

  4. Apa yang Layak bagi Pelanggan Kami:Memperkenalkan Dokumentasi MariaDB Enterprise

  5. Perbaiki "ERROR 1136 (21S01):Jumlah kolom tidak cocok dengan jumlah nilai pada baris 1" saat Memasukkan Data di MariaDB