Вопрос по mongodb – В какой степени критика «потерянных данных» остается в силе в отношении MongoDB?

43

В какой степени «потерянные данные» Критика по-прежнему актуальна для MongoDB?Я имею в виду следующее:

1. MongoDB issues writes in unsafe ways by default in order to win benchmarks

If you don't issue getLastError(), MongoDB doesn't wait for any confirmation from the database that the command was processed. This introduces at least two classes of problems:

  • In a concurrent environment (connection pools, etc), you may have a subsequent read fail after a write has "finished"; there is no barrier condition to know at what point the database will recognize a write commitment
  • Any unknown number of save operations can be dropped on the floor due to queueing in various places, things outstanding in the TCP buffer, etc, when your connection drops of the db were to be KILL'd or segfault, hardware crash, you name it

2. MongoDB can lose data in many startling ways

Here is a list of ways we personally experienced records go missing:

  1. They just disappeared sometimes. Cause unknown.
  2. Recovery on corrupt database was not successful, pre transaction log.
  3. Replication between master and slave had gaps in the oplogs, causing slaves to be missing records the master had. Yes, there is no checksum, and yes, the replication status had the slaves current
  4. Replication just stops sometimes, without error. Monitor your replication status!

...[other criticisms]

Если все еще в силе, эта критика будет в некоторой степени беспокоить. Статья в основном ссылается на v1.6 и v1.8, но с тех пор v2 был выпущен. Являются ли недостатки, обсуждаемые в статье, по-прежнему нерешенными в текущем выпуске?

Стоит упомянуть эту статью здесь:MongoDB stale reads torvin
Я немного опоздал на вечеринку, но было бы очень приятно, если бы все, что вы опубликовали на PasteBin, вы вместо этого опубликовали в StackOverflow, так как ваша ссылка, к сожалению, мертва. К счастью, ответы все еще информативны. KSwift87
Я рад, что вы отметили его как дубликат другого вопроса. Я не могу найти вопросы, на которые вы ссылаетесь. deltanovember

Ваш Ответ

4   ответа
25

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

2010

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

Supposedly stable versions of Mongo had major data-losing bugs that weren't made explicit to users. Eg, prior to 1.8 non-clustered configurations were likely to lose data. This was documented by Mongo, but not to the extent a data losing bug in a stable-versioned DB would normally be.

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

Users were informed of this danger, albeit not so explicitly. Users should read all the documentation before they begin.

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

2013

Позже, в 2013 году, вышло исследование, раскрывающееMongoDB defaults can cause significant loss of acknowledged writes во время сетевых разделов.

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

2014

С того времени,in 2014 a completely different bug in the stable MongoDB driver укусил меня и многих других пользователей.

2016

В2016, the Meteor project has issues with MongoDB queries not always returning all matching documents.

Более поздняя политика MongoDBlistening on all interfaces by default with no admin password set также плохо работает для многих пользователей. Два десятилетия назад мы знали (и, возможно, раньше, но в то время я не занимался технологией), что прослушивание на всех портах по умолчанию было плохой идеей, поэтому другие программы избегают этого.

Там была общая, повторная критика, чтоMongo has unsafe defaults - like acknowledging writes that haven't completed - to win performance benchmarks, Монго обычно отвечает, что пользователь должен знать об этом, читая все соответствующие документы, и может использовать выбор, чтобы использовать безопасные опции, если они необходимы.

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

enter image description here

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
11

самый последний анализ Jepsen MongoDB предполагает, чтоdata loss was possible in all versions of MongoDB up to MongoDB 3.2.11 and 3.4.0-rc4.

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

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

Error: User Rate Limit Exceeded
38

шаг за шагом, техническим директором MongoDB и соучредителем Элиотом Горовицем, здесь:

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

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

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

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

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

Update: August 19th 2013

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

Update: March 24th 2017

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
13

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

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

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

Yep MongoDB operates normally in fire and forget mode. But you can modify this bevavior with several options: https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError. So only because MongoDB defaults to it, it doesn't mean you can't change it to your needs. But you need to live less performance if you don't fire and forget within your app, as you're adding a roundtrip.

Update: Since version 2.6, the commands insert, update, save, remove by default acknowledges the write.

Never heard of such problems, except those caused to own failure...but that can happen with relational systems as well. I guess this point only talks about Master-Slave Replication. Replica-Sets are much never and stable. Some links from the web where other dbms caused data loss due to malfunction as well: 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 (Those posted links aren't in any favor of a given system or should imply anything else than showing that there are bugs in other systems as well, who can cause data loss.)

Yes actually there's Locking at instance level, I don't think that in sharded environment this is a global one, I think this will be at instance level for each shard separate, as there's no need to lock other instances as there are no consistency checks needed. The upcoming Version 2.2 will lock at DB Level, tickets for Collection Level and maybe extend or document exists as well (https://jira.mongodb.org/browse/SERVER-4328). But locking at deeper levels may affect the actual performance of MongoDB, as a lock management is expensive.

Moving chunks shouldn't cause much problems as rebalancing should take a few chunks from each node and move them to the new one. It never should cause ping/pong of chunks nor does rebalancing start just because of a difference of one or two chunks. What can be problematic is when your shard key is choosen wrong. So you may end up with all new entries inserted to one node rather than all. So you would see more often rebalancing which can cause problems, but that would be not due to mongo rather than your poorly choosen shardkey.

Can't comment on this one

Not 100% sure, but I think Replicasets where introduced in 1.6, so as told earlier never use the latest version for production, except you can live with loss of data. As with every new feature there's the possibility of bugs. Even extensive testing may not reveal all problems. Again always run some manual backup for gods sake, except you can live with data loss.

Can't comment on this. But in reality software may contain severe bugs. Many games suffer those problems as well and there are other areas as well where banana software was quite well known or is. Can't Comment about something concrete as this was before my MongoDB time.

Replication can cause such problems. Depending on the replication strategy this may be a problem and another system may fit better. But without a really really write intensive workload you may not encounter such problems. Indeed it may be problematic to have 3 replicas polling changes from one master. You could cure the problem by adding more shards.

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

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

Error: User Rate Limit Exceeded

Похожие вопросы