モデルのNoSQLデータベース（SQLデータベースからの変換）

Question

に私は私が（現在、私はRavenDBを使用しています）のNoSQL 1に変換するSQLデータベースを持っている

は私のテーブルは以下のとおりです。

トレース：

ID (PK, bigint, not null) 
DeploymentID (FK, int, not null) 
AppCode (int, not null) 

展開：

DeploymentID (PK, int, not null) 
DeploymentVersion (varchar(10), not null) 
DeploymentName (nvarchar(max), not null) 

アプリケーション：

AppID (PK, int, not null) 
AppName (nvarchar(max), not null) 

現在、私は私のテーブルにこれらの行を持っている：

トレース：

ID: 1 , DeploymentID: 1, AppCode: 1 
ID: 2 , DeploymentID: 1, AppCode: 2 
ID: 3 , DeploymentID: 1, AppCode: 3 
ID: 3 , DeploymentID: 2, AppCode: 1 

展開：

DeploymentID: 1 , DeploymentVersion: 1.0, DeploymentName: "Test1" 
DeploymentID: 2 , DeploymentVersion: 1.0, DeploymentName: "Test2" 

アプリケーション：

AppID: 1 , AppName: "Test1" 
AppID: 2 , AppName: "Test2" 
AppID: 3 , AppName: "Test3" 

私のNoSQLドキュメントモデルはどうすれば作成できますか？展開の1が変更されます場合

trace/1 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test1" 
} 

trace/2 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test2" 
} 

trace/3 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test3" 
} 

trace/4  
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test2" } ], 
"Application": "Test1" 
} 

そして、何：

は、それは次のようになりますか？それぞれの文書を読み、データを変更する必要がありますか？

NoSQLでリファレンスを使用する必要があるのはいつですか？

Answer 1

ドキュメントをモデル化する方法は、主にアプリケーションとそのドメインによって異なります。そこから、データ・アクセス・パターンを理解することによって、文書モデルを洗練させることができます。

ブラインドでは、リレーショナルデータモデルを非リレーショナルモデルにマップするのは良い考えではありません。

更新：マットは私のここでの主な考えを得たと思う。私が言っていることは、（正規化されたSQLスキーマのような）リレーショナル・データ・モデルを（ドキュメント・モデルのような）非リレーショナル・データ・モデルに変換することは、アプリケーションのドメインを考慮します。ここでちょっと詳しく説明してください...

SQLスキーマを見てから、アプリケーションとデプロイメントに参加するように見える表のほかにトレースが何もわかりません。私はまた、あなたのアプリケーションがデータをどのように照会するのか全く知らない。アプリケーションオブジェクト（またはドメインオブジェクト）をモデル化する方法に違いがあるように、ドキュメントをモデル化するときには、これについて少し気づくだけで違いがあります。

ご質問の中で提案されているドキュメントモデルが、あなたのアプリケーションでうまく動作しない場合があります。

Answer 2

Ravenなどのドキュメントデータベースは、リレーショナルデータベースではありません。最初にデータベースモデルを構築し、後でそれを照会する様々な興味深い方法を決定することはできません。代わりに、まずサポートするアクセスパターンを決定し、それに応じてドキュメントスキーマを設計する必要があります。

質問に答えるために、私たちが本当に知る必要があるのは、データの使い方です。たとえば、すべてのトレースを時間順に表示するのは、特定のデプロイメントまたはアプリケーションに関連付けられたトレースを表示する場合とはまったく異なります。これらの要件のそれぞれは、両方をサポートするように、異なる設計を指示する。

これはそれ自体が役に立つ情報（？）ですが、もっと具体的な回答が必要だと思われます:)

戦略を決定する際に「やる」と「いけないこと」いくつかあります。

はDO：一般的なユースケースの最適化が。 UXの20％が負荷の80％を占める20/80の内訳があります.Webアプリケーションのホームページ/ランディングページは古典的な例です。最優先事項は、これらができるだけ効率的であることを確認することです。あなたのデータモデルが、A）単一のIOリクエストでそれらをロードするか、またはB）キャッシュフレンドリーであるかを確認してください。

DONT：恐ろしい "N + 1"トラップに入り込まないでください。このパターンは、N個のエンティティをロードするためにN個の呼び出しを行うようにデータモデルを強制したときに発生します。多くの場合、N個のIDのリストを取得するための追加呼び出しが先行します。これはキラーです、特に＃3と一緒に...

DO：（UX経由で）フェッチしたいデータの量を常に制限してください。ユーザーが3729個のコメントを持っている場合は、一度にすべてをフェッチしないことは明らかです。たとえそれがデータベースの観点から実現可能であったとしても、ユーザーエクスペリエンスは恐ろしいものでした。なぜ検索エンジンが「次の20の結果」パラダイムを使用するのか。したがって、（例えば）データベース構造をUXに合わせて、20のブロックでコメントを保存することができます。次に、各ページのリフレッシュには、単一のDB getが含まれます。

DO：読み取りと書き込みの要件のバランスをとります。いくつかのタイプのシステムは、読み取りが重く、書き込みごとに多くの読み取りが行われると想定することができます（StackOverflowが良い例です）。そこで、読取りパフォーマンスの利点を得るために書込みをより高価にすることは理にかなっています。例えば、データの非正規化および複製。他のシステムは均等にバランスが取られているか、重量があり、他のアプローチが必要です。

DO：TIMEのディメンションを使用してください。 Twitterは古典的な例です：つぶやきの99.99％は、最初の1時間/ 1日/週/何日後にもアクセスされません。これにより、データスキーマ内であらゆる種類の興味深い最適化の可能性が開かれます。

これはちょうど氷山の先端です。私は列ベースのNoSQLシステム（Cassandraなど）で少し読んでみることをお勧めします。