Особисто я віддаю перевагу двигуну зберігання даних mmapv1 з трьох причин.
Причина 1: Зрілість
Справа не в тому, що WiredTiger незрілий. Але mmapv1 добре розуміється, і бій випробовується на всіх напрямках вгору і вниз, назад і вперед, і вище, і за його межами. У WiredTiger виникли серйозні проблеми (детальніше див. Http://jira.mongodb.com ) порівняно недавно, і я не бажаю, щоб мої клієнти знаходили наступний важкий шлях.
Причина 2: Особливості
З огляду на те, що WT має деякі найважливіші особливості. Річ у тім: я не бачив, щоб хтось з них виграв. Стиснення? Так чи інакше, ви жертвуєте досить важко для досягнення продуктивності за досить дешевий простір на диску. Відсутність проблеми міграції документів для розширення документів? Що ж, у нас все ще є обмеження розміру 16 Мб та додаткова складність для вбудованих документів, особливо коли вбудовування перестарається.
Є й інші особливості, але в цілому: я не бачу, що їм зараз користі .
Причина 3: Загальна вартість власності
Щодо нових проектів, то WT може бути добре, особливо з 3.2, оскільки наступне не застосовується.
Робити міграцію даних досить дорого. Це потрібно спланувати, план повинен бути узгоджений усіма зацікавленими сторонами, створювати та узгоджувати плани надзвичайних ситуацій, міграцію потрібно підготувати, виконати та переглянути. Тепер помножте час, необхідний для зацікавлених сторін, які є частиною цього процесу, та витрати на скорочення міграції даних. З іншого боку, рентабельність інвестицій здається невеликою. Ви можете досить масштабувати замість того, щоб робити міграцію, якщо врахувати ці фактори. Щоб скласти враження: я б оцінив приблизно один "людина-тиждень" на кожного зацікавленого учасника, якщо міграція запланована, виконана та переглянута належним чином. З витратами в 100 доларів на годину на людину та залученими лише троє людей (менеджер, DBA та розробник), це становить 12 000 доларів. Зауважте, що це консервативна оцінка.
Висновок
Усі ці фактори, що були зазначені вище, привели мене до висновку, що не використовувати WT взагалі. На даний момент.
Оновлення
Цій публікації вже кілька місяців, тому вона заслуговує на оновлення
На зрілість
Мої оригінальні коментарі щодо зрілості - це щось застаріле. У WiredTiger деякий час не виникало серйозних проблем, і він став двигуном зберігання за замовчуванням, починаючи з MongoDB 3.2
Про функції
Мої оригінальні коментарі все ще мають деяку обґрунтованість, імхо.
Стиснення
Однак, якщо обмеження в бюджеті або, взагалі кажучи, продуктивність не є першочерговою проблемою, компроміс продуктивності досить малий, і ви в основному торгуєте невеликими впливами на продуктивність (у порівнянні з нестисненими WT) для дискового простору, використовуючи те, що в іншому випадку буде простоювати навколо: ЦП.
Шифрування
MongoDB 3.2 Enterprise представила можливість шифрувати сховища WiredTiger. Для даних з підвищеними потребами в безпеці це є вбивчою функцією і робить WT єдиним механізмом зберігання даних, як технічно (MMAPv1 не підтримує шифрування), так і концептуально. Звичайно, відзначаючи можливість зашифрованих розділів дисків, звичайно, хоча у деяких середовищах ця опція може не бути.
Блокування рівня документа
Я маю визнати, що я в основному опустив цю особливість WT у своєму вище аналізі, головним чином тому, що він не застосовувався ні до мене, ні до моїх клієнтів, коли я писав оригінальну відповідь.
Залежно від налаштувань, в основному, коли у вас багато клієнтів, які одночасно пишуть, ця функція може забезпечити значне підвищення продуктивності.
Про загальну вартість власності
Робити міграцію все ще дорого. Однак, беручи до уваги зміни зрілості та змінене уявлення про особливості, міграція може коштувати інвестицій, якщо:
- Вам потрібно шифрування (лише для Enterprise Edition!)
- Продуктивність не є вашою першочерговою проблемою, і ви можете заощадити гроші в довгостроковій перспективі (розрахувати консервативно) за допомогою стиснення
- У вас багато процесів написання одночасно, оскільки збільшення продуктивності може заощадити вертикальне або горизонтальне масштабування.
Оновлений Висновок
Для нових проектів я зараз використовую WiredTiger. Оскільки міграція зі стисненого на нестиснене сховище WiredTiger досить проста, я, як правило, починаю зі стиснення, щоб підвищити використання процесора ("отримати більше грошей на долар"). Якщо стиснення помітно вплине на продуктивність або UX, я переходжу на нестиснений WiredTiger.
Для проектів з великою кількістю одночасних авторів відповідь на те, щоб перейти чи ні, майже завжди також є "Так" - якщо тільки бюджет проекту не забороняє інвестувати. Зрештою, підвищення продуктивності повинно окупитися, якщо розгортання було інакше розумно заплановано. Однак вам потрібно додати деякий час розробки до розрахунку, оскільки в деяких випадках драйвер потребує оновлення, і можуть виникнути проблеми, з якими потрібно вирішити.
Для проектів, які обмежують бюджет і не можуть дозволити собі більше дискового простору на даний момент, перехід на стислий WiredTiger може бути варіантом, але стиснення придає трохи навантаження на процесор, що є нечуваним для MMAPv1. Крім того, міграційні витрати можуть бути надзвичайно дорогими для такого проекту.
