2013-09-16 15 views
6

私は長い間、データウェアハウスプロジェクトとビッグデータサンプルを除いて、ロー指向のデータベース設計を使用しましたが、私はOLTPアプリケーションの列指向データベース設計を使用していません。列指向のデータベースと行指向のデータベース

私の行指向の表は、

ID, Make, Model, Month, Miles, Cost 
1 BMW Z3  12  12000 100 

列指向データベースの設計を提唱私たちのチームの何人かの人々のように見えます。 すべての列名は、Propertyテーブルのプロパティ名である必要があります。 別のテーブルQuoteには、PropertyNameとPropertyValueの2つのカラムがあります。

.netコードでは、各キーを読み取り、厳密に型指定されたオブジェクトと比較して変換します。コードは本当に乱雑になってきています。

if (qwi.DomainCode == typeof(CoreBO.Base.iQQConstants.MBPCollateralInfo).Name) 
    { 
     if (qwi.RefCode == iQQConstants.MBPCollateralInfo.ENGINETYPE) 
     { 
      Aspiration = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.FUELTYPE) 
     { 
      FuelType = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MAKE) 
     { 
      Make = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MILEAGE) 
     { 
      int reading = 0; 
      bool success = int.TryParse(qwi.Value, out reading); 
      if (success) 
      { 
       OdometerReading = reading; 
      } 
} 
} 

この列指向設計のためのarguementは、我々は(我々はまだ代わりに、Entity Frameworkののストアドプロシージャを使用している)テーブルスキーマとストアドプロシージャを変更する必要がないということです。

実際の問題に向かっているようです。列方向のデザインは業界で広く受け入れられていますか?

+1

"列指向"(列ストア)のDBMSとは何の関係もないようです。質問は実際にはEAVのデザインパターンに関するものです。 – sqlvogel

+0

"エンティティフレームワークの代わりにまだストアドプロシージャを使用しています" 私は多くの中小規模のプロジェクトでEFと遊んでいましたが、EFはこれ以上行くとは思わない。 私がテストしたことから、EFは、深刻な作業が考慮されるときに非常に頻繁にドアストッパーであるメモリを操作(更新)できるようにする必要があります。1アクティブ= 0 = UPDATE dbo.MyTable SETアクティブ: – Mariusz

+0

「我々はまだ代わりに、Entity Frameworkののストアドプロシージャを使用している」 EFは、それを変更することができるようにメモリ内のデータを必要としているようだ、そうのような単純なもの 大量のデータの場合、EFを使用するのは簡単ではないかもしれません(しかし、私はそれも大胆な時間をキックするので大好きです)。 – Mariusz

答えて

10

あなたの用語に問題があります。あなたはEAV構造(Entity-Attribute-Valueの略)を記述しています。

その他:「列指向」データベースは通常、他の列とは別に各列を格納するデータベースを参照します(データベースについて学んだとき、これは「垂直パーティショニング」と呼ばれていましたが、 。例としてParacelとVerticaがあります。

エンティティ属性値データベースは、エンティティの各属性を別々の行として格納しています。

特定の構造に最初に付いている問題は、入力です。いくつかの属性は文字列であり、いくつかは数字です。これはEAVの世界での管理の悪夢になります。すべてを文字列として格納するか(チェック値を入力する能力を失い、算術単語を保証するか)、型の列で異なる型の複数の列を含める(クエリをはるかに複雑にする)。

同様に、制約と外部キー参照は実装するのがはるかに難しいです。また、各行でエンティティIDと属性IDを繰り返すため、データがより多くの領域を占有することがあります。 NULLの値は、通常、かなり効率的です。

OLTP側には別の問題があります。エンティティを挿入する場合は、通常、複数の属性も挿入する必要があります。 1つのインサートが多くのインサートになりました。これをトランザクションにラップして、パフォーマンスに影響を与えたいと思うでしょう。

これらの欠点をすべて勘案すると、はEAVモデルを使用しないと思われるかもしれません。彼らのための場所があります。時間の経過とともに属性が変化する場合に特に便利です。あなたがタグを使って自分の情報を入れることができるアプリケーションがあるとします。そのような場合、ハイブリッドアプローチが最良の解決策です。共通情報には、多くの列を持つ通常のリレーショナル表を使用します。各エンティティのオプション情報には、EAVテーブルを使用します。

4

出典:読んでいるのでWIKI

  1. 列指向の組織は、集約は多くの行の上にだけ、データのすべての列の、特に小さなサブセットに対して計算する必要がある場合に、より効率的であること、データの小さなサブセットすべてのデータを読み取るよりも速くなる可能性があります。
  2. 列指向の組織は、列データを効率よく書き出し、行の他の列に触れることなく古い列データを置き換えることができるため、列の新しい値をすべての行に同時に提供すると効率的です。
  3. 行指向の組織は、1つの行の多くの列が同時に必要な場合や、行サイズが比較的小さい場合に、単一のディスクシークで行全体を取得できる場合に、より効率的です。
  4. 列全体のデータを1回のディスクシークで書き込むことができるので、すべての列データが同時に提供される場合は、新しい行を作成する方が効率的です。

実際には、行指向の記憶域レイアウトは、対話型トランザクションの負荷が高いOLTPのような作業負荷に適しています。列指向の記憶域レイアウトは、一般に、すべてのデータ(おそらくテラバイト)にわたって非常に複雑なクエリの数がより少ないOLAPライクな作業負荷(たとえばデータウェアハウス)に適しています。

+1

もちろん、正しいですが、問題は柱状ストレージを求めませんでした:-) – dnoeth

3

さらに、EAVデータモデルでは、質問が難しいとされています。つまり、BMWと12月から24ヶ月の間に車が見つかり、コストは<10000です。数字の文字列比較を行っている場合は特に...

0

一般的に、行指向と列指向は、低レベル(ディスク)の記憶メカニズムです。各ストレージの良さは、要件によって異なります。いくつかのシナリオでは、列指向の記憶域が良好になり、一部のシナリオでは列指向の記憶域が得られます。

Hbasデータベースでは、列の集合である列ファミリの概念を使用しています。

行指向の違いは、行で構成される論理表が行ブロックごとに1行格納され、列指向の列が列ブロックごとに1列格納されるということです。

行指向は、分析的な(給与の合計、平均給与などの)問合せを実行してもパフォーマンスが低下しますが、行の完全な詳細にアクセスしたり、新しいレコードを挿入する必要がある場合には問題ありません。列指向は分析クエリでは問題ありませんが、個々のレコードの挿入や行のすべての詳細へのアクセスではパフォーマンスが低下します。

このシナリオの賛否両論と例とその概要の違いを説明したこのリンクをご覧ください。ここ

クリック:私の経験のEAVからhttp://geekrandomstuff.blogspot.tw/2014/04/row-oriented-database-vs-column.html

0

は、アプリケーションの設定、すなわちを格納するのに最適です。比較的静的なデータであっても、データの結合と変換の必要はありません。それ以上のことはありません。

関連する問題