Facebook, MySQL, dan 4000 Horisontal Partisi

4000 shard Instance of MySQL, wow cool

  Michael Stonebraker menulis dalam artikelnya yang berjudul Facebook trapped in MySQL ‘fate worse than death’ tentang bagaimana database MySQL dipergunakan oleh FaceBook. Saya sangat salut dengan para engineernya Facebook dalam menggunakan database MySQL. Bayangkan 4000 Shard Instance database MySQL dipergunakan bersama sama dan 9000 Instance MemCache.

Wow, 4000 shard instance ? apa itu shard ? shard itu dalam arti lain adalah “horisontal partition”, artinya data yang dimiliki dipisah kedalam 4000 Instance MySQL. Nah pemisahannya ini dilakukan secara logika,developer Facebook yang menentukan data A pergi ke Instance MySQL yang mana, data B pergi ke instance MySQL yang mana. Proses pemisahaan ini sangatlah rumit, parameter yang dipergunakan mungkin juga sangat banyak dan beragam. Pekerjaan besar untuk developernya.

Bayangkan pula, 4000 mesin itu bisa terletak di belahan dunia yang lain, mungkin saja ada yang di amerika, singapura, eropa, china dan sebagainya. Tentu saja mereka memiliki cara untuk menyatukan kembali data tersebut, detailnya saya juga kurang tahu.Tapi saya yakin prosesnya juga rumit.

Di artikel tersebut juga disebutkan, menurut informasi terakhir tahun 2008, Facebook memiliki 1800 server khusus hanya untuk MySQL dan 805 server untuk MemCache. Wow, menakjubkan. Tentu saja DBAnya akan bekerja keras untuk memaintain database server dengan jumlah sebanyak itu.

Kembali ke artikel yang di tulis pak michael, dia mengatakan, dengan jumlah database MySQL yang sangat banyak dan hanya bisa melakukan “horisontal partition” untuk scalabilitasnya, maka Facebook akan mengalami kesulitan jika arsitektur seperti ini di pertahankan. Mengapa ? karena untuk melakukan ini semua itu sangat kompleks, ribet, dan memusingkan.

Itulah sebabnya, pak michael menyarankan Facebook untuk memindahkan databaseny dari MySQL ke database yang lain yang dapat melakukan scalabilitas dengan benar. Beliau menyarankan untuk berpindah ke database dengan konsep NewSQL seperti database VoltDB, NimbusDB, dan GenieDB. Konsep ini berbeda dengan konsep NoSQL yang menurut beliau masih merupakan database MySQL dalam bentuk yang lain.

Sudah beberapa hari ini pendapat dari pak michael ini mengundang perdebatan diantara para developer database. Slashdot, salah satu website rujukan para developer, ikut pula menjadi ramai. Topik ini pun berkembang menjadi ajang membahas solusi apa yang tepat untuk Facebook. Menariknya para developer ini juga menyarankan untuk memakai PostgreSQL.

Apapun solusi yang ditawarkan, bagaimana bentuk pelaksanaannya, semua developer setuju dengan pendapat pak michael, Facebook harus segera “menulis ulang” applikasinya dan menggunakan database yang baru

Author: Nareswara

Ordinary People with eye glasses

Leave a Reply

Your email address will not be published. Required fields are marked *