Maaf sudah terlambat ke pesta. :) Inilah jawaban saya, berdasarkan telah menggunakan Mnesia sejak tahun 1996 dan berbagai teknologi database lainnya sejak tahun 1988.
Mnesia dan MySQL memang binatang yang berbeda, dan yang mana yang terbaik sangat tergantung pada bagaimana Anda bermaksud menggunakannya.
Jika aplikasi Anda ditulis dalam bahasa Erlang, Mnesia memungkinkan Anda untuk menyimpan data dalam ruang memori yang sama dengan aplikasi Anda, yang berarti Anda dapat mengambil objek data tunggal secepat beberapa mikrodetik. Ini tidak mungkin di MySQL, karena aplikasi Anda dan database akan dipisahkan dalam memori. Alasan mengapa Mnesia dapat melakukan ini dan masih kuat, adalah bahwa Erlang menerapkan 'perlindungan' memori di tingkat bahasa.
Secara keseluruhan, database SQL cenderung mendukung throughput lebih dari latensi, dan ketika datang ke latensi, Mnesia + Erlang umumnya luar biasa. Anda perlu memutuskan mana yang paling penting bagi Anda. Seperti yang tertulis dalam dokumen (di atas), aplikasi target Mnesia adalah aplikasi switching telekomunikasi, di mana persyaratan waktu respons untuk mis. Pengaturan panggilan sekitar 20 ms. Ini pada dasarnya berarti bahwa Anda bisa membaca dari database hanya jika data berada dalam memori bersama, tetapi akan menghindari penulisan ke penyimpanan persisten berdasarkan per-panggilan-pengaturan. OTOH, aplikasi ini praktis tidak memerlukan dukungan permintaan ad-hoc, dan tidak menggunakan set data yang sangat besar. Beberapa pekerjaan telah dilakukan untuk memperluas kesesuaian Mnesia untuk domain lain, tetapi itu bukan prioritas untuk tim pengembangan Erlang / OTP. Mnesia adalah apa adanya, dan cenderung tetap seperti itu.
Dalam tautan di atas di mana Mnesia dan MySQL dibandingkan untuk kecepatan, orang harus ingat bahwa itu ada di eJabberd, yang berjalan melawan satu server jika itu MySQL dan menjalankan database yang sepenuhnya direplikasi jika itu Mnesia - dan kelompok eJabberd besar dapat memiliki sebanyak 10 atau lebih erlang node (dan karenanya, 10 atau lebih replika Mnesia). Dari sudut pandang redundansi, ini cukup konyol dan mahal, dan Mnesia sama sekali tidak memaksa Anda untuk melakukannya. Ini jelas memberikan membaca cepat jahat pada setiap node, tetapi menulis akan sangat mahal. Beberapa perbandingan yang saya baca akhirnya membandingkan Mnesia terdistribusi dengan MySQL node tunggal; jika redundansi tidak diperlukan untuk MySQL, seharusnya tidak diperlukan juga untuk Mnesia. Mnesia cukup fleksibel dalam memungkinkan Anda memilih pola replikasi, dan lokasi data transparan untuk aplikasi.
Mnesia juga tidak terbatas pada 2 GB per tabel (meskipun opsi penyimpanan tertentu ). Basis data Mnesia terbesar yang saya tahu memiliki ca 600 GB data dalam (64-bit) RAM + disk - meskipun saya tidak merekomendasikan ini. Apa pun hingga 10-20 GB harus sepenuhnya baik-baik saja dengan perangkat keras modern, tetapi abaikan disc_only_copies sepenuhnya dan gunakan disc_copies - beli lebih banyak RAM jika perlu. Saya akan berpikir dua kali sebelum menggunakan dukungan sharding (mnesia_frag) - itu berfungsi, tetapi jarang sepadan dengan masalahnya.
Mungkin perbedaan terbesar antara Mnesia dan MySQL adalah SQL itu sendiri: Mnesia tidak benar-benar memiliki fungsi yang sebanding; QLC menawarkan beberapa dukungan untuk permintaan ad-hoc, tetapi tidak dalam tingkat yang sama dengan SQL, dan tingkat optimisasi kueri juga tidak. Dalam tooling dan provisi, MySQL juga lebih unggul, dan jika Anda memerlukan analitik, tidak ada pertanyaan yang harus Anda pilih (yaitu BUKAN Mnesia).
Cara terbaik untuk melihat Mnesia adalah sebagai perluasan ke bahasa Erlang. Ini menempatkan data tepat di ujung jari Anda, dan sangat baik untuk set data kecil di mana struktur data dan pola akses dikenal. Untuk tujuan ini, menggunakan MySQL sama tidak nyamannya dengan menggunakan Mnesia untuk hal-hal di mana MySQL bekerja paling baik.
Sebagian besar aplikasi berada di antara keduanya, dan di sinilah ia menjadi panggilan penilaian. Anda mungkin akhirnya menggunakan keduanya ...