Benchmarking MongoDB - Mendorong Kinerja NoSQL

Sistem basis data adalah komponen penting dalam siklus aplikasi yang berjalan dengan sukses. Oleh karena itu, setiap organisasi yang melibatkan mereka memiliki mandat untuk memastikan kelancaran kinerja DBM ini melalui pemantauan yang konsisten dan penanganan kemunduran kecil sebelum berkembang menjadi komplikasi besar yang dapat mengakibatkan waktu henti aplikasi atau kinerja lambat.

Anda mungkin bertanya bagaimana Anda bisa tahu jika database benar-benar akan memiliki masalah saat bekerja secara normal? Nah, itulah yang akan kita bahas dalam artikel ini dan kita menyebutnya sebagai benchmarking. Pembandingan pada dasarnya menjalankan beberapa kumpulan kueri dengan beberapa data uji bersama dengan beberapa penyediaan sumber daya untuk menentukan apakah parameter ini memenuhi tingkat kinerja yang diharapkan.

MongoDB tidak memiliki metodologi pembandingan standar sehingga kami perlu menyelesaikan dalam pengujian kueri pada perangkat keras sendiri. Sebanyak mungkin Anda juga mendapatkan angka yang mengesankan dari proses benchmark, Anda harus berhati-hati karena ini mungkin kasus yang berbeda saat menjalankan database Anda dengan kueri nyata.

Gagasan di balik pembandingan adalah untuk mendapatkan gambaran umum tentang bagaimana opsi konfigurasi yang berbeda memengaruhi kinerja, bagaimana Anda dapat mengubah beberapa konfigurasi ini untuk mendapatkan kinerja maksimum dan memperkirakan biaya untuk meningkatkan implementasi ini. Selain itu, aplikasi tumbuh seiring waktu dalam hal pengguna dan mungkin jumlah data yang akan dilayani maka perlu melakukan beberapa perencanaan kapasitas sebelum waktu ini. Setelah menyadari tren data yang meningkat, Anda perlu melakukan beberapa tolok ukur tentang bagaimana Anda akan memenuhi persyaratan data yang berkembang pesat ini.

Pertimbangan dalam Pembandingan MongoDB

1. Pilih beban kerja yang merupakan representasi umum dari aplikasi modern saat ini. Aplikasi modern menjadi lebih kompleks setiap hari dan ini ditransmisikan ke struktur data. Artinya, penyajian data juga berubah seiring waktu misalnya menyimpan bidang sederhana ke objek dan array. Tidak mudah untuk bekerja dengan data ini dengan konfigurasi basis data default atau lebih tepatnya di bawah standar karena dapat meningkatkan masalah seperti latensi yang buruk dan operasi throughput yang buruk yang melibatkan data yang kompleks. Saat menjalankan benchmark, Anda harus menggunakan data yang merupakan presentasi yang jelas dari aplikasi Anda.
2. Periksa dua kali pada penulisan. Selalu pastikan bahwa semua penulisan data dilakukan dengan cara yang tidak memungkinkan kehilangan data. Ini untuk meningkatkan integritas data dengan memastikan data konsisten dan paling dapat diterapkan terutama di lingkungan produksi.
3. Gunakan volume data yang merupakan representasi dari kumpulan data "data besar" yang tentunya akan melebihi kapasitas RAM untuk setiap node. Jika beban kerja pengujian besar, ini akan membantu Anda memprediksi ekspektasi kinerja database Anda di masa mendatang, sehingga memulai beberapa perencanaan kapasitas cukup awal.

Metodologi

Uji benchmark kami akan melibatkan beberapa data lokasi besar yang dapat diunduh dari sini dan kami akan menggunakan perangkat lunak Robo3t untuk memanipulasi data kami dan mengumpulkan informasi yang kami butuhkan. File tersebut memiliki lebih dari 500 dokumen yang cukup untuk pengujian kami. Kami menggunakan MongoDB versi 4.0 pada Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3.4GHz dedicated server dengan 32GB RAM, Western Digital WD Caviar RE4 1TB spinning disk dan Smart XceedIOPS 256GB SSD. Kami memasukkan 500 dokumen pertama.

Kami menjalankan perintah insert di bawah

db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})

Tulis Kekhawatiran

Kekhawatiran penulisan menjelaskan tingkat pengakuan yang diminta dari MongoDB untuk operasi penulisan dalam hal ini ke MongoDB yang berdiri sendiri. Untuk operasi throughput tinggi, jika nilai ini disetel ke rendah maka panggilan tulis akan sangat cepat sehingga mengurangi latensi permintaan. Di sisi lain, jika nilainya ditetapkan tinggi, maka panggilan tulis menjadi lambat dan akibatnya meningkatkan latensi kueri. Penjelasan sederhana untuk ini adalah bahwa ketika nilainya rendah maka Anda tidak khawatir tentang kemungkinan kehilangan beberapa penulisan jika terjadi crash mongod, kesalahan jaringan, atau kegagalan sistem anonim. Batasan dalam hal ini adalah, Anda tidak akan yakin apakah penulisan ini berhasil. Di sisi lain, jika kekhawatiran penulisan tinggi, ada prompt penanganan kesalahan dan dengan demikian penulisan akan diakui. Pengakuan hanyalah tanda terima bahwa server menerima penulisan untuk diproses.

Dalam pengujian kami, masalah penulisan yang disetel ke rendah menghasilkan kueri yang dieksekusi dalam waktu minimal 0,013 md dan maksimal 0,017 md. Dalam hal ini, pengakuan dasar penulisan dinonaktifkan tetapi seseorang masih dapat memperoleh informasi mengenai pengecualian soket dan kesalahan jaringan apa pun yang mungkin telah dipicu.

Ketika masalah penulisan disetel tinggi, hampir membutuhkan waktu dua kali lipat untuk kembali dengan waktu eksekusi menjadi 0,027 mdtk dan maks 0,031 md. Pengakuan dalam hal ini dijamin tetapi tidak 100% telah mencapai jurnal disk. Dalam hal ini, kemungkinan kehilangan penulisan adalah 50% karena jendela 100 mdtk di mana jurnal mungkin tidak di-flush ke disk.

Penjurnalan

Ini adalah teknik untuk memastikan tidak ada kehilangan data dengan memberikan daya tahan jika terjadi kegagalan. Hal ini dicapai melalui write-ahead logging ke file jurnal on-disk. Ini paling efisien jika perhatian penulisan disetel tinggi.

Untuk disk yang berputar, waktu eksekusi dengan penjurnalan diaktifkan agak tinggi, misalnya dalam pengujian kami sekitar 0,251 md untuk operasi yang sama di atas.

Namun waktu eksekusi untuk SSD sedikit lebih rendah untuk perintah yang sama. Dalam pengujian kami, ini sekitar 0,207 md, tetapi tergantung pada sifat data, terkadang ini bisa 3 kali lebih cepat daripada disk yang berputar.

Saat penjurnalan diaktifkan, ini mengonfirmasi bahwa penulisan telah dilakukan ke jurnal dan karenanya memastikan ketahanan data. Akibatnya, operasi tulis akan bertahan dari shutdown mongod dan memastikan bahwa operasi tulis tahan lama.

Untuk operasi throughput tinggi, Anda dapat separuh waktu kueri dengan menyetel w=0. Jika tidak, jika Anda perlu memastikan bahwa data telah direkam atau lebih tepatnya akan dihidupkan kembali setelah kegagalan, maka Anda perlu menyetel w=1.

Replikasi

Pengakuan masalah penulisan dapat diaktifkan untuk lebih dari satu node yang merupakan primer dan beberapa sekunder dalam set replika. Ini akan dicirikan oleh bilangan bulat apa yang dinilai untuk parameter tulis. Misalnya, jika w =3, Mongod harus memastikan bahwa kueri menerima pengakuan dari simpul utama dan 2 budak. Jika Anda mencoba menetapkan nilai lebih besar dari satu dan node belum direplikasi, akan muncul kesalahan bahwa host harus direplikasi.

Replikasi datang dengan kemunduran latency sehingga waktu eksekusi akan meningkat. Untuk kueri sederhana di atas jika w=3, maka waktu eksekusi rata-rata meningkat menjadi 270 md. Faktor pendorong untuk ini adalah rentang waktu respons antara node yang dipengaruhi oleh latensi jaringan, overhead komunikasi antara 3 node dan kemacetan. Selain itu, ketiga node menunggu satu sama lain untuk menyelesaikan sebelum mengembalikan hasilnya. Dalam penerapan produksi, Anda tidak perlu melibatkan begitu banyak node jika ingin meningkatkan kinerja. MongoDB bertanggung jawab untuk memilih node mana yang akan dikenali kecuali ada spesifikasi dalam file konfigurasi menggunakan tag.

Spinning Disk vs Solid State Disk

Seperti disebutkan di atas, disk SSD cukup cepat daripada disk berputar tergantung pada data yang terlibat. Terkadang bisa 3 kali lebih cepat sehingga layak membayar jika perlu. Namun, akan lebih mahal untuk menggunakan SSD terutama ketika berhadapan dengan data yang sangat besar. MongoDB telah mendapat manfaat karena mendukung penyimpanan basis data dalam direktori yang dapat dipasang sehingga memungkinkan untuk menggunakan SSD. Menggunakan SSD dan mengaktifkan penjurnalan adalah pengoptimalan yang hebat.

Kesimpulan

Eksperimen tersebut memastikan bahwa masalah penulisan yang dinonaktifkan menghasilkan pengurangan waktu eksekusi kueri dengan mengorbankan peluang kehilangan data. Di sisi lain, ketika masalah penulisan diaktifkan, waktu eksekusi hampir 2 kali lipat saat dinonaktifkan tetapi ada jaminan bahwa data tidak akan hilang. Selain itu, kami dapat membenarkan bahwa SSD lebih cepat daripada disk Spinning. Namun, untuk memastikan ketahanan data jika terjadi kegagalan sistem, disarankan untuk mengaktifkan masalah penulisan. Saat mengaktifkan masalah penulisan untuk kumpulan replika, jangan atur angkanya terlalu besar sehingga dapat mengakibatkan penurunan kinerja dari akhir aplikasi.