Pendekatan terbaik untuk sharding tabel MySQL untuk tidak melakukannya kecuali benar-benar tidak dapat dihindari untuk melakukannya.
Saat Anda menulis aplikasi, Anda biasanya ingin melakukannya dengan cara yang memaksimalkan kecepatan, kecepatan pengembang. Anda mengoptimalkan latensi (waktu hingga jawaban siap) atau throughput (jumlah jawaban per unit waktu) hanya jika diperlukan.
Anda mempartisi dan kemudian menetapkan partisi ke host yang berbeda (=shard) hanya ketika jumlah semua partisi ini tidak lagi sesuai dengan satu instance server database - alasannya adalah penulisan atau pembacaan.
Kasus penulisan adalah a) frekuensi penulisan membebani disk server ini secara permanen atau b) ada terlalu banyak penulisan yang terjadi sehingga replikasi secara permanen tertinggal dalam hierarki replikasi ini.
Kasus baca untuk sharding adalah ketika ukuran data sangat besar sehingga set kerja tidak lagi muat ke dalam memori dan pembacaan data mulai mengenai disk alih-alih dilayani dari memori hampir sepanjang waktu.
Hanya jika Anda memiliki untuk memecahkan Anda melakukannya.
Saat Anda melakukan shard, Anda membayarnya dengan berbagai cara:
Sebagian besar SQL Anda tidak lagi bersifat deklaratif.
Biasanya, dalam SQL Anda memberi tahu database data apa yang Anda inginkan dan menyerahkannya kepada pengoptimal untuk mengubah spesifikasi itu menjadi program akses data. Itu hal yang baik, karena fleksibel, dan karena menulis program akses data ini adalah pekerjaan membosankan yang merusak kecepatan.
Dengan lingkungan sharded, Anda mungkin menggabungkan tabel pada node A dengan data pada node B, atau Anda memiliki tabel yang lebih besar dari node, pada node A dan B dan menggabungkan data darinya dengan data yang ada pada node B dan C. Anda mulai menulis resolusi gabungan berbasis hash aplikasi secara manual untuk menyelesaikannya (atau Anda menemukan kembali cluster MySQL), yang berarti Anda berakhir dengan banyak SQL yang tidak lagi deklaratif, tetapi mengekspresikan fungsionalitas SQL dengan cara prosedural (mis. Anda menggunakan pernyataan SELECT dalam perulangan).
Anda mengalami banyak latensi jaringan.
Biasanya, kueri SQL dapat diselesaikan secara lokal dan pengoptimal mengetahui tentang biaya yang terkait dengan akses disk lokal dan menyelesaikan kueri dengan cara yang meminimalkan biaya untuk itu.
Dalam lingkungan sharded, kueri diselesaikan dengan menjalankan akses nilai kunci di seluruh jaringan ke beberapa node (semoga dengan akses kunci yang dikelompokkan dan bukan pencarian kunci individual per perjalanan pulang pergi) atau dengan mendorong bagian dari WHERE klausa seterusnya ke node di mana mereka dapat diterapkan (yang disebut 'kondisi pushdown'), atau keduanya.
Tetapi bahkan dalam kasus terbaik, ini melibatkan lebih banyak perjalanan pulang pergi jaringan daripada situasi lokal, dan ini lebih rumit. Terutama karena pengoptimal MySQL tidak tahu apa-apa tentang latensi jaringan sama sekali (Oke, cluster MySQL perlahan-lahan menjadi lebih baik dalam hal itu, tetapi untuk vanilla MySQL di luar cluster itu masih benar).
Anda kehilangan banyak kekuatan ekspresif SQL.
Oke, itu mungkin kurang penting, tetapi batasan kunci asing dan mekanisme SQL lainnya untuk integritas data tidak mampu menjangkau banyak pecahan.
MySQL tidak memiliki API yang memungkinkan kueri asinkron yang berfungsi.
Ketika data dengan tipe yang sama berada di beberapa node (misalnya data pengguna pada node A, B, dan C), kueri horizontal sering kali perlu diselesaikan terhadap semua node ini ("Temukan semua akun pengguna yang belum masuk selama 90 hari atau lebih"). Waktu akses data bertambah secara linier dengan jumlah node, kecuali beberapa node dapat ditanyakan secara paralel dan hasilnya dikumpulkan saat mereka masuk ("Map-Reduce").
Prasyarat untuk itu adalah API komunikasi asinkron, yang tidak ada untuk MySQL dalam kondisi kerja yang baik. Alternatifnya adalah banyak forking dan koneksi dalam proses anak, yaitu mengunjungi dunia suck on a season pass.
Setelah Anda mulai melakukan sharding, struktur data dan topologi jaringan menjadi terlihat sebagai poin kinerja untuk aplikasi Anda. Agar dapat bekerja dengan cukup baik, aplikasi Anda perlu mengetahui hal-hal ini, dan itu berarti bahwa hanya sharding tingkat aplikasi yang masuk akal.
Pertanyaannya lebih lanjut jika Anda ingin melakukan auto-shard (menentukan baris mana yang masuk ke node mana dengan hashing kunci utama misalnya) atau jika Anda ingin membagi secara fungsional dengan cara manual ("Tabel yang terkait dengan cerita pengguna xyz buka ini master, sementara tabel terkait abc dan def pergi ke master itu").
Sharding fungsional memiliki keuntungan bahwa, jika dilakukan dengan benar, sebagian besar waktu tidak terlihat oleh sebagian besar pengembang, karena semua tabel yang terkait dengan kisah pengguna mereka akan tersedia secara lokal. Itu memungkinkan mereka untuk tetap mendapat manfaat dari SQL deklaratif selama mungkin, dan juga akan mengurangi latensi jaringan karena jumlah transfer lintas jaringan dijaga agar tetap minimal.
Sharding fungsional memiliki kelemahan yaitu tidak memungkinkan tabel tunggal menjadi lebih besar dari satu instance, dan memerlukan perhatian manual dari seorang desainer.
Sharding fungsional memiliki kelebihan yaitu relatif mudah dilakukan pada basis kode yang sudah ada dengan jumlah perubahan yang tidak terlalu besar. http://Booking.com telah melakukannya beberapa kali dalam beberapa tahun terakhir dan berhasil dengan baik untuk mereka.
Setelah mengatakan semua itu, melihat pertanyaan Anda, saya yakin Anda mengajukan pertanyaan yang salah, atau saya benar-benar salah memahami pernyataan masalah Anda.
