5

NoSQL データベースに変換したい SQL データベースがあります (現在、RavenDB を使用しています)。

ここに私のテーブルがあります：

痕跡： 

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 ドキュメント モデルをどのように構築すればよいですか?

次のようになります。

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"
}

そして、Deployment 1 が変更された場合はどうなるでしょうか? 各ドキュメントを参照してデータを変更する必要がありますか?

また、NoSQL でいつ参照を使用する必要がありますか?

4

2 に答える 2

8

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

したがって、あなたの質問に答えるために、私たちが本当に知る必要があるのは、あなたがデータをどのように使用するつもりなのかということです. たとえば、すべてのトレースを時間順に表示することは、特定の展開またはアプリケーションに関連付けられたトレースを表示することとは明らかに異なるシナリオです。これらの要件のそれぞれが異なる設計を決定し、両方をサポートします。

これ自体があなたにとって有益な情報かもしれませんが (?)、もっと具体的な回答が必要なのではないかと思います :) 意図した使用法についてさらに詳細を追加してください。

戦略を決定する際には、いくつかの「すべきこと」と「すべきでないこと」があります。

すべきこと: 一般的なユースケースに合わせて最適化します。多くの場合、UX の 20% が負荷の 80% を駆動する 20/80 の内訳があります。Web アプリのホームページ/ランディング ページは典型的な例です。最優先事項は、これらが可能な限り効率的であることを確認することです。データモデルで、A) 単一の IO リクエストでそれらをロードするか、B) キャッシュフレンドリーであることを確認してください。

いけないこと: 恐ろしい「N+1」の罠にはまらないでください。このパターンは、データ モデルにより、N 個のエンティティを読み込むために N 回の呼び出しを行う必要がある場合に発生します。多くの場合、N 個の ID のリストを取得するための追加の呼び出しが先行します。これはキラーです、特に＃3と一緒に...

すべきこと: フェッチするデータの量を常に (UX を介して) 制限します。ユーザーが 3729 件のコメントを持っている場合、明らかにそれらすべてを一度に取得することはできません。データベースの観点からは実現可能であったとしても、ユーザー エクスペリエンスはひどいものになるでしょう。これが、検索エンジンが「次の 20 件の結果」パラダイムを使用する理由です。そのため、(たとえば) データベース構造を UX に合わせて、コメントを 20 個のブロックで保存できます。その後、各ページの更新には 1 回の DB 取得が含まれます。

実施: 読み取りと書き込みの要件のバランスを取ります。一部のタイプのシステムは読み取りが多く、書き込みごとに多くの読み取りが行われると想定できます (StackOverflow が良い例です)。したがって、読み取りパフォーマンスを向上させるために、書き込みのコストを高くすることは理にかなっています。たとえば、データの非正規化と複製。他のシステムは均等にバランスが取れているか、書き込みが多く、他のアプローチが必要です

すべきこと: 時間の次元を有利に利用してください。Twitter は典型的な例です。ツイートの 99.99% は、最初の 1 時間後、1 日後、1 週間後など、アクセスされることはありません。これにより、データ スキーマであらゆる種類の興味深い最適化の可能性が開かれます。

これは氷山の一角にすぎません。列ベースの NoSQL システム (Cassandra など) について少し調べてみることをお勧めします。

于 2013-05-02T21:25:34.177 に答える
1

ドキュメントをどのようにモデル化するかは、主にアプリケーションとそのドメインによって異なります。そこから、データ アクセス パターンを理解することでドキュメント モデルを改良できます。

むやみにリレーショナル データ モデルを非リレーショナル データ モデルにマッピングしようとするのは、おそらく良い考えではありません。

更新: マットはここで私の要点の主要なアイデアを得たと思います。私が言おうとしているのは、リレーショナル データ モデル (正規化された SQL スキーマなど) を非リレーショナル データ モデル (ドキュメント モデルなど) に変換するための規定された方法 (とにかく私が知っている方法) は存在しないということです。アプリケーションのドメインを考慮します。ここで少し詳しく説明しましょう...

SQL スキーマを見た後、Applications と Deployments を結合しているように見えるテーブル以外のトレースが何であるかわかりません。また、アプリケーションが通常どのようにデータをクエリするかについてもわかりません。これについて少し知っていると、アプリケーション オブジェクト (またはドメイン オブジェクト) をモデル化する方法が異なるように、ドキュメントをモデル化するときに違いが生じます。

したがって、質問で提案されているドキュメント モデルは、アプリケーションで機能する場合と機能しない場合があります。

于 2013-04-30T17:00:37.160 に答える