MongoDB против CouchDB (оптимизация скорости)

Просто для итерации сокетов против HTTP и fsync против разговора в памяти.

По умолчанию MongoDB не возвращает ответ на вызов записи. Вы просто записываете свои данные в сокет и предполагаете, что они есть в БД и доступны.При параллельной загрузке это может быть резервное хранилище, и нет хорошего способа узнать, насколько быстр Mongo really, если вы не используете дополнительный вызов, который вернет ответ на запись, как только данные будут доступны.

Я не говорю, что производительность вставки Mongo не быстрее, чем Couch, вставка в память намного быстрее, чем fsyncing на диск, большая разница здесь заключается в разнице в целях MongoDB и CouchDB в отношении согласованности и долговечности. Но все инструменты «производительности», которые я видел для тестирования Mongo, используют API записи по умолчанию, поэтому вы на самом деле не тестируете производительность вставки, а проверяете, как быстро вы можете смыть в сокет.

Я видел много тестов, которые показывают, что Mongo быстрее, чем Redis и memcached, потому что они не понимают, что Redis и Memcached возвращают ответ, когда данные находятся в памяти, а Mongo нет. Mongo определенно не быстрее, чем Redis :)

Я не думаю, что разница между сокетами и http является единственной разницей. Разница также связана с синхронизацией диска (fsync). Это сказывается на долговечности. MongoDB сначала сохраняет все в ОЗУ и синхронизируется с диском только через определенные промежутки времени, если вы явно не укажете MongoDB выполнить fsync.

Прочтите о долговечности и MongoDB: http://blog.mongodb.org/post/381927266/what-about-durability и fsync: http://www.mongodb.org/ display / DOCS / fsync + Command

Вот идея, о которой я думал, но не тестировал. Я ожидаю, что он будет отличным в определенных ситуациях:

• Пропускная способность вставки должна быть высокой
• Получение отдельных документов по ключу не требуется
• Все данные выбираются через представления (возможно, другая машина, отличная от той, которая получает вставки)

План

Вставляйте пакеты документов и используйте представления для их правильной сериализации.

Пример

Рассмотрим файл журнала с простой меткой времени и строкой сообщения.

0.001 Start
0.123 This could be any message
0.500 Half a second later!
1.000 One second has gone by
2.000 Two seconds has gone by
[...]
1000.000 One thousand seconds has gone by

Вы можете вставлять журналы по одному сообщению в документ, например:

{ "_id": "f30d09ef6a9e405994f13a38a44ee4a1",
  "_rev": "1-764efa883dda1e11db47671c4a3bbd9e",
  "timestamp": 0.123,
  "message": "This could be any message"
}

Стандартная оптимизация объемных документов

Первая оптимизация - это вставка с использованием _bulk_docs , как в документации по объемным документам CouchDB .

Вторичная оптимизация массовой вставки

Однако вторая оптимизация заключается в предварительном объединении журналов в один более крупный документ Couch . Например, пакетами по 4 (в реальном мире это было бы намного больше):

{ "_id": "f30d09ef6a9e405994f13a38a44ee4a1",
  "_rev": "1-764efa883dda1e11db47671c4a3bbd9e",
  "logs": [
    {"timestamp": 0.001, "message": "Start"},
    {"timestamp": 0.123, "message": "This could be any message"},
    {"timestamp": 0.500, "message": "Half a second later!"},
    {"timestamp": 1.000, "message": "One second has gone by"}
  ]
}

{ "_id": "74f615379d98d3c3d4b3f3d4ddce82f8",
  "_rev": "1-ea4f43014d555add711ea006efe782da",
  "logs": [
    {"timestamp": 2.000, "message": "Two seconds has gone by"},
    {"timestamp": 3.000, "message": "Three seconds has gone by"},
    {"timestamp": 4.000, "message": "Four seconds has gone by"},
    {"timestamp": 5.000, "message": "Five seconds has gone by"},
  ]
}

Конечно, вы могли бы вставить их также через _bulk_docs , эффективно вставляя пакеты пакетов данных .

Представления по-прежнему очень просты

По-прежнему очень легко сериализовать журналы обратно в представление:

// map
function(doc) {
  if(doc.logs) {
    // Just unroll the log batches!
    for (var i in doc.logs) {
      var log = doc.logs[i];
      emit(log.timestamp, log.message);
    }
  }
}

Тогда будет довольно легко получить журналы с отметками времени между startkey , endkey или что-то еще, что у вас есть.

Заключение

Это все еще не тестировалось, но я надеюсь, что для некоторых типов данных группирование данных сократит количество записей во внутреннем B-дереве.В сочетании с _bulk_docs я надеюсь увидеть, что пропускная способность при вставке превысит аппаратную скорость диска.