6

過去数日間、Mongo DB に固有のドキュメントを読んだり、スクリーンキャストを見たりしてきましたが、このようなソリューションが典型的な pg または mysql 環境よりも優れているのはいつなのか途方に暮れています。

具体的には、私の質問は、どのような状況（ユースケースがあればいいでしょう）でnosqlルートに行きたいですか？

ありがとう！

4

3 に答える 3

10

  1. 多くの異なる作家。特に、ネットワークの切断によりライターがセグメント化される可能性があり、分岐の両側で書き込まれたデータを後で再同期する必要がある場合。これは ACID を壊します。明示的なビジネス ロジックで問題を解決できますが、NoSQL の領域にいることになります。これは軍事的な状況では非常に一般的ですが、全員が多作のライターであるシステムでは、ACID システムで何らかの書き込み競合ロックが発生します。

  2. 流動的なスキーマ。従来の DB でスキーマを変更することは、多くの場合、ある種のサーバーのダウンタイムやその他の複雑なプロセスを必要とする高価な操作です。ほとんどの NoSQL システムでは簡単です。したがって、多数の異なるソースからデータを取得してマージしたり、後日新しい情報の追跡を開始したい場合は、NoSQL システムの方がはるかに簡単に処理できます。2 つのデータ ソースをマージして相互にグラフ化できるようにすることは、私が考えることができる良い例です。

  3. 低帯域幅のレプリケーション。ACID を解除すると、データベースの完全なレプリカを必要としない部分的なデータを含むネットワーク グラフのリーフ ノードにリーダーとライターを配置できます。我が社の製品、未来の陸軍司令部はこれを使っています。

  4. データの相互運用性。ほとんどの NoSQL データベースでは、事前にスキーマを知らなくてもデータをイントロスペクトできるため、異種システム間の接続が容易になります。

  5. 大規模なスケーリング。これは、最も頻繁に議論され、NoSQL 支持者によって最も頻繁に悪用されるものです。これが NoSQL を選択する唯一の理由である場合は、代わりに MySQL から始めて、後で拡張してください。

于 2010-09-01T19:35:28.227 に答える
8

使用例
大規模で非常に一時的なデータ構造に MongoDB を使用します。実際には、毎秒多くの作業単位が処理されるジョブ トラッカー/マネージャーとして機能します。作業単位にはスキーマが定義されていません (さまざまな単位が頻繁に考案されます) が、DB 全体を反復処理せずに特定のフィールドまたはプロパティを照会する機能が必要です。要約すると、非常に一時的で、高可用性 (クエリのためにブロックする余裕がない) であり、クラウドで実行されている単一の「コモディティ」マシンの作業負荷は約 600QPS です。

実際のところ、同じコストを維持しながら SQL マシンで同じことを行うのは非常に困難です。

MongoDB (私たちにとっても) の他の一般的な使用例は統計収集です。これは、ドキュメント内の特定のプロパティをインクリメントする際に非常に効率的であり、ほとんどの RDBMS システムよりもはるかに効率的です。

繰り返しになりますが、MySQL でこれを行うことが不可能というわけではありません。費用がかかり、時間 (スキル) がかかるため、小さな会社や高速な開発環境では実行できないことを意味します。

于 2010-09-01T19:42:33.417 に答える
7

一部のRESTAPIはJSONデータを返します（たとえば、多くのオープンな政府データAPI）。RESTデータをローカルデータストアにダンプする場合（分析などを実行する必要がある場合）、MongoDBを使用してJSONオブジェクトを取り込むのは簡単です。テーブルスキーマを定義する必要はありません。さらに良いことに、JSONオブジェクトが時間の経過とともに変化する場合（たとえば、REST APIが追加のフィールドを返す場合）、1つのステップでデータを取り込むことができます。リレーショナルデータベースで試してみてください！

于 2010-09-05T07:28:23.483 に答える