7

私は、通常の職務の範囲をはるかに超えた仕事のプロジェクトに着手しようとしています。SQL DBA としての私の最初の傾向は、SQL データベースを使用してプロジェクトにアプローチすることでしたが、NoSQL について学べば学ぶほど、それがより良い選択肢であると信じるようになりました。この質問を使用してプロジェクトの概要を説明し、各オプションを使用することの長所と短所に関するフィードバックを得ることができればと思っていました.

プロジェクトは比較的簡単です。さまざまな属性を持つ一連のオブジェクトがあります。これらの属性には、すべてのオブジェクトに共通するものもあれば、オブジェクトのサブセットのみに共通するものもあります。私が構築を任されているのは、ユーザーがオブジェクトの属性に基づく一連のフィルターを選択し、すべてのフィルターに一致するオブジェクトのリストを返すサービスです^。ユーザーがフィルターを選択するとき、ユーザーは共通属性またはサブセット属性をフィルター処理している可能性がありますが、それはフロントエンドで抽象化されています。

^ ユーザーのフィードバックによっては、オブジェクトのリストが一部のフィルターのみに一致する可能性があり、その一致の質が、一致した基準の数を示すスコアを通じてユーザーに表示されます。

Martin Folwler によるこの講演 ( http://www.youtube.com/watch?v=qI_g07C_Q5I ) を見た後、ドキュメント スタイルの NoSQL データベースが私のニーズに合っているように思えますが、このアプローチの経験がないことを考えると、明らかな何かが欠けている可能性もあります。

追加情報 - データベースには、最初は約 5,000 のオブジェクトがあり、各オブジェクトには 10 ～ 50 の属性が含まれますが、オブジェクトの数は時間の経過とともに確実に増加し、属性の数はユーザーのフィードバックに応じて増加する可能性があります。さらに、ユーザーからのフィードバックを受けて製品を迅速に変更できるようにしたいと考えているため、柔軟性は非常に重要です。

フィードバックをお寄せいただければ幸いです。ディスカッションで重要な点が抜け落ちていた場合は、喜んでさらに情報を提供させていただきます。ありがとう。

4

3 に答える 3

3

この問題は、2 つの別個のテクノロジを使用することで解決できます。1 つ目は、最新の RDBMS で比較的適切に設計されたデータベース スキーマを使用することです。正規化の通常の原則を使用してアプリケーションをモデル化することにより、個々の CRUD ステートメントに対してストレージから非常に優れた応答が得られます。

ご想像のとおり、このスキーマを検索することは、大規模な悪夢になるでしょう。やらないでください。代わりに、Solr/Luceneを全文検索エンジンとして使用することを検討してください。Solr は動的フィールドをサポートしているため、Solr スキーマを正しく設計していれば、その場でドキュメント/オブジェクトに新しいプロパティを追加し、すぐにデータ内を検索できます。

于 2013-10-22T15:42:07.200 に答える
2

私は NoSQL の専門家ではないので、NoSQL を推奨するつもりはありません。ただし、リレーショナルデータベースの構造に関する質問に対処するのに役立つポイントがいくつかあります。

私がすぐに最初に目にするのは、(少なくとも概念的には)継承について話しているということです。オブジェクトは相互に継承されるため、派生オブジェクトに追加の属性があります。新しいタイプのオブジェクトを追加するとします。最初に (概念的に) 行う必要があるのは、属性のサブセットを持ち、それらの上に追加する (拡張する) ベース/スーパー (親) オブジェクト タイプを見つけることです。基本オブジェクト タイプ)。

上記のような考え方に慣れたら、次はリレーショナル データベースの継承マッピング パターンについてです。Martin Fowler の言葉を借りて、ここで説明します。

次の 3 つの方法のいずれかに従って、継承チェーンをデータベースに保持できます。

1 -単一テーブルの継承: 継承チェーン全体が 1 つのテーブルにあります。したがって、新しいタイプのオブジェクトはすべて同じテーブルに入ります。

利点: 検索クエリには検索するテーブルが 1 つしかなく、たとえば結合よりも高速である必要があります。

短所: テーブルは、たとえばオプション 2 よりも速く大きくなります。type行がどのタイプのオブジェクトであるかを示す列を追加する必要があります。一部の行は他のタイプのオブジェクトに属しているため、空の列があります。

2 -具体的なテーブルの継承: 新しいタイプのオブジェクトごとに個別のテーブル。

利点: 検索が 1 つのタイプのみに影響する場合は、一度に 1 つのテーブルのみを検索します。たとえば、各テーブルの成長はオプション 1 よりも遅くなります。

短所: 同時に複数のタイプを検索する場合は、クエリの結合を使用する必要があります。

3 -クラス テーブルの継承: 属性のみを持つ基本タイプ オブジェクト用の 1 つのテーブル、各子オブジェクト タイプ用の追加の属性を持つ追加のテーブル。したがって、子テーブルは PK/FK 関係を持つベース テーブルを参照します。

利点: すべてのタイプが 1 つのテーブルに存在するため、共通の属性を使用して簡単にまとめて検索できます。

短所: ベース テーブルには子テーブルの一部も含まれているため、すぐに大きくなります。join を使用して、すべての属性を持つすべてのタイプのオブジェクトを検索する必要があります。

どちらを選ぶ？

それは明らかにトレードオフです。多くの種類のオブジェクトが追加されることが予想される場合は、合理的なクエリとスケーリング オプションを提供する具象テーブル継承を使用します。クラス テーブルの継承は、高速なクエリとスケーラビリティにあまり適していないようです。単一テーブルの継承は、少数の型でうまく機能するようです。

あなたの電話、私の友人！

于 2013-10-25T22:46:05.433 に答える
1

これを答えにすることもできます。私は NoSQL が得意ではないので、SQL に傾倒する傾向があるとコメントしておく必要があります。

私はこれを 3 つのテーブル セットとして行います。Web ではエンティティ値ペア ロジックと呼ばれていることがわかります。これは、アイテムの複数の動的属性を処理する方法です。たくさんの製品があり、それぞれにいくつかの属性があるとしましょう。

Prd 1 - a,b,c
Prd 2 - a,d,e,f
Prd 3 - a,b,d,g
Prd 4 - a,c,d,e,f

ここでは、4 つの製品と 6 つの属性を示します。同じ理論が、数百の製品と数千の属性に適用されます。これを 1 つのテーブルに保持する標準的な方法では、データを格納するための 6 つの列と共に製品情報が必要です (この設定では、それらの少なくとも 3 分の 1 が null です)。新しい属性が追加されるということは、テーブルを変更して別の列を追加し、スクリプトを作成して既存のデータを入力するか、既存のすべてに対して null のままにすることを意味します。最も楽しいわけではなく、頭が痛くなる可能性があります。

これに代わる方法は、名前と値のペアのセットアップです。「ヘッダー」テーブルに、製品間で共通の値 (名前や価格など、すべての製品が常に持っているもの) を保持する必要があります。上記の例では、属性 'a' が各レコードで使用されていることがわかります...これは、属性 a もヘッダー テーブルの一部になる可能性があることを意味します。ここでは、キー列を「header_id」と呼びます。

2 番目のテーブルは、各製品に割り当てることができる属性を格納し、それに ID を割り当てるだけの参照テーブルです。キーの atrr_id で table 属性を呼び出します。むしろ簡単に言えば、上記の各属性は 1 行になります。

簡単な例:

attr_id, attribute_name, notes
1,b, the length of time the product takes to install
2,c, spare part required
etc...

これは、すべての属性とその属性の意味の単なるリストです。将来的には、このテーブルに行を追加して、各ヘッダーの新しい属性を開く予定です。

Final table は、実際に情報を保持するマッピング テーブルです。製品 ID、属性 ID、そして値が表示されます。通常、詳細テーブルと呼ばれます。

prd1, b, 5 mins
prd1, c, needs spare jack
prd2, d, 'misc text'
prd3, b, 15 mins

プロダクト キー、値ラベル、値としてデータがどのように保存されているかを確認してください。今後追加される製品は、このテーブルに格納されている属性を自由に組み合わせることができます。新しい属性の追加とは、属性テーブルに新しい行を追加し、必要に応じて詳細テーブルに入力することです。

ウィキもあると思います... http://en.wikipedia.org/wiki/Entity-attribute-value_model

この後は、データをピボットするための最適な方法を見つけ出すだけです (ここでは、オープンソース データベース オプションとして Postgres をお勧めします)。

于 2013-10-22T17:57:25.113 に答える