Saya telah melakukan BANYAK membaca pada pilihan yang tersedia. Saya juga mendapatkan MySQL High Performance 2nd edition, yang sangat saya rekomendasikan.
Inilah yang berhasil saya kumpulkan:
Pengelompokan
Pengelompokan dalam pengertian umum adalah mendistribusikan beban di banyak server yang muncul ke aplikasi luar sebagai satu server.
Kluster MySQL NDB
MySQL NDB Cluster adalah mesin penyimpanan terdistribusi, dalam memori, tanpa berbagi apa pun dengan replikasi sinkron dan partisi data otomatis (permisi, saya meminjam secara harfiah dari buku Kinerja Tinggi, tetapi mereka meletakkannya dengan sangat baik di sana). Ini bisa menjadi solusi kinerja tinggi untuk beberapa aplikasi, tetapi aplikasi web umumnya tidak berfungsi dengan baik.
Masalah utama adalah bahwa di luar kueri yang sangat sederhana (yang hanya menyentuh satu tabel), kluster umumnya harus mencari data di beberapa node, memungkinkan latensi jaringan merayap masuk dan secara signifikan memperlambat waktu penyelesaian kueri. Karena aplikasi memperlakukan cluster sebagai satu komputer, aplikasi tidak dapat memberi tahu dari node mana untuk mengambil data.
Selain itu, persyaratan dalam memori tidak dapat diterapkan untuk banyak database besar.
Sequoia Berlanjut
Ini adalah solusi pengelompokan lain untuk MySQL, yang bertindak sebagai middleware di atas server MySQL. Menawarkan replikasi sinkron, load balancing dan failover. Ini juga memastikan bahwa permintaan selalu mendapatkan data dari salinan terbaru, secara otomatis memilih node yang memiliki data baru.
Saya telah membaca beberapa hal-hal baik di atasnya, dan secara keseluruhan kedengarannya cukup menjanjikan.
Federasi
Federasi mirip dengan pengelompokan, jadi saya menariknya ke sini juga. MySQL menawarkan federasi melalui mesin penyimpanan federasi. Mirip dengan solusi klaster NDB, solusi ini hanya berfungsi dengan baik dengan kueri sederhana - tetapi lebih buruk lagi klaster untuk yang rumit (karena latensi jaringan jauh lebih tinggi).
Replikasi dan penyeimbangan beban
MySQL memiliki kapasitas bawaan untuk membuat replikasi database di server yang berbeda. Ini dapat digunakan untuk banyak hal - membagi beban antar server, hot backup, membuat server uji, dan failover.
Pengaturan dasar replikasi melibatkan satu server master yang menangani sebagian besar penulisan dan satu atau lebih budak yang menangani hanya baca. Variasi yang lebih maju adalah master-master konfigurasi, yang memungkinkan untuk menskalakan penulisan juga dengan memiliki beberapa server yang menulis secara bersamaan.
Setiap konfigurasi memiliki pro dan kontra, tetapi satu masalah yang mereka alami adalah jeda replikasi - karena replikasi MySQL tidak sinkron, tidak semua node memiliki data terbaru setiap saat. Ini memerlukan aplikasi untuk mengetahui replikasi dan menggabungkan kueri yang sadar akan replikasi agar berfungsi seperti yang diharapkan. Untuk beberapa aplikasi, ini mungkin tidak menjadi masalah, tetapi jika Anda selalu membutuhkan data terbaru, semuanya menjadi agak rumit.
Replikasi memerlukan beberapa penyeimbangan beban untuk membagi beban antar node. Ini bisa sesederhana beberapa modifikasi pada kode aplikasi, atau menggunakan solusi perangkat lunak dan perangkat keras khusus.
Sharding dan partisi
Sharding adalah pendekatan yang umum digunakan untuk menskalakan solusi basis data. Anda membagi data menjadi pecahan yang lebih kecil dan menyebarkannya di sekitar node server yang berbeda. Hal ini mengharuskan aplikasi untuk menyadari modifikasi pada penyimpanan data agar bekerja secara efisien, karena perlu mengetahui di mana menemukan informasi yang dibutuhkan.
Ada kerangka kerja abstraksi yang tersedia untuk membantu menangani pemisahan data, seperti Hibernate Shards , ekstensi ke Hibernate ORM (yang sayangnya ada di Java. Saya menggunakan PHP). HiveDB adalah solusi lain yang juga mendukung shard rebalancing.
Lainnya
Sphinx
Sphinx adalah mesin pencari teks lengkap, yang dapat digunakan lebih dari sekadar pencarian percobaan. Untuk banyak kueri, ini jauh lebih cepat daripada MySQL (terutama untuk pengelompokan dan penyortiran), dan dapat meminta sistem jarak jauh secara paralel dan menggabungkan hasilnya - yang membuatnya sangat berguna saat digunakan dengan sharding.
Secara umum sphinx harus digunakan dengan solusi penskalaan lain untuk mendapatkan lebih banyak perangkat keras dan infrastruktur yang tersedia. Kelemahannya adalah sekali lagi Anda memerlukan kode aplikasi untuk mengetahui sphinx agar dapat menggunakannya dengan bijak.
Ringkasan
Solusi penskalaan berbeda tergantung pada kebutuhan aplikasi yang membutuhkannya. Bagi kami dan untuk sebagian besar aplikasi web, saya percaya bahwa replikasi (mungkin multi-master) adalah cara yang harus dilakukan dengan penyeimbang beban yang mendistribusikan beban. Membagi area masalah tertentu (tabel besar) juga merupakan keharusan untuk dapat menskalakan secara horizontal.
Saya juga akan mencoba Continuent Sequoia dan melihat apakah itu benar-benar dapat melakukan apa yang dijanjikan karena itu akan melibatkan paling sedikit perubahan pada kode aplikasi.
