スケーラブルでないアプリケーションにMongoDBを使用していますか？

Question

私は主にRDBMSデータベースに取り組んできました。最近MongoDBを研究し、スキーマを事前に定義する必要がないところが気に入りました。したがって、アプリケーション開発者はすぐにコードを書き始めることができます。ほとんどの記事に記載されている主な欠点は、MongoDB（またはその他のドキュメントベースのDB）がトランザクション要件に適していないことです。なぜそれが取引に適していないのか疑問に思います。あらゆるWebアプリケーションで私たちが持っているユースケースの助けを借りて理解しようとするだけです

プライマリ、セカンダリ、メールアドレスなどの複数のアドレスを持つユーザープロファイルページがあるユースケースを考えてみましょう。ユーザーは複数の銀行口座を持つことができます。 RDBMSでは、以下のテーブルを作成します

ユーザー（テーブルuser_profile）
アドレス（ユーザーテーブルを指す外部キー）

ユーザーとアドレスは1つのトランザクションで作成されますが、アドレスとユーザーの両方の作成はアトミックにする必要があります。

アカウント（ユーザーテーブルを指す外部キー）

MongoDbを使用すると、アドレスの配列とアカウントの配列を含む単一のUserJSONドキュメントが作成されます。したがって、私の理解では、mongodbはすべてのユーザー関連のものを単一のドキュメントに格納するため、多くの場所で最初にトランザクションを実行する必要はありません。ただし、ユーザー間でトランザクションが発生している場合は、あるアカウントから別のアカウントへのアカウント転送などのトランザクションが必要になります。

そのため、ドキュメントをMongoDBに保存する方法により、トランザクションが必要な場所のほとんどが排除されます。そうですね。はいの場合、おそらく2フェーズコミットを通じて、ドキュメント間でトランザクションを維持できる方法はありますか？

RDBMSでトランザクションを必要とするアプリケーションでも、mongodbまたはその他のドキュメントベースのDBを使用する正当な理由がありますが、MongoDBは、ドキュメント全体でトランザクションが必要な場合を除いて、トランザクション自体の必要性を排除します。ドキュメントベースのDBを使用すると、開発が高速になり、フェッチと更新の呼び出しが改善されます。

理解が正しいかどうか教えてください。

更新：-

私が見るモンゴの他のプラスは：-

結合は必要ないため、パフォーマンスが向上し、クエリの複雑さが軽減されます。
読み取り/書き込みスループットはmongoの方が優れています（ドキュメントストアの支持者から述べただけで自分で試したことはありません）
特定のドキュメントについて追加情報を保存する必要がある場合（たとえば、特定のタイプのドキュメントのコメントフィールドを保存する場合）、すべてのドキュメントに列を追加する必要はありません。
データをjson形式で保存します
接続されたすべての情報が単一のドキュメント自体に格納されるため、上記の例のようなほとんどの場所でのトランザクションの必要性がなくなります。

短所

私が見る最大かつ唯一の欠点は、数は少ないかもしれませんが、ある時点でほとんどのWebアプリケーションが必要とするドキュメント間のトランザクションをサポートすることができません。そのような場合、2フェーズコミットのような手法に頼る必要があります。

また、私は声明に同意しますSo application developers straightaway can start writing the codeは状況に応じて恩恵にあふれることもあれば、悩み事になることもあります。 RDBMSでは、そのようなポリシーを作成し、事前に確認してから、全員がそれに従います。そのポリシーを変更したい場合、それは少し難しいです。 DBのようなMongoでは、ポリシーはありませんが、非公式の契約を決定し、全員がそれに従うことを信頼する必要があります。明らかに、誤用される可能性があるため、決定した契約を確認するために、アプリケーションコードをより頻繁に確認する必要があり、何らかの理由で契約を変更したい場合は、ここに簡単に組み込むことができます。

Philipp · Accepted Answer

はい、あなたの理解は正しいです。

1回の操作で同じドキュメントに複数の変更を実行する場合、それはアトミックプロセスになります。ただし、操作が複数のドキュメントに影響を与える場合、その間のクエリが操作の前に部分的にドキュメントを返し、操作後に部分的にドキュメントを返さないという保証はありません。

MongoDBのネストされたドキュメントは、リレーショナルデータベースの複数のテーブルの複数の行に分散される単一のドキュメントにデータを配置することを推奨します。つまり、このような操作は、リレーショナルデータベースほど一般的ではありません。ただし、それらが発生し、一貫性が重要な場合は、 2フェーズコミットで処理できます。これは本当に醜い回避策ですが、他に方法がない場合でも機能します。

Ewan · Answer

Mongoの唯一の（メイン-編集後）プラスは、「アプリケーション開発者はすぐにコードを書き始めることができる」ということのようです。

しかし、これはテクノロジーではなく、現在の開発慣行が原因である必要があります。これらのテーブルは、mongoDbと同じくらい速くmssqlで作成できます。

RDBMSの作業では、その作業をDBAチームにプッシュして、彼らがそれを行うのを待つ必要があると思いますか？

問題は、強制されたスキーマがなくても、データの保存方法を設計する作業から解放されないことです。実際、後で変更を加えてから、たとえばv1およびv2アドレスについて心配する必要がある場合は、さらに複雑になる可能性があります。

SebTHU · Answer

RDBMSでは、そのようなポリシーを作成し、事前に確認してから、全員がそれに従います。そのポリシーを変更したい場合、それは少し難しいです。 DBのようなMongoでは、ポリシーはありませんが、非公式の契約を決定し、全員がそれに従うことを信頼する必要があります。

この違いの見方は、DBMSが実際に行っていることを誤って伝えていると思います。 DBMSは、フロントエンドプログラマーに（残念ながら必要な）ストレージサービスを提供するだけの愚かなプロバイダーではありません。これは、物事の邪魔になる量に応じて評価できます。

まず、データベースシステムはビジネスルールを実装することもできます。また、ビジネスルールが大量のデータのトラバースに依存している場合は、RDBMSを実装するのに適しています。

RDBMSで実現されたデータベース設計は、特定のデータモデルへのコミットメントの明示的なステートメントとしても機能します。非公式の「契約」は、同じ普遍的な執行力を持つことは決してできません。

RDBMSの代替案に関する誇大宣伝の多くは（スケーラビリティの問題は別として、利点が本物のように見える）、データの保存方法に関する強制されたルールに従うというこの考えに対する不快感から生じていると感じます。しかし、その不快感、および（私の見方では）そこから解放されようとする見当違いの試みは、いくつかの非常に重要な点を見逃しています。

RDBMSは、非常に成熟したエンジニアリング手法です。データベースの構造は静的で変更できないように見える場合がありますが、適切に設計された正規化データベースには、正規化ルールの遵守により、モデルを変更する（またはデータを移行する）機能が組み込まれています。
これに関連して：他のデータベースタイプの支持者は、RDBMSデータベースモデルの設定または変更の難しさを非常に過大評価しているように思われます。提示されているほど難しくはありません。それに固有の問題は、新しいデータとレガシーデータの両方を処理する必要があるストレージシステムに固有です。ここにはNoSQLエスケープルートはありません。
特定のRDB設計によって課せられる制約は、必ずしも恣意的で扱いにくいものではありません。データベースの設計は、実際のビジネス要件のために、そのようにすることができます。または、大量のデータを保存、処理、および要約する最も効率的な方法を提供するためです。

これは、MongoDBが特定の目的のための優れたソリューションではないという意味ではありません。それらの目的が何であるかを明確に理解せず、RDBMSの有用性について非常に歪んだ見方をしているので、それが1つの最良の解決策としてしばしば誇大宣伝されていると思います。