В какой степени критика "потерянных данных" по-прежнему действительна для MongoDB?

Ответ 1

Этот конкретный пост был развенчан, по пунктам технический директор 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), и мне нравится тот факт, что филната здесь и опровергла это независимо сначала - это, вероятно, говорит больше о продукте, чем что-либо еще:)

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

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

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

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

Ответ 2

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

Главными критиками Монго в первый раз, когда я его использовал (2010), были:

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

Главной защитой этой критики было:

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

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

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

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

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

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

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

Ответ 3

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

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

Итак, давайте поговорим об этих моментах коротко:

• Yep MongoDB работает нормально в режиме огня и забывания. Но вы можете изменить это поведение на несколько вариантов: https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError. Поэтому только потому, что MongoDB по умолчанию не использует его, это не значит, что вы не можете изменить его на свои нужды. Но вам нужно меньше работать, если вы не стреляете и не забываете в своем приложении, поскольку вы добавляете кругооборот.

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

• Никогда не слышал о таких проблемах, кроме тех, которые вызвали собственный провал... но это может случиться и с реляционными системами. Думаю, этот момент говорит только о Master-Slave Replication. Replica-Sets намного никогда и не стабильны. Некоторые ссылки из Интернета, в которых другие dbms также вызвали потерю данных из-за неисправности: 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 (Опубликованные ссылки не в пользу какой-либо системы или должны подразумевать что-то еще, кроме как показывать, что в других системах есть ошибки, которые могут привести к потере данных.)

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

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

• Не могу прокомментировать этот

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

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

• Репликация может вызвать такие проблемы. В зависимости от стратегии репликации это может быть проблемой, и другая система может поместиться лучше. Но без реальной загрузки интенсивной рабочей нагрузки вы не можете столкнуться с такими проблемами. На самом деле может быть проблематично иметь 3 опроса опроса реплик от одного мастера. Вы можете устранить проблему, добавив больше осколков.

Как общий вывод: Да, возможно, эти проблемы существуют, но MongoDB многое сделал в этом направлении, и я сомневаюсь, что в другой СУБД никогда не было той или иной проблемы. Просто возьмите традиционные реляционные dbms, будут ли они хорошо масштабироваться в веб-масштабе, не будет необходимости в таких системах, как MongoDB, HBase и что еще. Вы не можете получить систему, которая бы соответствовала всем потребностям. Таким образом, вам нужно жить с недостатками одного или попытаться построить объединенную систему из нескольких, чтобы получить то, что вам нужно.

Отказ от ответственности: я не связан с MongoDB или 10gen, я просто работаю с MongoDB и рассказываю свое мнение об этом.

Ответ 4

По состоянию на февраль 2017 года последний анализ Jepsen MongoDB предполагает, что потеря данных была возможной во всех версиях MongoDB до MongoDB 3.2.11 и 3.4.0-rc4.

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