Bagaimana cara mengkonfigurasi driver MongoDB Java MongoOptions untuk penggunaan produksi?

Diperbarui ke 2.9 :

• autoConnectRetry berarti pengemudi akan secara otomatis mencoba menyambung kembali ke server setelah terputus secara tidak terduga. Di lingkungan produksi, Anda biasanya ingin set ini ke true.

• koneksiPerHost adalah jumlah koneksi fisik yang dapat dibuat oleh satu instance Mongo (tunggal sehingga Anda biasanya memiliki satu per aplikasi) untuk proses mongod/mongos. Pada saat penulisan, driver Java akan membuat jumlah koneksi ini pada akhirnya bahkan jika throughput kueri yang sebenarnya rendah (dengan kata lain Anda akan melihat statistik "sambungan" di mongostat meningkat hingga mencapai angka ini per server aplikasi).

  Tidak perlu mengatur ini lebih tinggi dari 100 dalam banyak kasus tetapi pengaturan ini adalah salah satu dari hal-hal "uji dan lihat". Perhatikan bahwa Anda harus memastikan bahwa Anda mengatur ini cukup rendah sehingga jumlah total koneksi ke server Anda tidak melebihi

  db.serverStatus().connections.available

  Dalam produksi saat ini kami memiliki ini di 40.

• waktu koneksi habis . Seperti namanya, jumlah milidetik yang ditunjukkan oleh pengemudi akan menunggu sebelum upaya koneksi dibatalkan. Tetapkan batas waktu ke sesuatu yang lama (15-30 detik) kecuali ada kemungkinan realistis yang diharapkan, ini akan menghalangi upaya koneksi yang berhasil. Biasanya jika upaya koneksi membutuhkan waktu lebih dari beberapa detik, infrastruktur jaringan Anda tidak mampu menghasilkan throughput yang tinggi.

• maxWaitTime . Jumlah ms utas akan menunggu koneksi tersedia di kumpulan koneksi, dan menimbulkan pengecualian jika ini tidak terjadi tepat waktu. Tetap default.

• socketTimeout . Nilai batas waktu soket standar. Setel ke 60 detik (60000).

• utasAllowedToBlockForConnectionMultiplier . Pengganda untuk koneksiPerHost yang menunjukkan jumlah utas yang diizinkan menunggu koneksi tersedia jika kumpulan saat ini habis. Ini adalah pengaturan yang akan menyebabkan pengecualian "com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores to get db connection". Ini akan membuang pengecualian ini setelah antrian utas ini melebihi nilai threadsAllowedToBlockForConnectionMultiplier. Misalnya, jika connectionPerHost adalah 10 dan nilai ini adalah 5, hingga 50 utas dapat memblokir sebelum pengecualian yang disebutkan di atas dibuang.

  Jika Anda mengharapkan puncak besar dalam throughput yang dapat menyebabkan antrian besar untuk sementara meningkatkan nilai ini. Kami memilikinya di 1500 saat ini untuk alasan itu. Jika beban kueri Anda secara konsisten melebihi server, Anda harus meningkatkan situasi perangkat keras/penskalaan Anda.

• readPreference . (DIPERBARUI, 2.8+) Digunakan untuk menentukan preferensi baca default dan menggantikan "slaveOk". Siapkan ReadPreference melalui salah satu metode pabrik kelas. Deskripsi lengkap tentang setelan yang paling umum dapat ditemukan di akhir postingan ini

• dengan . (DIPERBARUI, 2.6+) Nilai ini menentukan "keamanan" penulisan. Ketika nilai ini adalah -1, penulisan tidak akan melaporkan kesalahan apa pun terlepas dari kesalahan jaringan atau basis data. WriteConcern.NONE adalah WriteConcern standar yang sesuai untuk ini. Jika w adalah 0 maka kesalahan jaringan akan membuat penulisan gagal tetapi kesalahan mongo tidak. Ini biasanya disebut sebagai penulisan "api dan lupakan" dan harus digunakan ketika kinerja lebih penting daripada konsistensi dan daya tahan. Gunakan WriteConcern.NORMAL untuk mode ini.

  Jika Anda menyetel w ke 1 atau lebih tinggi, penulisan dianggap aman. Penulisan aman melakukan penulisan dan menindaklanjutinya dengan permintaan ke server untuk memastikan penulisan berhasil atau mengambil nilai kesalahan jika tidak (dengan kata lain, mengirimkan perintah getLastError() setelah Anda menulis). Perhatikan bahwa sampai perintah getLastError() ini selesai, koneksi dicadangkan. Sebagai akibatnya dan perintah tambahan, throughput akan jauh lebih rendah daripada penulisan dengan w <=0. Dengan nilai w tepat 1 MongoDB menjamin penulisan berhasil (atau benar-benar gagal) pada saat Anda mengirim penulisan.

  Dalam kasus set replika, Anda dapat menggunakan nilai yang lebih tinggi untuk w yang memberi tahu MongoDB untuk mengirim penulisan ke setidaknya anggota "w" dari set replika sebelum kembali (atau lebih tepatnya, tunggu replikasi penulisan Anda ke anggota "w" ). Anda juga dapat menyetel w ke string "mayoritas" yang memberi tahu MongoDB untuk melakukan penulisan ke sebagian besar anggota kumpulan replika (WriteConcern.MAJORITY). Biasanya Anda harus mengatur ini ke 1 kecuali Anda membutuhkan kinerja mentah (-1 atau 0) atau penulisan yang direplikasi (>1). Nilai yang lebih tinggi dari 1 memiliki dampak yang cukup besar pada throughput tulis.

• fsinkron . Opsi daya tahan yang memaksa mongo untuk menyiram ke disk setelah setiap penulisan saat diaktifkan. Saya tidak pernah mengalami masalah daya tahan terkait dengan backlog penulisan, jadi kami memiliki ini pada false (default) dalam produksi.

• j *(BARU 2,7+) *. Boolean bahwa ketika disetel ke true memaksa MongoDB untuk menunggu komit grup penjurnalan yang berhasil sebelum kembali. Jika penjurnalan diaktifkan, Anda dapat mengaktifkan ini untuk daya tahan tambahan. Lihat http://www.mongodb.org/display/DOCS/Journaling untuk melihat jurnal apa yang Anda dapatkan (dan dengan demikian mengapa Anda mungkin ingin mengaktifkan tanda ini).

Preferensi Baca Kelas ReadPreference memungkinkan Anda untuk mengonfigurasi kueri instance mongod apa yang dirutekan jika Anda bekerja dengan set replika. Opsi berikut tersedia:

• ReadPreference.primary() :Semua bacaan hanya ditujukan ke anggota utama yang direset. Gunakan ini jika Anda memerlukan semua kueri untuk mengembalikan data yang konsisten (yang paling baru ditulis). Ini adalah default.

• ReadPreference.primaryPreferred() :Semua bacaan pergi ke anggota utama yang direset jika memungkinkan tetapi dapat meminta anggota sekunder jika simpul utama tidak tersedia. Dengan demikian, jika primer menjadi tidak tersedia, pembacaan pada akhirnya menjadi konsisten, tetapi hanya jika primer tidak tersedia.

• ReadPreference.secondary() :Semua pembacaan pergi ke anggota repset sekunder dan anggota utama hanya digunakan untuk menulis. Gunakan ini hanya jika Anda bisa hidup dengan bacaan yang konsisten. Anggota repset tambahan dapat digunakan untuk meningkatkan kinerja membaca meskipun ada batasan jumlah (voting) anggota yang dapat dimiliki oleh repset.

• ReadPreference.secondaryPreferred() :Semua bacaan pergi ke anggota repset sekunder jika ada yang tersedia. Anggota utama digunakan secara eksklusif untuk menulis kecuali semua anggota sekunder menjadi tidak tersedia. Selain fallback ke anggota utama untuk pembacaan, ini sama dengan ReadPreference.secondary().

• ReadPreference.nearest() :Membaca pergi ke anggota repset terdekat yang tersedia untuk klien database. Gunakan hanya jika pada akhirnya pembacaan yang konsisten dapat diterima. Anggota terdekat adalah anggota dengan latensi terendah antara klien dan berbagai anggota repset. Karena anggota yang sibuk pada akhirnya akan memiliki latensi yang lebih tinggi seharusnya juga secara otomatis menyeimbangkan beban baca meskipun menurut pengalaman saya sekunder (Lebih disukai) tampaknya melakukannya lebih baik jika latensi anggota relatif konsisten.

Catatan:Semua di atas memiliki versi yang mengaktifkan tag dari metode yang sama yang mengembalikan instance TaggableReadPreference sebagai gantinya. Deskripsi lengkap dari tag set replika dapat ditemukan di sini :Tag Set Replika