Как выбрать из MMAPV1, WiredTiger или в памяти StorageEngine для MongoDB?
в документации MongoDb 3.2 я видел, что они поддерживают механизм хранения 3, MMAPV1, WiredTiger, In-Memory, очень запутанно, какой из них выбрать.
у меня есть ощущение от описание, что WiredTiger лучше, чем MMAPV1, но в других источниках они говорят, что MMAPV1 лучше для тяжелых чтений... и WiredTiger для тяжелых пишет...
есть ли какие-то ограничения, когда выбирать один над другим ? Может кто-нибудь предложить некоторые рекомендации по пример
когда у меня есть этот тип приложения, обычно лучше всего это, иначе выберите другой...
2 ответов
Это из личного опыта, однако, пожалуйста, посмотрите на эту запись в блоге, она объясняет очень хорошо различные типы двигателей: Mongo Blog v3
сравнение движков хранения MongoDB WiredTiger и MMAPv1.Высокая производительность и эффективность между 7X и 10x большая производительность записи MongoDB 3.0 обеспечивает более детальное управление параллелизмом на уровне документа, обеспечивая между 7x и 10x больше пропускная способность для большинства приложений с интенсивной записью при сохранении предсказуемой низкой задержки.
для меня выбор был очень прост, мне нужны блокировки уровня документа, что делает WiredTiger идеальный выбор, мы не имеем версию предприятия монго следовательно в двигателе памяти не доступен. MMAPv1 Btree-очень простой метод для отображения памяти на жесткий диск и не очень эффективный.
механизм хранения MMAP использует процесс называется "выделение записи" для захвата дискового пространства для хранения документов. Все записи расположены на диске, и когда документ становится больше выделенной записи, он должен выделить новую запись. Новые распределения требуют перемещения документа и обновления всех индексов, ссылающихся на документ, что занимает больше времени, чем обновления на месте, и приводит к фрагментации хранилища. Кроме того, MMAPv1 в текущих итерациях обычно приводит к высокому использованию пространства в вашей файловой системе из-за выделение записи и отсутствие поддержки сжатия. Как упоминалось ранее, схема блокировки механизма хранения данных является одним из наиболее важных факторов общей производительности базы данных. MMAPv1 имеет блокировку на уровне коллекции-это означает, что только одна операция вставки, обновления или удаления может использовать коллекцию одновременно. Этот тип схемы блокировки создает очень распространенный сценарий в параллельных рабочих нагрузках, где операции update/delete/insert всегда ждут операции впереди из них для завершения. Кроме того, часто эти операции протекают быстрее, чем они могут быть завершены последовательно двигателем хранения. Чтобы представить это в контексте, представьте себе гигантский супермаркет в воскресенье днем, в котором открыта только одна касса: много клиентов, но низкая пропускная способность!
У всех разные требования, но для большинства случаев WiredTiger будет идеальным выбором тот факт, что он делает атомарные операции на уровне документа, а не уровень сбора имеет большое преимущество, вы просто не можете победить, что.
больше читает и мало пишет
Если чтение является вашей главной заботой, вот один из способов решить эту проблему.
вы можете настроить драйвер Mongo Читать Режимы Предпочтений следующим образом:
- Setup Replica Set, скажем, 1 master и 3 secondaries.
- установить написать озабоченность большинство это сделает пишу немного медленнее (trade off).
- установите предпочтение чтения на вторичный.
Эта настройка будет работать очень хорошо, когда у вас много чтения, но в качестве компромисса запись будет медленнее. Однако пропускная способность считанных данных будет большой.
Я надеюсь, что это поможет, если у вас есть дополнительные вопросы, добавьте их в качестве комментария, и я попытаюсь рассмотреть его в этом ответе.
и MMAPv1 против WiredTiger обзор и обратите внимание, как он изменил его ум от MMAPv1 до WiredTiger. Продавец документ блокировки, что производительность вы просто не можете бить.
для новых проектов я использую WiredTiger сейчас. Поскольку миграция из сжатого в несжатое хранилище WiredTiger довольно проста, я, как правило, начинаю с сжатия, чтобы повысить загрузку процессора ("получить больше взрыва за доллар"). Если сжатие оказывает заметное влияние на производительность или UX, я мигрирую в несжатое WiredTiger.
профилировщик базы данных MongoDB
лучший способ определения потребностей базы данных-настроить тестовый кластер и запустить приложение на нем с помощью MongoDB profiler Как и большинство профилировщиков базы данных, профилировщик MongoDB можно настроить только для записи сведений профиля о запросах, которые заняли больше заданного порога. Поэтому, как только вы узнаете медленные запросы, вы можете выяснить, читает ли он vs writes или cpu vs ram и перейти от там.
вы должны использовать набор реплик, состоящий из как в памяти, так и в WiredTiger системы хранения. И вы должны разбить свой MongoDB таким образом, чтобы наиболее часто посещаемые данные были доступны движку хранения в памяти, а rest использует движок хранения WiredTiger.
после приобретения WiredTiger в 2014 году MongoDB представил этот механизм хранения как свой механизм хранения по умолчанию от версии 3.2. После этого, они сами начали поощрять пользователей использовать WiredTiger из-за его следующих преимуществ перед MMAPV1:
- WiredTiger использует параллелизм уровня документа, тогда как MMAPV1 использует блокировку уровня коллекции. Это означает, что несколько пользователей могут писать в коллекцию одновременно с помощью WiredTiger, но не с помощью MMAPV1.
- поскольку WiredTiger управляет собственной памятью, он может использовать сжатие, тогда как MMPAV1 не имеет такой функции.
- WiredTiger не допускает обновления. Таким образом, в конечном итоге это освобождает пространство, которое больше не используется.
только преимущества MMPAV1 над WiredTiger, которые я нашел до сих пор:
- WiredTiger не доступен на платформе Solaris, в то время как MMPAV1.
- даже при обновлении большого документа только с одним элементом, WiredTiger перезаписывает весь документ, делая его медленнее.
таким образом, вы всегда можете оставить MMPAV1 при выборе двигателя хранения. Теперь перейдем к делу. двигателя хранения в-памяти. Начиная с MongoDB Enterprise версии 3.2.6,двигатель хранения в памяти является частью общей доступности (GA) в 64-разрядных сборках.
Он имеет следующие преимущества перед двигателями хранения:
- подобно WiredTiger, механизм хранения в памяти также позволяет параллелизм уровня документа.
- механизм хранения в памяти намного быстрее, чем другие.
избегая ввода-вывода диска, механизм хранения в памяти обеспечивает более предсказуемую задержку операций с базой данных.
но у этого механизма хранения также есть несколько недостатков:
механизм хранения в памяти не сохраняет данные после завершения процесса.
- если ваш набор данных слишком велик, то in-memory engine не является хорошим вариантом.
in-memory storage engine требует, чтобы все его данные (включая oplog, если mongod является частью набора реплик и т. д.) вписывается в указанную опцию командной строки --inMemorySizeGB или хранилище.памяти.engineConfig.установка inMemorySizeGB.
проверьте руководство MongoDB, например Архитектур Развертывания Через в-памяти системы хранения.