Apa yang terjadi jika ada terlalu banyak sisipan di MongoDB? Bagaimana cara memastikan semua data disimpan?

Saya menggunakan MongoDB untuk menyimpan nilai yang diukur secara berkala. Setiap ~ 100 ms banyak nilai dimasukkan sebagai dokumen. Ini berfungsi dengan baik, tapi saya khawatir tentang masalah kinerja. (Saya menggunakan sisipan yang aman, sepertinya di PyMongo ini adalah default.)

Apa yang terjadi jika ada lebih banyak sisipan per detik dari yang dapat disimpan mongod ke hard disk? Apakah akan ada peringatan atau akan gagal secara diam-diam?

Apakah ada metode untuk memonitor beban tulis? Saya hanya menemukan db.serverStatus().writeBacksQueuedyang selalu disetel ke false ketika saya menyebutnya. Bagaimana saya bisa menguji berapa banyak data yang harus saya masukkan untuk mengisi antrian tulis?

mongostatmenampilkan kunci. Apakah ini sesuatu yang harus saya khawatirkan?

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

Apakah saya harus khawatir tentang kunci tulis? Apa yang terjadi pada sisipan selama periode waktu penulisan yang terkunci? Apakah itu antri dan disimpan nanti?

Saya berpikir tentang pengaturan replikasi sederhana menggunakan satu master dan satu slave. Apakah sinkronisasi awal atau proses sinkronisasi ulang mengunci basis data?

(Saya menggunakan versi 2.4.3.)

Pembaruan: Saya pikir sebagian sudah menjawab pertanyaan saya sendiri. Saya berhasil mendapatkan hingga 12.000 sisipan per detik menggunakan loop sederhana sambil memasukkan dokumen uji kecil. Tapi qr | qw masih menunjukkan bahwa ada antrian baca-dan tulis masih kosong:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

Saya kira ini berarti bahwa menyisipkan saja tidak akan menyebabkan banyak masalah: "Antrian akan cenderung lonjakan jika Anda melakukan banyak operasi penulisan bersama operasi tulis berat lainnya, seperti pemindahan jarak jauh yang besar." (ditemukan di sini ]

Pertanyaan terbuka saya: Apa yang terjadi pada data saya jika antrian tulis meningkat dalam jangka panjang?

Anda telah menjawab beberapa pertanyaan Anda sendiri di sini, khususnya Anda memiliki ide yang layak tentang aspek kunci tulis dari persamaan - 12.000 insert / sec membuat Anda ~ 60% menulis kunci. Itu tingkat yang masuk akal untuk mendapatkan kinerja yang konsisten - Anda akan mendapatkan beberapa pertengkaran, dan beberapa ops akan sedikit lebih lambat, tetapi Anda benar-benar ingin mulai mengkhawatirkan sekitar 80% - seperti banyak hal, ketika Anda mulai melebihi 80% tersedia kapasitas Anda akan mulai memukul masalah lebih sering.

Dalam hal hambatan lainnya, dan khususnya seberapa cepat Anda dapat menulis ke disk - ini dapat menyebabkan masalah, tetapi untuk melihat statistik yang relevan dari waktu ke waktu saya akan merekomendasikan memasang MMS dengan plugin munin-node untuk memberi Anda perangkat keras dan statistik IO di Selain statistik MongoDB.

Ketika Anda memilikinya, metrik yang ingin Anda perhatikan adalah:

• Waktu Flush Rata-rata (ini adalah waktu yang diperlukan untuk sinkronisasi berkala MongoDB ke disk)
• IOStats di tab perangkat keras (IOWTunggu khususnya)
• Kesalahan Halaman (jika disk Anda sibuk menulis dan Anda perlu membaca data, mereka akan bersaing untuk sumber daya yang langka)

Memang agak rumit, tapi inilah ide dasarnya:

• Ketika waktu rata-rata siram mulai meningkat, khawatir
• Jika masuk ke rentang beberapa detik, Anda mungkin berada pada batas (meskipun ini tergantung pada volume data yang ditulis dan kecepatan disk)
• Jika mendekati 60 detik, Anda akan melihat kinerja menurun secara drastis (flush terjadi setiap 60 detik, sehingga mereka pada dasarnya akan mengantri)
• IOWait tinggi juga akan menghambat kinerja, terutama jika Anda harus membaca dari disk kapan saja
• Oleh karena itu melihat tingkat kesalahan halaman juga akan menjadi penting

Bagian lain dari teka-teki ini, yang belum kami sebutkan, adalah jurnal. Itu akan menjadi data yang ada di disk juga (secara default setiap 100 ms) dan jadi itu akan menambah beban disk jika berada pada volume yang sama. Oleh karena itu jika Anda melihat pemanfaatan disk yang tinggi, maka memindahkan jurnal ke disk lain adalah ide yang bagus.

Tidak ada "angka ajaib" nyata untuk bertahan, dalam kebanyakan kasus itu semua relatif, jadi dapatkan garis dasar yang baik untuk lalu lintas normal Anda, periksa untuk melihat apakah ada yang sedang tren dan mungkin memuat tes untuk melihat apa batas Anda dan kapan hal-hal mulai menurun dan Anda akan berada dalam kondisi yang baik.

Setelah semua pra-amble, ke beberapa pertanyaan Anda:

Apa yang terjadi jika ada lebih banyak sisipan per detik dari yang dapat disimpan mongod ke hard disk? Apakah akan ada peringatan atau akan gagal secara diam-diam?

Jika Anda mulai menekankan disk ke tingkat yang dijelaskan di atas, pada akhirnya semuanya akan melambat dan pada titik tertentu (dan ini akan tergantung pada waktu menyendiri, seberapa gemuk perangkat keras Anda, bagaimana Anda menangani pengecualian) penulisan Anda akan gagal - jika Anda menggunakan versi terbaru dari pymongo maka Anda akan menggunakan aman menulis secara default dan kemudian gagal. Jika Anda ingin menjadi sedikit lebih paranoid, Anda kadang-kadang dapat melakukan kekhawatiran menulis tentang j: true yang akan menunggu untuk kembali OK sampai tulisan telah sampai ke jurnal (yaitu pada disk). Ini, tentu saja, akan lebih lambat daripada penulisan aman normal, tetapi ini akan menjadi indikasi langsung dari masalah kapasitas terkait disk, dan Anda dapat menggunakannya untuk memblokir / mengantri operasi lain dan pada dasarnya bertindak sebagai penghambat untuk mencegah database Anda dari menjadi kewalahan.

Saya berpikir tentang pengaturan replikasi sederhana menggunakan satu master dan satu slave. Apakah sinkronisasi awal atau proses sinkronisasi ulang mengunci basis data?

Saya pikir saya membahas penguncian secara keseluruhan pada awalnya, tetapi untuk menjawab bagian ini secara khusus: Pertama, pastikan Anda menggunakan set replika , bukan master / slave. Implementasi master / slave sudah usang dan tidak direkomendasikan untuk digunakan secara umum. Adapun sinkronisasi awal akan menambahkan beberapa memuat ke utama dalam hal membaca, tetapi tidak dalam hal menulis, jadi Anda harus baik-baik saja dalam hal penguncian.

Apa yang terjadi pada data saya jika antrian tulis meningkat dalam jangka panjang?

Seperti yang mungkin Anda ketahui dari penjelasan di atas, jawabannya sangat tergantung pada bagaimana Anda menulis aplikasi Anda, bagaimana Anda memilih agar tulisan Anda diakui dan berapa banyak kapasitas yang Anda miliki. Anda pada dasarnya bisa seaman yang Anda inginkan ketika menulis ke disk pada MongoDB, tetapi ada trade off kinerja, seperti yang disebutkan dalam j:truediskusi di atas.

Secara umum, Anda ingin mengetahui faktor pembatas Anda - baik itu mengunci, kecepatan disk, dll. Dan kemudian melacak level seiring waktu dan meningkatkan (sharding) atau naik (perangkat keras yang lebih baik) sebelum Anda mencapai batas keras dan melihat masalah kinerja.

Satu hal terakhir, db.serverStatus().writeBacksQueuedsebenarnya adalah metrik yang hanya akan menjadi nol di lingkungan yang terlantar, dan itu ada hubungannya dengan memastikan bahwa menulis ke bongkahan selama migrasi ditangani dengan tepat (ditangani oleh pendengar penulis kembali ). Oleh karena itu pada dasarnya ini adalah herring merah di sini - tidak ada hubungannya dengan volume tulis umum.