Как выбрать из MMAPV1, WiredTiger или In-Memory StorageEngine для MongoDB?

Ответ 1

Это из личного опыта, однако, пожалуйста, взгляните на эту запись в блоге, в которой объясняются очень разные типы движков: Mongo Blog v3

Сравнение моторов хранения MongoDB WiredTiger и MMAPv1. Высокая производительность и эффективность от 7x до 10x большей производительности записи MongoDB 3.0 обеспечивает более подробный контроль уровня concurrency на уровне документа, обеспечивающий пропускную способность от 7x до 10x для большинства приложений с интенсивной записью, при этом поддерживая предсказуемую низкую задержку.

Для меня выбор был очень простым, мне нужны блокировки уровня документа, которые делают WiredTiger идеальным выбором, у нас нет Enterprise-версии mongo, следовательно, механизм памяти недоступен. MMAPv1 Btree - очень простой способ отображать память на жесткий диск и не очень эффективно.

В хранилище MMAP используется процесс, называемый "распределение записи", для захвата дискового пространства для хранения документов. Все записи смежно расположены на диске, и когда документ становится больше, чем выделенная запись, он должен выделять новую запись. Новые распределения требуют перемещения документа и обновления всех индексов, которые относятся к документу, что занимает больше времени, чем обновления на месте, и приводит к фрагментации памяти. Кроме того, MMAPv1 в своих текущих итерациях обычно приводит к большому использованию пространства в вашей файловой системе из-за чрезмерного распределения пространства записи и отсутствия поддержки сжатия. Как упоминалось ранее, схема блокировки двигателей хранения данных является одним из наиболее важных факторов общей производительности базы данных. MMAPv1 имеет блокировку на уровне коллекции - это означает, что только одна операция вставки, обновления или удаления может использовать коллекцию за раз. Этот тип схемы блокировки создает очень распространенный сценарий в параллельных рабочих нагрузках, где операции обновления/удаления/вставки всегда ждут завершения операции (операций) перед ними. Кроме того, часто эти операции протекают быстрее, чем они могут быть завершены в серийном порядке с помощью механизма хранения. Чтобы выразить это в контексте, представьте себе гигантский супермаркет в воскресенье днем, у которого есть только одна контрольная линия: множество клиентов, но низкая пропускная способность!

У каждого есть разные требования, но в большинстве случаев WiredTiger был бы идеальным выбором, потому что он делает атомарные операции на уровне документа, а не уровне сбора, имеет большое преимущество, вы просто не можете победить.

Больше читает и не много пишет

Если вы читаете, ваша главная проблема здесь - один из способов решения этой проблемы.

Вы можете настроить Mongo Driver Прочитать режимы предпочтений следующим образом:

• Установить набор реплик, скажем 1 мастер и 3 секунды.
• Задайте проблему записи , это сделало бы напишите немного медленнее (компромисс).
• Установите приоритет чтения для вторичного.

Эта настройка будет очень хорошо работать, когда у вас будет много чтений, но поскольку компромиссная запись будет медленнее. Однако пропускная способность прочитанных данных была бы большой.

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

Также вы можете проверить MMAPv1 vs WiredTiger и заметить, как он передумал с MMAPv1 на WiredTiger. Продавец блокирует запись, которую вы просто не можете победить.

Для новых проектов я теперь использую WiredTiger. Поскольку переход из сжатого в несжатое хранилище WiredTiger довольно прост, я, как правило, начинаю с сжатия, чтобы увеличить загрузку процессора ( "получите больше ударов по доллару" ). Если сжатие оказывает заметное влияние на производительность или UX, я переношу на несжатый WiredTiger.

Профайлер базы данных MongoDB

Лучший способ определить ваши потребности в базе данных - настроить тестовый кластер и запустить приложение на нем с помощью профилировщика MongoDB Как и большинство профилировщиков базы данных, профилировщик MongoDB может быть сконфигурирован только для записи информации профиля о запросах, длина которых превышала заданный порог. Поэтому, как только вы знаете медленные запросы, вы можете понять, читает ли он или пишет cpu vs ram и отходит оттуда.

Ответ 2

Вы должны использовать набор реплик, состоящий из модулей хранения в памяти и WiredTiger. И вы должны очернить свой MongoDB таким образом, чтобы доступ к наиболее часто посещаемым данным был в памяти, а система останова использует механизм хранения WiredTiger.

После приобретения WiredTiger в 2014 году MongoDB представила этот механизм хранения как свой механизм хранения по умолчанию из версии 3.2. Впоследствии они сами стали поощрять пользователей использовать WiredTiger из-за своих следующих преимуществ перед MMAPV1:

• WiredTiger использует уровень документа concurrency, тогда как MMAPV1 использует блокировку уровня сбора. Это означает, что несколько пользователей могут записывать коллекцию одновременно с помощью WiredTiger, но не используя MMAPV1.
• Так как WiredTiger управляет собственной памятью, он может использовать сжатие, тогда как MMPAV1 не имеет такой функции.
• WiredTiger не разрешает никаких обновлений на месте. Таким образом, в конечном итоге он восстанавливает пространство, которое больше не используется.

Только преимущества MMPAV1 над WiredTiger, которые я нашел до сих пор:

• WiredTiger недоступен на платформе Solaris, тогда как MMPAV1 есть.
• Даже при обновлении большого документа только с одним элементом WiredTiger переписывает весь документ, делая его медленнее.

Таким образом, вы всегда можете оставить MMPAV1 при выборе механизма хранения. Теперь давайте подходим к моменту хранения памяти. Начиная с версии MongoDB Enterprise 3.2.6, механизм в памяти хранения данных является частью общей доступности (GA) в 64-битных сборках.

Он обладает следующими преимуществами над двигателями хранения:

• Подобно WiredTiger, механизм хранения в памяти также позволяет уровень документа concurrency.
• Механизм хранения в памяти намного быстрее, чем другие.

  Избегая дискового ввода-вывода, механизм хранения в памяти допускает более предсказуемую задержку операций с базой данных.

Но у этого механизма хранения есть и немало недостатков:

• Механизм хранения в памяти не сохраняет данные после завершения процесса.

• Если ваш набор данных слишком велик, тогда механизм с памятью не является хорошим вариантом.

  Механизм хранения в памяти требует, чтобы все его данные (включая oplog, если mongod является частью набора реплик и т.д.), вписываются в заданный параметр командной строки --inMemorySizeGB или параметр storage.inMemory.engineConfig.inMemorySizeGB.

Проверьте руководство MongoDB, например Архитектуры развертывания, используя механизм хранения в памяти.