Я использую MongoDB для хранения периодически измеренных значений. Каждые ~ 100 мс связка значений вставляется как документ. Это отлично работает, но я беспокоюсь о проблемах производительности. (Я использую безопасные вставки, кажется, что в PyMongo это по умолчанию.)
Что произойдет, если число вставок в секунду больше, чем mongod может сохранить на жесткий диск? Будет ли какое-нибудь предупреждение или он просто молча провалится?
Есть ли способ контролировать загрузку записи? Я нашел только то, db.serverStatus().writeBacksQueued
что всегда устанавливается в ложь, когда я звоню. Как я могу проверить, сколько данных мне нужно вставить, чтобы заполнить очередь записи?
mongostat
отображает замки. Это то, что я должен беспокоиться?
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
Должен ли я беспокоиться о блокировках записи? Что происходит со вставкой в течение периода блокировки записи? Это поставлено в очередь и сохранено позже?
Я думаю о простой настройке репликации с использованием одного главного и одного подчиненного. Начальная синхронизация или процесс повторной синхронизации блокируют базы данных?
(Я использую версию 2.4.3.)
Обновление: я думаю, что частично ответил на мой собственный вопрос. Мне удалось получить до 12.000 вставок в секунду, используя простой цикл while для вставки небольшого тестового документа. Но qr | qw по-прежнему показывает, что там очередь на чтение и запись по-прежнему пуста:
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
Я предполагаю, что это означает, что одна только вставка не вызовет много проблем: «Очереди будут иметь тенденцию к скачкам, если вы выполняете много операций записи наряду с другими операциями записи с большими объемами операций, такими как операции удаления с большим диапазоном». (найдено здесь )
Мой открытый вопрос: что произойдет с моими данными, если очередь записи увеличится в долгосрочной перспективе?