69

「失われたデータ」に対する批判は、MongoDBに対してどの程度有効ですか？私は以下を参照しています：

1. MongoDBは、ベンチマークを勝ち取るために、デフォルトで安全でない方法で書き込みを発行します

getLastError（）を発行しない場合、MongoDBは、コマンドが処理されたというデータベースからの確認を待ちません。これにより、少なくとも2つのクラスの問題が発生します。

  • 並行環境（接続プールなど）では、書き込みが「終了」した後、後続の読み取りが失敗する場合があります。データベースが書き込みコミットメントを認識する時点を知るための障壁条件はありません
  • さまざまな場所でのキューイング、TCPバッファーで未処理のものなどが原因で、不明な数の保存操作がフロアにドロップされる可能性があります。データベースの接続ドロップが強制終了またはセグメンテーション違反、ハードウェアクラッシュが発生した場合、名前を付けます。

2. MongoDBは、多くの驚くべき方法でデータを失う可能性があります

これが私たちが個人的に経験した記録が失われる方法のリストです：

  1. 彼らは時々姿を消した。原因不明。
  2. 破損したデータベースのリカバリは成功しませんでした。トランザクションログの前。
  3. マスターとスレーブ間のレプリケーションでは、oplogにギャップがあり、マスターが持っていたレコードがスレーブに失われていました。はい、チェックサムはありません。はい、レプリケーションステータスのスレーブは最新です。
  4. レプリケーションがエラーなしで停止することがあります。レプリケーションステータスを監視してください！

...[その他の批判]

それでも有効であれば、これらの批判はある程度心配になるでしょう。この記事は主にv1.6とv1.8を参照していますが、それ以降、v2がリリースされています。記事で説明されている欠点は、現在のリリースの時点でまだ未解決ですか？

4

4 に答える 4

58

コンテキストに関する注意:

この質問は 2012 年に行われましたが、現在でもトラフィックと投票が見られます。元の回答は、質問の時点で人気があった特定の投稿に反論することでした。この回答が書かれて以来、物事は大幅に変化しました（そして変化し続けています）。MongoDB は、基本的なジャーナリングなどの機能が比較的新しい 2012 年に比べて、確実に耐久性と信頼性が大幅に向上しています。私はこの回答に対して反対票とコメントを受け取ります。これは、「失われたデータの批判はまだ有効ですか?」というタイトルの質問 (詳細ではない) に対する現在の (現在の特定の値に対する) 一般的な回答に対処していないと人々が感じているためです。以下の更新で明確にしようとしましたが、基本的にこの質問に対する完全な答えはありません。

元の回答:

その特定の投稿は、MongoDB の CTO で共同創設者の Eliot Horowitz によって一点一点暴かれました。

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 がここに来て、これを最初に独自に反論したという事実が気に入っています。

更新: 2013 年 8 月 19 日

最近、この回答でかなりの活動を見てきました。これは、SERVER-10478のバグの発表に関連していると思われます。これは間違いなくエッジ ケースですが、大きなドキュメントでシャーディングを使用している人には、この問題の修正を含む v2.2.6 および v2.4.6 にできるだけ早くアップグレードしてください。

更新: 2017 年 3 月 24 日

私はもう MongoDB で働いていませんが、それでもこの回答を支持しています。この回答が引き続き賛成票 (および反対票) を獲得し、多くのビューを受け取っていることを考えると、この質問が提起されてからの MongoDB の進歩を示すこの投稿を人々に指摘したいと思います。データベースはJepsenテストに合格し、そのテストをビルド プロセスに統合しました。合格しないはるかに成熟したシステムがたくさんあります。2017 年になってもまだデータ損失のドラムを打ち続けている人は、まったく注意を払っていません。

更新: 2020 年 5 月 24 日

Jepsen はMongoDB 4.2.6 を再分析しました。MongoDB が「完全な ACID トランザクション」を提供するようになったためです。部分的にかなり技術的になりますが、MongoDB でのデータ損失が懸念される場合は、この記事を読むことを強くお勧めします (チェックアウトすることをお勧めします)。 Jepsen がテストするデータベースを使用すると、その弱点に驚くかもしれません)。このレポートでは、デフォルトの読み取りと書き込みの懸念事項の弱点を要約し、適切な読み取りと書き込みの懸念事項を使用した非トランザクションの読み取りと書き込みの信頼性について説明し、ドキュメントの欠陥に対処し、新しいACID トランザクション (および関連する読み取り/書き込みの問題)。

では、MongoDB でもデータを失う可能性はありますか? はい、特にデフォルト設定ではそうですが、それはほとんどのデータベースに当てはまります。この質問に回答したときよりも状況は大幅に改善されており、信頼性と耐久性を向上させる機能があり、機能しているように見えます (トランザクションは別として)。私のアドバイスは、運用している構成の制限が何であるかを学び、データ損失のリスクが製品/ビジネス/ユース ケースで許容できるかどうかを判断することです。

于 2012-05-14T11:33:53.913 に答える
50

私はすべてのケースについて話すことはできません。私自身のケースだけです。ただし、他の回答とは異なり、私は Mongo またはその競合他社のために働いていません。MongoDB を使用するとデータが失われ、Mongo を約 10 年間使用したので、ここに行きます。

2010年

これは、私が最初に Mongo を使い始めたときで、当時の Mongo に対する主な批判は次のとおりでした。

  • おそらく安定したバージョンの Mongo には、ユーザーに明示されていない主要なデータ損失バグがありました。たとえば、1.8 より前の非クラスタ構成では、データが失われる可能性がありました。これは Mongo によって文書化されましたが、安定したバージョンの DB でのデータ損失のバグが通常発生する程度ではありません。

その批判の主な防御は次のとおりです。

  • 明示的ではありませんが、ユーザーにはこの危険性が通知されました。ユーザーは、開始する前にすべてのドキュメントを読む必要があります。

私の場合、単一サーバー構成で 1.7 を使用していましたが、リスクを認識していました。バックアップを取るためにDBをシャットダウンしました。DB自体をシャットダウンする行為は私のデータを失いました.10genは（無料で）支援しましたが、データを回復することはできませんでした.

2013年

その後、2013 年に調査が発表され、 MongoDB のデフォルトがネットワーク パーティション中に確認済みの書き込みを大幅に損失する可能性があることが明らかになりました。

また、2013 Mongo では、公式の本番ノード Mongo ドライバーがラップされ、すべてのエラーが破棄されました。

2014年

それ以来、2014 年に、安定版の MongoDB ドライバーにまったく別のバグが発生し、私と他の多くのユーザーを悩ませました。

2016年（そして2020年も）

2016年の Meteor プロジェクトでは、MongoDB クエリが常に一致するすべてのドキュメントを返すとは限らないという問題がありました。

その後、管理者パスワードを設定せずにデフォルトですべてのインターフェースをリッスンするという MongoDB のポリシーも、多くのユーザーにとってうまくいきませんでした。デフォルトですべてのポートをリッスンするのは悪い考えであるということは 20 年前 (そしておそらくそれより前のことですが、私は当時技術者ではありませんでした) に知っていました。そのため、他のソフトウェアはこれを避けています。

2020 更新: Meow 攻撃は、Mongo の古いネットワーク デフォルトでデータベースを自動的に破壊するようになりました。

2020年

Jepsen は MongoDB 4.2.6を評価し、次のように結論付けました。

読み取りと書き込みの懸念が最も強いレベルであっても、MongoDB 4.2.6 はスナップショットの分離を維持できませんでした。代わりに、Jepsen は読み取りスキュー、周期的な情報フロー、重複書き込み、および内部整合性違反を観察しました。脆弱なデフォルトは、トランザクションが書き込みを失い、ダーティ リードを許可する可能性があることを意味し、データベースおよびコレクション レベルで要求された安全性レベルを下げることさえありました。

結論

長年にわたり、Mongo がパフォーマンス ベンチマークを獲得するために安全でないデフォルトを使用しているという一般的な観察が繰り返し行われてきました。Mongo は一般的に、関連するすべてのドキュメントを読んでユーザーがこれらのことを認識する必要があり、必要に応じて安全なオプションを使用することを選択できると回答しています。

2020 年の時点で、時間と投資のおかげで MongoDB は実際にはより安定した製品になっているように感じますが、当社のデータを 10 年間ベータ テストに使用した会社を信頼することは決してありません。状態が明らかになりました。私は Postgres JSONB、FoundationDB、および RethinkDB を構造化データ ストアとして使用しましたが、これらは有効な代替手段となる可能性があります。

ここに画像の説明を入力

于 2013-08-16T09:19:33.267 に答える
12

最近のバージョンでこれらの重大な問題が発生したことは聞いたことがありません。考慮すべきことは、MongoDB にはリレーショナル システムとして 10 年間の開発が行われていないということです。さらに、MongoDB がデータ損失をまったく回避するための機能をあまり提供していないことも事実かもしれません。しかし、リレーショナル システムであっても、データがまったく失われないという確信は持てません。システム構成に大きく依存します (したがって、レプリケーションと手動データ バックアップを使用すると、非常に安全なはずです)。

ベータ版のバグや初期バージョンのバグを回避するための一般的なガイドラインとして、本番環境で新しいバージョンを使用しないようにしてください (サーバーで debian が非常に人気があるのには理由があります)。MongoDB がこのような深刻な問題に (常に) 苦しむ場合、ユーザーのリストはより少なくなります: https://www.mongodb.com/community/deployments さらに、私はこのペーストビン メッセージをあまり信用していません。なぜこれが匿名で公開されているのですか? この会社は mongodb を使用したことを恥ずかしく思いますか? 彼らは 10gen を恐れていますか? これらのバグ レポートへのリンクはどこにありますか (または 10gen はそれらを JIRA から削除しましたか?)

それでは、これらの点について簡単に説明しましょう。

  1. はい、MongoDB はファイア アンド フォーゲット モードで正常に動作します。ただし、いくつかのオプションを使用してこの動作を変更できます: https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError。したがって、MongoDB がデフォルトで設定されているからといって、必要に応じて変更できないわけではありません。ただし、往復を追加しているため、アプリ内で起動して忘れない場合は、パフォーマンスを低下させる必要があります。

    更新:バージョン 2.6 以降、コマンドinsert、update、saveはremoveデフォルトで書き込みを確認します。

  2. このような問題は聞いたことがありませんが、自分自身の障害が原因の場合を除きます...しかし、それはリレーショナル システムでも発生する可能性があります。この点は、マスター/スレーブ レプリケーションについてのみ述べていると思います。Replica-Set は決して安定したものではありません。他の dbms も誤動作によるデータ損失を引き起こした Web からのリンク: 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 は、DB レベル、コレクション レベルのチケットでロックされ、拡張またはドキュメントも存在する可能性があります ( https://jira.mongodb.org/browse/SERVER-4328 )。ただし、ロック管理にはコストがかかるため、より深いレベルでのロックは MongoDB の実際のパフォーマンスに影響を与える可能性があります。

  4. リバランスは各ノードからいくつかのチャンクを取得し、それらを新しいノードに移動する必要があるため、チャンクを移動しても大きな問題は発生しません。チャンクの ping/pong が発生したり、1 つまたは 2 つのチャンクの違いが原因でリバランスが開始されたりすることはありません。問題になる可能性があるのは、シャード キーの選択が間違っている場合です。そのため、すべてではなく 1 つのノードにすべての新しいエントリが挿入される可能性があります。そのため、問題を引き起こす可能性のあるリバランスがより頻繁に見られますが、それは選択が不十分なシャードキーではなく、mongo によるものではありません。

  5. これについてはコメントできません

  6. 100%確かではありませんが、レプリカセットは 1.6 で導入されたと思います。そのため、前に述べたように、データが失われる可能性がある場合を除いて、本番用に最新バージョンを使用しないでください。すべての新機能と同様に、バグの可能性があります。大規模なテストを行っても、すべての問題が明らかになるわけではありません。繰り返しになりますが、データの損失に耐えることができる場合を除いて、神のために常に手動バックアップを実行してください。

  7. これについてはコメントできません。しかし実際には、ソフトウェアには重大なバグが含まれている場合があります。多くのゲームも同様の問題を抱えており、バナナ ソフトウェアがよく知られている、または知られている分野は他にもあります。これは私のMongoDBの時間の前だったので、具体的なことについてコメントすることはできません.

  8. レプリケーションは、このような問題を引き起こす可能性があります。レプリケーション戦略によっては、これが問題になる可能性があり、別のシステムが適している場合があります。しかし、実際に書き込みが集中する作業負荷がなければ、このような問題に遭遇することはありません。実際、3 つのレプリカが 1 つのマスターからの変更をポーリングすることは問題になる場合があります。シャードを追加することで問題を解決できます。

一般的な結論として: ええ、これらの問題が存在していた可能性がありますが、MongoDB はこの方向に多くのことを行いました。さらに、他の DBMS 自体に何らかの問題があったことはないと思います。従来のリレーショナル dbms を例にとると、Web スケールにうまくスケーリングできれば、MongoDB、HBase などのシステムは必要ありません。すべてのニーズを満たすシステムを手に入れることはできません。したがって、必要なものを得るには、1 つの欠点を受け入れるか、複数のシステムを組み合わせて構築する必要があります。

免責事項: 私は MongoDB や 10gen とは関係ありません。MongoDB を扱っており、それについての意見を述べているだけです。

于 2012-05-12T20:12:19.243 に答える