Лично я предпочитаю механизм хранения mmapv1 на данный момент по трем причинам.
Причина 1: зрелость
Не то чтобы WiredTiger был незрелым. Но mmapv1 хорошо изучен и проверен в бою все время вверх и вниз, вперед и назад, выше и дальше. У WiredTiger возникли серьезные проблемы ( подробности см. На http://jira.mongodb.com) относительно недавно, и я не хочу, чтобы мои клиенты нашли следующий трудный путь.
Причина 2: Особенности
Учитывая, что WT имеет некоторые принципиально отличные функции. Дело в том, что я не видел, чтобы кто-то извлекал выгоду из них. Сжатие? В любом случае, вы жертвуете довольно трудно, чтобы достичь производительности ради довольно дешевого дискового пространства. Отсутствие проблемы миграции документов для расширения документов? Что ж, у нас все еще есть ограничение в размере 16 МБ и дополнительная сложность для встраиваемых документов, особенно когда встраивание излишне.
Есть и другие функции, но в целом: я не вижу, чтобы от них было много пользы на данный момент .
Причина 3: Общая стоимость владения
Для новых проектов может подойти WT, особенно начиная с версии 3.2, поскольку следующее не применяется.
Выполнение миграции данных стоит дорого, Это должно быть запланировано, план должен быть согласован всеми заинтересованными сторонами, должны быть разработаны и согласованы планы действий в чрезвычайных ситуациях, миграция должна быть подготовлена, выполнена и рассмотрена. Теперь умножьте время, необходимое для заинтересованных сторон, участвующих в этом процессе, и затраты на ускорение миграции данных. Возврат инвестиций с другой стороны кажется довольно небольшим. Вы можете немного масштабировать вместо миграции, если учесть эти факторы. Чтобы создать у вас впечатление: я бы оценил примерно одну «рабочую неделю» на каждого участника, если миграция запланирована, выполнена и проверена должным образом. С затратами в 100 долларов в час на человека и привлечением только трех человек (менеджер, администратор баз данных и разработчик), что составляет 12000 долларов. Обратите внимание, что это консервативная оценка.
Вывод
Все вышеперечисленные факторы привели меня к выводу, что вообще не следует использовать WT. Сейчас.
Обновить
Этому посту уже несколько месяцев, поэтому он заслуживает обновления
По срокам погашения
Мои оригинальные комментарии о сроке погашения являются устаревшими. WiredTiger уже давно не сталкивался с какими-либо серьезными проблемами и стал стандартным механизмом хранения по умолчанию в MongoDB 3.2.
На особенности
Мои оригинальные комментарии все еще имеют смысл, imho.
компрессия
Однако, когда бюджет ограничен или, вообще говоря, производительность не является главной проблемой, компромисс производительности довольно мал, и вы в основном обмениваете небольшое влияние на производительность (по сравнению с несжатым WT) на дисковое пространство, используя то, что в противном случае было бы просто вокруг: процессор.
шифрование
В MongoDB 3.2 Enterprise появилась возможность шифрования хранилищ WiredTiger. Для данных с повышенными требованиями безопасности это убойная функция и делает WT единственным механизмом хранения, как с технической точки зрения (MMAPv1 не поддерживает шифрование), так и концептуально. Конечно, если оставить в стороне возможность зашифрованных разделов диска, хотя в некоторых средах такой возможности может не быть.
Блокировка уровня документа
Я должен признать, что я в основном пропустил эту особенность WT в моем вышеупомянутом анализе, главным образом потому, что он не относился ко мне или моим клиентам, когда я писал оригинальный ответ.
В зависимости от настроек, в основном, когда у вас много одновременно работающих клиентов записи, эта функция может значительно повысить производительность.
По общей стоимости владения
Делать миграции все еще дорого. Однако, принимая во внимание изменения в сроке погашения и изменение представления о функциях, миграция может стоить инвестиций, если:
- Вам нужно шифрование (только Enterprise Edition!)
- Производительность не является вашей главной задачей, и вы можете сэкономить деньги в долгосрочной перспективе (рассчитать консервативно), используя сжатие
- У вас много процессов, пишущих одновременно, так как увеличение производительности может спасти вас от вертикального или горизонтального масштабирования.
Обновленный вывод
Для новых проектов я использую WiredTiger сейчас. Поскольку миграция из сжатого в несжатое хранилище WiredTiger довольно проста, я, как правило, начинаю со сжатия, чтобы повысить загрузку ЦП («получи больше денег»). Если сжатие окажет заметное влияние на производительность или UX, я перейду на несжатый WiredTiger.
Для проектов с большим количеством одновременно работающих авторов ответ на вопрос, стоит ли мигрировать или нет, почти всегда тоже "Да" - если только бюджет проекта не запрещает инвестиции. В долгосрочной перспективе повышение производительности должно окупиться, если развертывание было разумно спланировано. Тем не менее, вам нужно добавить некоторое время разработки для расчета, так как в некоторых случаях необходимо обновить драйвер, и могут возникнуть проблемы, которые необходимо устранить.
Для проектов, которые ограничены в бюджете и не могут позволить себе больше дискового пространства на данный момент, миграция на сжатый WiredTiger может быть вариантом, но сжатие создает небольшую нагрузку на процессор, что неслыханно с MMAPv1. Кроме того, затраты на миграцию могут быть слишком дорогими для такого проекта.
