MySQL Sharding vs MySQL Cluster

Mempertimbangkan kinerja saja , bisakah MySQL Cluster mengalahkan data kustom sharding solusi MySQL? sharding = partisi horisontal

Ketika saya merujuk pada sharding, saya mempertimbangkan sharding yang dibuat di lapisan aplikasi, misalnya, mendistribusikan catatan secara merata di seluruh instance MySQL yang independen. Untuk dua server, bisa jadi (kunci mod 2).

mysql ndbcluster

— GSB
sumber

Pengungkapan: Saya seorang karyawan MySQL, bekerja pada MySQL Cluster.

Saya akan mengatakan bahwa MySQL Cluster dapat mencapai throughput / host yang lebih tinggi daripada MySQL + InnoDB asalkan:

Pertanyaannya sederhana
Semua data masuk dalam memori

Dalam hal latensi, MySQL Cluster harus memiliki latensi yang lebih stabil daripada MySQL sharded. Latensi aktual untuk data murni dalam memori bisa serupa.

Ketika kueri menjadi lebih kompleks, dan data disimpan dalam disk, perbandingan kinerja menjadi lebih membingungkan. Untuk mendapatkan jawaban yang lebih spesifik, Anda perlu menjabarkan lebih lanjut tentang aplikasi Anda dan kueri yang Anda lakukan, serta jumlah host dan volume data. MySQL Cluster baru-baru ini memperoleh eksekusi query paralel lokal (AQL) yang berarti dapat bersaing dengan MySQLD mandiri meskipun memiliki data yang didistribusikan di beberapa host.

MySQL Cluster saat ini terbatas pada 'sharding' lebih dari 48 host. Secara teori, Sharded MySQL tidak memiliki batas. Namun, untuk throughput target yang diberikan, lebih sedikit host MySQL Cluster mungkin diperlukan daripada host MySQL yang di-shard.

Perbedaan yang lebih menarik adalah ketika Anda melihat bidang selain kinerja:

MySQL Cluster mendukung permintaan acak di semua pecahan
MySQL Cluster mendukung transaksi sewenang-wenang di semua pecahan
MySQL Cluster mendukung replikasi pecahan serpihan dengan failover dan pemulihan otomatis
MySQL Cluster mendukung penambahan simpul online (ekspansi cluster)
MySQL Sharded lebih 'roll milik Anda'

Memiliki pecahan bawaan pada aplikasi Anda memberi Anda potensi penskalaan maksimum, tetapi menambah kompleksitas dan membatasi fleksibilitas Anda dalam hal kueri dan operasi lintas-beling. Jika sharding Anda terlalu dini maka itu mungkin menjadi akar beberapa masalah bagi Anda. MySQL Cluster memungkinkan Anda mendapatkan beberapa manfaat dari sharding tanpa harus membatasi aplikasi Anda menjadi single-shard saja.

Mengenai jawaban sebelumnya, beberapa klarifikasi:

"Meskipun MySQL Cluster adalah keluhan ACID, ia tidak menyediakan mesin penyimpanan yang cocok untuk data dengan kunci majemuk."

MySQL Cluster mendukung kunci primer dan sekunder gabungan. Tidak yakin apa yang tidak 'cocok' tentang itu. Mungkin poster sebelumnya bisa menjelaskan?

"Untuk memiliki data dengan karakteristik kunci yang sama disimpan dalam satu set node data tertentu, Anda dapat melakukan hal berikut:

Ambil semua simpul data offline, hanya menyisakan simpul data yang Anda inginkan untuk menyimpan data dengan karakteristik kunci yang sama.

Memuat data Anda ke dalam MySQL Cluster, yang mengisi hanya node data pilih Anda

Bawa semua node data kembali online "

Ini salah. Distribusi data tidak tergantung pada node mana yang sedang online setiap saat. MySQL Cluster mendukung berbagai skema distribusi data untuk mendukung optimisasi yang Anda jelaskan. Saya menggambarkan distribusi data di MySQL Cluster dalam posting blog di sini: Distribusi data di MySQL Cluster

— Clement Frazer
sumber

Hei, Frazier. Saya membaca tautan yang Anda berikan. Hanya untuk klaraifikasi, komentar 'kunci majemuk' saya didasarkan pada indeks yang tidak unik. Perusahaan majikan saya mencoba MySQL Cluster sekitar tahun 2007 Q1 dan tidak menyukainya karena kinerjanya yang buruk. IMHO itu adalah pilihan buruk klien untuk kunci (kardinalitas kecil) dan pertanyaannya. MySQL Cluster harus lebih matang sejak saat itu berdasarkan tautan Anda. Mengenai pernyataan kedua saya, ini adalah berapa banyak pengguna MongoDB mengisi pecahan spesifik. Beberapa klien majikan saya telah melakukan ini dengan pengaturan MySQL khusus mereka.

— RolandoMySQLDBA

Di tautan Anda, disebutkan 'pemindaian indeks berurutan' yang tidak dapat dipangkas, karena baris yang cocok tidak dijamin untuk disimpan dalam satu fragmen tabel. Inilah sebabnya saya menyarankan mengisolasi data ke pecahan specfic (data node) untuk meminimalkan tempat data akan menyebar. Karena jawaban Anda membawa sisi positif dari MySQL Cluster, lebih baik cocok dengan pertanyaan yang diposting asli. Jawaban saya salah dalam mendukung kehati-hatian, pesimisme, dan agak naif dari kekuatan MySQL Cluster hari ini.

— RolandoMySQLDBA

Sebagai pengganti omelan dan ocehan saya, +1 untuk jawaban Anda !!!

— RolandoMySQLDBA

Hai Rolando, Terima kasih telah menjelaskan pernyataan Anda. Benar bahwa pemindaian indeks yang tidak dipangkas adalah 'mahal' di Cluster, karena semua node data terlibat. Kedengarannya seperti pemindaian pada indeks kardinalitas rendah ini akan mahal pada sistem apa pun, tetapi pada Cluster harganya menjadi mahal. Kehati-hatian dan pesimisme Anda pasti telah menyelamatkan Anda lebih dari sekali :) Terima kasih atas +1

— Frazer Clement