Чтобы протестировать мой MongoDB 3.2 / WiredTiger на CentOS6, я использую сценарий из http://vladmihalcea.com/2013/12/01/mongodb-facts-80000-insertssecond-on-commodity-hardware/. Здесь я перечисляю сценарий (немного измененный):
// Run me as:
// mongo random --eval "var arg1=50000000;arg2=1" create_random.js
var minDate = new Date(2012, 0, 1, 0, 0, 0, 0);
var maxDate = new Date(2013, 0, 1, 0, 0, 0, 0);
var delta = maxDate.getTime() - minDate.getTime();
var job_id = arg2;
var documentNumber = arg1;
var batchNumber = 5 * 2000;
var job_name = 'Job#' + job_id
var start = new Date();
var tsPrev = start;
var batchDocuments = new Array();
var index = 0;
while(index < documentNumber) {
var date = new Date(minDate.getTime() + Math.random() * delta);
var value = Math.random();
var document = {
created_on : date,
value : value
};
batchDocuments[index % batchNumber] = document;
if((index + 1) % batchNumber == 0) {
db.randomData.insert(batchDocuments, {writeConcern:{w:0}, ordered: false});
}
index++;
if(index % 100000 == 0) {
var tsNow = new Date();
print(job_name + ' inserted ' + index + ' documents in ' + (tsNow-tsPrev)/1000 + 's; Total time: ' + (tsNow-start)/1000 + 's');
tsPrev = tsNow;
}
}
print(job_name + ' inserted ' + documentNumber + ' in ' + (new Date() - start)/1000.0 + 's');
Я получаю в среднем 11 000 вкладышей в секунду независимо от количества документов в пакете, записи концерта или заказанного флажка. Данные монгостатов:
insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time
15424 *0 *0 *0 0 1|0 0.5 17.6 0 3.2G 2.8G 0|0 0|1 930k 18k 33 2015-12-15T23:32:40+01:00
12430 *0 *0 *0 0 6|0 0.5 17.6 0 3.2G 2.8G 0|0 0|0 807k 19k 33 2015-12-15T23:32:41+01:00
14330 *0 *0 *0 0 1|0 0.5 17.6 0 3.2G 2.8G 0|0 0|1 868k 18k 33 2015-12-15T23:32:42+01:00
15670 *0 *0 *0 0 1|0 0.5 17.6 0 3.2G 2.8G 0|0 0|0 992k 18k 33 2015-12-15T23:32:43+01:00
10794 *0 *0 *0 0 1|0 0.5 17.6 0 3.2G 2.8G 0|0 0|1 620k 18k 33 2015-12-15T23:32:44+01:00
15370 *0 *0 *0 0 1|0 0.6 17.7 0 3.2G 2.8G 0|0 0|1 992k 18k 33 2015-12-15T23:32:45+01:00
13836 *0 *0 *0 0 6|0 0.6 17.7 0 3.2G 2.8G 0|0 0|0 869k 19k 33 2015-12-15T23:32:46+01:00
13900 *0 *0 *0 0 1|0 0.6 17.7 0 3.2G 2.8G 0|0 0|1 806k 18k 33 2015-12-15T23:32:47+01:00
15121 *0 *0 *0 0 1|0 0.6 17.7 0 3.2G 2.9G 0|0 0|1 992k 18k 33 2015-12-15T23:32:48+01:00
11040 *0 *0 *0 0 1|0 0.6 17.7 0 3.2G 2.9G 0|0 0|1 682k 18k 33 2015-12-15T23:32:49+01:00
Данные из самого скрипта:
Job#3 inserted 100000 documents in 7.353s; Total time: 7.353s
Job#3 inserted 200000 documents in 7.261s; Total time: 14.614s
Job#3 inserted 300000 documents in 7.495s; Total time: 22.109s
Job#3 inserted 400000 documents in 8.094s; Total time: 30.203s
Job#3 inserted 500000 documents in 7.39s; Total time: 37.593s
Job#3 inserted 600000 documents in 8.088s; Total time: 45.681s
Job#3 inserted 700000 documents in 7.682s; Total time: 53.363s
Job#3 inserted 800000 documents in 7.728s; Total time: 61.091s
Даже близко к 80 000 ин / с.
iostats 10 дает:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.40 0.00 2.40 0 24
sdb 34.70 0.00 1801.20 0 18012
avg-cpu: %user %nice %system %iowait %steal %idle
3.72 0.00 0.58 0.03 0.00 95.67
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 26.10 0.40 5464.40 4 54644
sdb 32.50 0.00 1889.60 0 18896
У меня 32 ГБ ОЗУ, процессор Intel (R) Xeon (R) E5-2620 0 @ 2,00 ГГц и SSD 1T IBM ServeRAID M5110e (scsi).
В чем может быть причина такой низкой производительности относительно результатов блога? Где я могу найти больше тестов на MongoDB, чтобы иметь ориентир?
Когда была написана эта статья, установка MongoDB по умолчанию была настроена на небезопасную запись. Он отлично показал себя в тестах, но не так хорошо сохранил ваши данные.
https://aphyr.com/posts/284-call-me-maybe-mongodb
До недавнего времени клиенты для MongoDB по умолчанию не беспокоились о проверке успешности их записи: они просто отправляли их и предполагали, что все идет нормально. Все идет так хорошо, как и следовало ожидать.
https://blog.rainforestqa.com/2012-11-05-mongodb-gotchas-and-how-to-avoid-them/
MongoDB по умолчанию позволяет выполнять очень быструю запись и обновление. Компромисс заключается в том, что вы не получаете явного уведомления о сбоях. По умолчанию большинство драйверов выполняют асинхронную, «небезопасную» запись - это означает, что драйвер не возвращает ошибку напрямую, подобно INSERT DELAYED с MySQL. Если вы хотите узнать, удалось ли что-то, вам нужно вручную проверить наличие ошибок с помощью getLastError.
В случаях, когда вы хотите, чтобы при возникновении каких-либо проблем выдается сообщение об ошибке, в большинстве драйверов просто включить «безопасные» синхронные запросы. Это заставляет MongoDB действовать привычным образом для тех, кто переходит с более традиционной базы данных.
Скорее всего, вы видите результаты более безопасных настроек по умолчанию.