NoSQLの状況でのデータの整合性

Question

背景

はじめに、職場では、当時は非常に壮観であったレガシーシステムを使用していますが、今は...興味深い... IBM（現在はRocket）UniVerseをバッキングデータベースとして使用しています。いくつかの問題を引き起こしているその特定の部分は、データ整合性チェックの欠如です。データの整合性とは、ファイルの破損を意味するのではなく、孤立したレコードや無効なキーなどを指します。彼らが使用する特定のバージョンは、トリガーなどをサポートしていないため、プログラマーが計算されたインデックスを更新することを忘れない限り、「壊れて」しまい、不良データでいっぱいになります。現在、他のプログラムはこの不良データを処理するように構築されていますが、実際にデータに制約があるMySQL（InnoDBをエンジンとして使用）などの別のデータベースにそれを置くと、最も煩わしくなります。

質問

MongoDBとNodeJSを実験して、誇大宣伝の内容を確認しています。 Mongooseとそのスキーマシステムも大好きです。私は、各レコードと個別のコレクションに何を格納するかについて多くを読んでいます。多分それは私自身のRDBMSバイアスだけかもしれませんが、物事の各「タイプ」を別々のコレクションに格納し、Mongooseの「移入」機能を利用して基本的にレコードを相互に関連付けることにしました。今、誰かがそれがNoSQLの全体に反することだと言うだろうと確信していますが、何かがレコードの代わりにドキュメントを格納し、それがデータベースレベルに設定されたスキーマを持っていないためと言っているところは本当に読んでいませんリレーショナルにすることはできません。

私の実験では、「投稿」と「コメント」があります。これら2つの関係を保存する方法は4つあります。

各コメントの完全なデータは、サブドキュメントとして投稿に直接配置されます。これに関して私が見た主な短所は2つあります。何か他のもの（「ページ」と言いましょう）にもコメントを付けることにした場合、基本的に自分自身を繰り返す必要があり、その方法を見つけるのはそれほど簡単ではありません。コメントが実際に複数のコレクションに保存されている場合、ユーザーが投稿した多くのコメント
コメントは別個のコレクションで、親のキーと、入力時に使用するmongooseのスキーマ名が格納されます（スキーマ名の切り替えは自動的には行われません）。これはそれほど悪くはありませんが、最初にコメントをロードし、後でポストするという偏りがあります。投稿のコメントを見つけるのは難しくありませんが、手動でのクエリが必要です。
コメントは別のコレクションであり、投稿にはそれらに関連するコメントIDのリストがあります。これは最初に投稿をロードする方向に偏っており、コメントが何に添付されているかを見つけるのは難しくなります。ただし、mongooseを使用すると、コメントを追加することなくコメントを読み込むことができます。
コメントは別のコレクションであり、親IDがあります。投稿にはコメントIDのリストもあります。これは上記の2つの方法を組み合わせ、それらの短所を無効にし、比較的少ない「手動」クエリを作成しますが、上記のレガシーシステムのようにデータがダーティになり、同期しなくなる可能性があります（たとえば、コメントは1つの投稿に属しているとコメントしています）別の投稿（または複数の投稿）がそのコメントを所有していると主張しています）。

上記の後者のパスをたどっていたところ、手動で更新されたインデックスと多くの悪いデータの可能性で非常に多くの問題を引き起こしていたこのレガシーシステムの領域に入り始めていることに気付きました。

さて、私はこの小さな実験で大したことをするつもりはありませんが、それが私が考えさせていることの原則です。これに何をすることをお勧めしますか？クエリ数を低く抑えたいのですが、これらすべてのインデックスを更新することを覚えておく必要もありません。どこかに幸せな媒体がなければならない。

もちろん、もう1つのオプションは、MySQLをいくつかのNiceスキーマ制約とともに使用することですが、私はすでに何トンもそのことを行っているので、これは私にとってこの特定の演習のポイントではありません。

bodokaiser · Accepted Answer

noSQLでのnode.jsの使用に関する私の経験は、Mongooseをスキップして node-mongodb-nativeドライバーを使用する結果となりました。

これは、Mongooseが実際にはnode.jsの方法と競合するためです。つまり、さまざまなツールを組み合わせて、独自のニーズフレームワークを構築する必要があります。 Mongooseは、従来の環境から来た人には見栄えがしますが、複雑になるだけの制限があることに気づくでしょう。ネイティブドライバーを使用して、必要に応じて特定のコレクションのカスタマーヘルパーマネージャーを作成します。

Originの質問については、最初のコンセプトを採用し、すべてを1つのドキュメントにまとめることをお勧めします。リソースを浪費していると感じると、最初はばかげているように聞こえることは知っています。これは、MySQLのデータモデリングテーブル構造から学んだことです。ドキュメント指向のDBでは、このすべてが必要というわけではありません。彼らのアイデアは、物事を可能な限りシンプルにして、受け取ったドキュメントを保存することです。他のすべてのものは時間の無駄です。 Mongooseの生成をサポートするREST APIを構築しようとしただけでどれだけの時間を無駄にしたかを振り返ると...

結論として、ドキュメント指向のデータベースは、シリアライズされたオブジェクトの永続性と考えることをお勧めします。複雑なクエリを計画しないか、データを無駄にしないためにデータを1度だけ保持することを計画している限り、 MySQLを再構築しようとする時間。

お役に立てば幸いです。