В какой степени критика MongoDB в адрес 'потерянных данных' все еще актуальна?

Это конкретное сообщение было развенчано по пунктам техническим директором и соучредителем MongoDB Элиотом Хоровицем здесь:

http://news.ycombinator.com/item?id=3202959

Здесь также есть хорошее резюме:

http://www.betabeat.com/2011/11/10/the-trolls-come-out-for-10gen/

Короткая версия такова: похоже, что это был просто чей-то троллинг с целью привлечь внимание (успешно), без каких-либо серьезных доказательств или подтверждений. В прошлом были реальные инциденты, которые устранялись по мере развития продукта (например, введение журналирования в 1.8) или по мере обнаружения и исправления более специфических ошибок.

Отказ от ответственности: Я работаю в MongoDB (ранее 10gen), и мне нравится тот факт, что philnate пришел сюда и опроверг это первым - это, вероятно, говорит о продукте больше, чем что-либо еще :)

Обновление: 19 августа 2013

Я'видел довольно много активности в этом ответе в последнее время, что, как я предполагаю, связано с объявлением об ошибке в SERVER-10478 - это, безусловно, крайний случай, но я все равно рекомендую всем, кто использует шардинг с большими документами, как можно скорее обновиться до v2.2.6 и v2.4.6, которые включают исправление этой проблемы.

Обновление: 24 марта 2017 года.

Я больше не работаю в MongoDB, но тем не менее поддерживаю этот ответ. Учитывая, что этот ответ продолжает набирать голоса "за" (и "против") и получает много просмотров, я хотел бы указать людям на это сообщение, которое показывает прогресс, достигнутый MongoDB с тех пор, как был задан этот вопрос. База данных теперь проходит тесты Jepsen, и интегрировала тесты в свой процесс сборки, есть много гораздо более зрелых систем, которые не проходят их. Тот, кто все еще бьет в барабан о потере данных в 2017 году, действительно не обращал внимания.

Я не могу говорить за каждый случай, только за свой. Однако я не работаю на Mongo или его конкурентов, и у меня были потери данных при использовании MongoDB, и я использовал Mongo около 6 лет, так что вот.

2010

Именно тогда я впервые начал использовать Mongo, основными критическими замечаниями в адрес Mongo в то время были:

• Предположительно стабильные версии Mongo имели серьезные ошибки с потерей данных, которые не были очевидны для пользователей. Например, до версии 1.8 некластеризованные конфигурации могли терять данные. Это было задокументировано Mongo, но не в той степени, в какой обычно документируется ошибка потери данных в стабильной версии БД.

Основная защита от этой критики заключалась в следующем:

• Пользователи были проинформированы об этой опасности, хотя и не так явно. Пользователи должны прочитать всю документацию, прежде чем начать работу.

В моем собственном случае я использовал 1.7 в конфигурации с одним сервером, но знал о риске. Я отключил БД, чтобы сделать резервную копию. В результате выключения БД мои данные были потеряны, 10gen оказал помощь (бесплатно), но не смог восстановить данные.

2013

Позже, в 2013 году, вышло исследование, которое показало, что Установки MongoDB по умолчанию могут привести к значительной потере подтвержденных записей во время сетевых разделов.

Также в 2013 году Mongo официальные драйверы Mongo для производственных узлов завернули и выбросили все ошибки.

2014

С тех пор в 2014 году совершенно другая ошибка в стабильном драйвере MongoDB укусила меня и многих других пользователей.

2016

В 2016 году у проекта Meteor появились проблемы с тем, что запросы к MongoDB не всегда возвращают все подходящие документы.

Позднее политика MongoDB прослушивание всех интерфейсов по умолчанию без установки пароля администратора также плохо сработала для многих пользователей. Мы знали два десятилетия назад (а возможно, и раньше, но в то время я не занимался техникой), что прослушивание всех портов по умолчанию - плохая идея, поэтому другие программы избегают этого.

Была общая, неоднократная критика, что Mongo имеет небезопасные настройки по умолчанию - например, подтверждение записи, которая не была завершена - для победы в тестах производительности. Mongo обычно отвечает, что пользователь должен знать об этом, читая всю соответствующую документацию, и может использовать безопасные опции, если они необходимы.

В настоящее время я использую RethinkDB в производстве в течение последних 3 лет, но я бы также рассмотрел FoundationDB для будущих структурированных хранилищ данных.

Никогда не слышал о таких серьезных проблемах в последних версиях. Вам нужно учесть, что MongoDB не имеет десятилетней истории развития, как реляционные системы. Кроме того, возможно, MongoDB действительно не предлагает столько функциональности, чтобы избежать потери данных. Но даже в реляционных системах вы не можете быть уверены, что никогда не потеряете данные. Это сильно зависит от конфигурации вашей системы (так что с репликацией и ручным резервным копированием данных вы будете в полной безопасности). В качестве общего правила, чтобы избежать ошибок бета-версии или ошибок ранних версий, избегайте использовать свежие версии в производстве (есть причина, почему debian так популярен для серверов). Если бы MongoDB страдала от таких серьезных проблем (постоянно), список пользователей был бы меньше: https://www.mongodb.com/community/deployments. Кроме того, я не очень доверяю этому сообщению на pastebin, почему оно опубликовано анонимно? Неужели этот человек стесняется сказать, что использует mongodb, неужели он боится 10gen? Где ссылки на эти отчеты о багах (или 10gen удалил их из JIRA?). Итак, давайте вкратце поговорим об этих моментах:

1. Да, MongoDB работает нормально в режиме "запустить и забыть". Но вы можете изменить это поведение с помощью нескольких опций: https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError. Так что только потому, что MongoDB работает по умолчанию, это не значит, что вы не можете изменить его под свои нужды. Но вам придется жить с меньшей производительностью, если вы не будете использовать режим fire and forget в вашем приложении, так как вы добавляете обходной путь.

   Обновление: С версии 2.6, команды insert, update, ave, remove по умолчанию подтверждают запись.

2. Никогда не слышал о таких проблемах, кроме тех, которые вызваны собственным сбоем... но это может произойти и с реляционными системами. Я полагаю, что этот пункт относится только к репликации Master-Slave. Наборы реплик гораздо более надежны и стабильны. Некоторые ссылки из Интернета, где другие СУБД также приводили к потере данных из-за сбоев: http://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-running-oracle-on.html http://dbaspot.com/oracle-server/430465-parallel-cause-data-lost-another-oracle-bug.html http://bugs.mysql.com/bug.php?id=18014. (Эти ссылки не в пользу той или иной системы и не должны означать ничего другого, кроме того, что они показывают, что и в других системах есть ошибки, которые могут привести к потере данных).

3. Да, действительно есть блокировка на уровне экземпляра, я не думаю, что в шардированной среде это глобально, я думаю, что это будет на уровне экземпляра для каждого шарда отдельно, так как нет необходимости блокировать другие экземпляры, поскольку нет необходимости в проверке согласованности. В предстоящей версии 2.2 блокировка будет осуществляться на уровне БД, билетов для уровня коллекции и, возможно, расширения или существования документа (https://jira.mongodb.org/browse/SERVER-4328). Но блокировка на более глубоких уровнях может повлиять на реальную производительность MongoDB, так как управление блокировкой является дорогостоящим.

4. Перемещение чанков не должно вызывать больших проблем, так как ребалансировка должна взять несколько чанков с каждого узла и переместить их на новый узел. Это никогда не должно вызывать пинг/понг чанков и ребалансировка не начинается только из-за разницы в один или два чанка. Проблема может возникнуть, если ключ шарда выбран неправильно. В результате все новые записи могут быть вставлены в один узел, а не во все. Таким образом, вы будете чаще наблюдать ребалансировку, которая может вызвать проблемы, но это будет связано не с mongo, а с неправильно выбранным ключом шарда.

5. Не могу прокомментировать

6. Не уверен на 100%, но думаю, что Replicasets появились в 1.6, поэтому, как уже говорилось ранее, никогда не используйте последнюю версию для производства, если только вы не можете смириться с потерей данных. Как и с каждой новой функцией, есть вероятность ошибок. Даже обширное тестирование может не выявить всех проблем. Опять же, ради бога, всегда выполняйте резервное копирование вручную, если только вы не можете смириться с потерей данных.

7. Не могу комментировать это. Но в действительности программное обеспечение может содержать серьезные ошибки. Многие игры также страдают от этих проблем, и есть и другие области, где банальное программное обеспечение было или есть достаточно известным. Не могу прокомментировать что-то конкретное, так как это было до моего времени работы с MongoDB.

8. Репликация может вызвать такие проблемы. В зависимости от стратегии репликации это может быть проблемой, и другая система может подойти лучше. Но без действительно очень интенсивной нагрузки на запись вы можете не столкнуться с такими проблемами. Действительно, может быть проблематично иметь 3 реплики, опрашивающие изменения с одного мастера. Вы можете решить эту проблему, добавив больше шардов. В качестве общего вывода: Да, возможно, эти проблемы существовали, но MongoDB сделала многое в этом направлении, и далее я сомневаюсь, что другие СУБД никогда не имели тех или иных проблем. Просто возьмите традиционные реляционные СУБД, если бы они хорошо масштабировались до веб-масштаба, то не было бы необходимости в таких системах, как MongoDB, HBase и прочих. Вы не можете получить систему, которая подходит для всех потребностей. Поэтому вам придется жить с недостатками одной из них или попытаться построить комбинированную систему из нескольких, чтобы получить то, что вам нужно. Отказ от ответственности: Я'не связан с MongoDB или 10gen, я'просто работаю с MongoDB и рассказываю свое мнение о ней.

По состоянию на февраль 2017, Последняя Джепсен анализ в MongoDB свидетельствует о том, что потеря данных во всех версиях СУБД MongoDB вверх в MongoDB 3.2.11 и 3.4.0-RC4 и выше.

Поэтому на тот момент вопрос был написан (2012) ответ должен'вэ были да, такая критика действует с теоретической точки зрения. Но, похоже, клиенты Дон'т волнует теория. Как не RethinkDB показано, правильность не'т вопрос. Единственное, что важно то время выхода на рынок. Очень грустно.

По состоянию на октябрь 2018, в MongoDB 3.4 - это еще вопрос.