Saya ingin mengajukan pertanyaan tentang praktik terbaik yang dijelaskan dalam dokumen ini:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

Gunakan beberapa router kueri. Gunakan beberapa proses mongo yang tersebar di beberapa server. Penempatan umum adalah untuk bersama-sama menempatkan proses mongo di server aplikasi, yang memungkinkan komunikasi lokal antara aplikasi dan proses mongo. Jumlah proses mongo yang tepat akan tergantung pada sifat aplikasi dan penyebaran.

Hanya sedikit latar belakang tentang penempatan kami. Kami memiliki banyak node server aplikasi. Masing-masing menjalankan satu proses berbasis JVM dengan stateless RESTful WS. Seperti yang disarankan praktik terbaik ini, setiap node server aplikasi tunggal menjalankan mongosprosesnya sendiri , yang berarti bahwa jumlah proses JVM selalu sama dengan jumlah mongosproses.

Semua mongosproses terhubung ke 3 server konfigurasi dan beberapa pecahan mongo (dengan set replika di dalam setiap pecahan). Meskipun kami menggunakan penyebaran berjuntai, kami tidak benar-benar menagih koleksi kami. Sebenarnya kami memiliki sejumlah besar basis data yang tersebar di semua pecahan selama waktu pembuatannya (dan ini adalah kasus penggunaan utama kami untuk pecahan saat ini).

Karena praktik terbaik juga menyarankan bahwa "Jumlah proses mongo yang tepat akan tergantung pada sifat aplikasi dan penyebaran" Saya mulai bertanya-tanya apakah penggunaan kami mongosbenar-benar tepat atau apakah akan lebih baik bagi kami untuk memiliki beberapa mongossimpul khusus dan membiarkan server aplikasi kami terhubung ke mereka tanpa harus mongosberjalan secara lokal.

Apa pendapat Anda tentang pendekatan terbaik untuk memutuskan berapa banyak mongosinstance yang sesuai dalam kaitannya dengan jumlah instance server aplikasi atau ukuran cluster MongoDB?

Baru-baru ini kami mulai melihat ke manajemen cluster untuk layanan web stateless kami, yang saya maksudkan alat seperti Docker, Apache Mesos, dan Kubernetes. Jika kita menggunakan Docker, maka biasanya tidak disarankan untuk menjalankan lebih dari satu proses dalam wadah. Mempertimbangkan fakta ini menjadi sangat sulit untuk memastikan bahwa container dan container server aplikasi mongosselalu berada pada node fisik yang sama dan memiliki jumlah proses yang sama. Ini membuat saya bertanya-tanya apakah praktik terbaik ini masih berlaku untuk arsitektur cluster yang baru saja saya jelaskan. Jika tidak, dapatkah Anda menyarankan apa cara terbaik untuk menemukan dan menggunakan mongosproses dalam arsitektur ini?

Karena sudah ada dan jawaban yang diajukan, dan yang berguna dan valid pada saat itu, saya tidak ingin mengalihkan perhatian dari kegunaannya sendiri tetapi memang ada poin untuk meningkatkan yang melampaui komentar singkat. Jadi pertimbangkan ini "augmentasi", yang diharapkan sah tetapi terutama di samping apa yang telah dikatakan.

Yang benar adalah untuk benar-benar mempertimbangkan "bagaimana aplikasi Anda menggunakan data", dan juga untuk menyadari faktor-faktor dalam "lingkungan yang terbengkalai" serta "lingkungan wadah" yang Anda usulkan yang memengaruhi hal ini.

Kasus Latar Belakang

Pandangan umum pada rekomendasi praktik untuk co-locating mongosproses bersama dengan contoh aplikasi adalah untuk meniadakan setiap overhead jaringan yang diperlukan agar aplikasi untuk berkomunikasi dengan mongosproses itu. Tentu saja ini juga merupakan "praktik yang disarankan" untuk menentukan sejumlah mongosinstance dalam string koneksi aplikasi dalam kasus di mana simpul "terdekat" tidak tersedia untuk beberapa alasan maka yang lain dapat dipilih, meskipun dengan kemungkinan biaya overhead untuk menghubungi suatu simpul jarak jauh.

Kasus "buruh pelabuhan" yang Anda sebutkan tampaknya agak arbitrer. Meskipun benar bahwa salah satu tujuan utama wadah (dan sebelum itu, sesuatu seperti penjara BSD atau bahkan chroot) umumnya untuk mencapai beberapa tingkat "proses isolasi", tidak ada yang salah dengan menjalankan banyak proses selama Anda memahami implikasinya.

Dalam kasus khusus mongosini dimaksudkan untuk menjadi "ringan" dan dijalankan sebagai "fungsi tambahan" untuk proses aplikasi dengan cara yang cukup banyak "bagian" dari aplikasi itu sendiri. Jadi buruh pelabuhan gambar sendiri tidak memiliki proses seperti "initd" tetapi tidak ada yang salah dengan menjalankan pengontrol proses seperti supervisord (misalnya) sebagai proses utama untuk wadah yang kemudian memberi Anda titik proses kontrol atas wadah itu juga. Situasi "proses berpasangan" ini adalah kasus yang masuk akal dan juga cukup umum meminta ada dokumentasi resmi untuknya.

Jika Anda memilih jenis operasi "berpasangan" untuk ditempatkan, maka operasi itu memang menangani titik utama mempertahankan mongosinstance pada koneksi jaringan yang sama dan memang "instance server" sebagai server aplikasi itu sendiri. Ini juga dapat dilihat dalam beberapa cara sebagai kasus di mana "seluruh wadah" gagal maka simpul itu sendiri hanya akan tidak valid. Bukannya saya akan merekomendasikan itu, dan pada kenyataannya Anda mungkin harus mengkonfigurasi koneksi untuk mencari mongoscontoh lain bahkan jika ini hanya dapat diakses melalui koneksi jaringan yang meningkatkan latensi.

Khusus Versi / Penggunaan Khusus

Sekarang setelah titik itu dibuat, pertimbangan lain di sini kembali ke pertimbangan awal dari co-locating mongosproses dengan aplikasi untuk keperluan latensi jaringan. Dalam versi MongoDB sebelum 2.6 dan secara khusus berkenaan dengan operasi seperti dengan kerangka agregasi, maka ada kasus bahwa akan ada lebih banyak lalu lintas jaringan dan selanjutnya setelah pekerjaan pemrosesan dilakukan oleh mongosproses untuk menangani data dari pecahan yang berbeda. . Itu tidak begitu banyak terjadi sekarang karena banyak dari beban kerja pemrosesan sekarang dapat dilakukan pada pecahan itu sendiri sebelum "menyaring" ke "router".

Kasus lainnya adalah pola penggunaan aplikasi Anda sendiri terkait dengan sharding. Itu berarti apakah beban kerja utama adalah dalam "mendistribusikan tulisan" di beberapa pecahan, atau memang menjadi pendekatan "pencar-pengumpulan" dalam mengkonsolidasikan permintaan baca. Dalam skenario itu

Tes, Uji dan Uji lagi

Jadi poin terakhir di sini benar-benar jelas, dan sampai pada konsensus dasar dari setiap tanggapan yang masuk akal terhadap pertanyaan Anda. Ini bukan hal baru untuk MongoDB atau solusi penyimpanan lainnya, tetapi lingkungan penempatan Anda yang sebenarnya perlu diuji pada "pola penggunaan" itu sedekat mungkin dengan realitas aktual seperti halnya "pengujian unit" dari fungsionalitas yang diharapkan dari komponen inti atau hasil keseluruhan perlu diuji.

Benar-benar tidak ada pernyataan "pasti" untuk mengatakan "konfigurasikan dengan cara ini" atau "gunakan dengan cara ini" yang sebenarnya masuk akal selain menguji apa yang "benar-benar berfungsi terbaik" untuk kinerja dan keandalan aplikasi Anda seperti yang diharapkan.

Tentu saja "kasus terbaik" akan selalu untuk tidak "kerumunan" mongoscontoh dengan permintaan dari sumber server aplikasi "banyak". Tetapi kemudian untuk memungkinkan mereka beberapa "paritas" alami yang dapat didistribusikan oleh beban kerja sumber daya yang tersedia untuk memiliki "setidaknya" "kumpulan sumber daya" yang dapat dipilih, dan memang idealnya dalam banyak kasus tetapi mengeliminasi kebutuhan untuk mendorong tambahan "overhead transportasi jaringan".

Itulah tujuannya, tetapi idealnya Anda dapat "menguji laboratorium" konfigurasi yang dipersepsikan berbeda untuk mendapatkan solusi "paling cocok" untuk solusi penempatan Anda yang akhirnya.

Saya juga akan sangat merekomendasikan kursus "gratis" (seperti dalam bir) yang tersedia seperti yang telah disebutkan, dan tidak peduli apa tingkat pengetahuan Anda. Saya menemukan bahwa berbagai sumber materi pelajaran sering menawarkan "permata tersembunyi" untuk memberikan lebih banyak wawasan tentang hal-hal yang mungkin tidak Anda pertimbangkan atau abaikan. The M102 Kelas seperti yang disebutkan dibangun dan dilakukan oleh Adam Commerford untuk siapa saya bisa atestasi memiliki tingkat tinggi pengetahuan tentang penyebaran skala besar MongoDB dan arsitektur data lainnya. Sepadan dengan waktu untuk setidaknya mempertimbangkan perspektif baru tentang apa yang Anda pikir sudah Anda ketahui.

Karena praktik terbaik juga menyarankan bahwa "Jumlah proses mongo yang tepat akan tergantung pada sifat aplikasi dan penyebaran" Saya mulai bertanya-tanya apakah penggunaan mongo kita benar-benar sesuai

Saya pikir ini adalah pertanyaan yang pada akhirnya hanya Anda yang bisa menjawab, sebagaimana merujuk pada dokumentasi.

Salah satu strategi yang direkomendasikan adalah memiliki mongoslayanan pada masing-masing node aplikasi dan bahkan mungkin satu node khusus untuk ketersediaan tambahan. Karena Anda memiliki ini saat ini, saya tidak melihat ada yang salah dengan penyebaran Anda saat ini. Jika tidak ada yang berubah dalam arsitektur Anda, maka Anda berada dalam praktik terbaik saat ini. Namun...

Jika kita menggunakan Docker, maka biasanya tidak disarankan untuk menjalankan lebih dari satu proses dalam wadah.

Karena mongosprosesnya tidak terlalu intensif sumber daya, Anda juga dapat meletakkannya di masing-masing pecahan dan membiarkan setiap mongodsimpul juga bertindak sebagai mongossimpul. Ini mungkin lebih masuk akal jika Anda membuat arsitektur server aplikasi Anda sedikit lebih kompleks.

Saya pribadi tidak terlalu terbiasa dengan produk-produk ini, tetapi saya juga akan memeriksa dengan vendor pada rekomendasi mereka karena mongosmungkin kurang intensif daripada kebanyakan proses lain yang dapat Anda jalankan berdampingan.

Akhirnya, Anda selalu dapat menggunakan node khusus untuk mongosproses tergantung pada skala Anda, sumber daya, dll. Yang juga akan masuk dalam praktik terbaik. Yang benar-benar dibawa pulang di sini adalah selama Anda memiliki banyak mongosproses di suatu tempat maka Anda melakukannya dengan baik.

Berapa banyak yang benar-benar tergantung pada ukuran penempatan dan persyaratan SLA Anda. Jika Anda menggunakan pecahan, Anda akan memiliki lebih dari cukup, tetapi jika Anda akan menggunakan node khusus saya akan mencoba untuk mencocokkan jumlah node aplikasi sedekat mungkin.

Anda dapat melihat video ini dari kursus online MongoDB M102 yang membahas topik-topik ini dan mungkin ingin mencoba mendaftar untuk kelas M102 untuk DBA lain kali dalam sesi (gratis, online).