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

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

私たちは本当の問題に向かっているようです。業界で受け入れられている列指向の設計です。

4

5 に答える 5

11

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

余談ですが、「列指向」データベースとは、通常、各列を他の列とは別に格納するデータベースを指します (データベースについて学んだとき、これは「垂直分割」と呼ばれていましたが、普及しているとは思いません)。例としては、Paracel と Vertica があります。

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

特定の構造で最初に発生する問題は、タイピングです。一部の属性は文字列で、一部は数値です。これは、EAV の世界では管理上の悪夢となります。すべてを文字列として格納するか (チェック値を入力し、その算術単語を保証する機能を失う)、型列に異なる型の複数の列を含める (クエリをより複雑にする) かのいずれかです。

同様に、制約と外部キー参照の実装ははるかに困難です。また、各行でエンティティ ID と属性 ID を繰り返しているため、データは多くの場合、より多くのスペースを占有します。 NULL値は通常、非常にスペース効率が良いです。

OLTP 側では、別の問題があります。エンティティを挿入する場合は、通常、一連の属性も挿入します。1 つの挿入が多くの挿入に変わったので、これらをトランザクションにラップして、パフォーマンスに影響を与える必要があります。

これらすべての欠点を考慮すると、 EAV モデルは使用しないと考えるかもしれません。彼らのための場所があります。これらは、属性が時間の経過とともに変化する場合に特に役立ちます。たとえば、ユーザーがタグを使用して自分の情報を入力できるアプリケーションがあるとします。このような場合は、ハイブリッド アプローチが最適なソリューションです。共通情報には、多くの列を持つ通常のリレーショナル テーブルを使用します。各エンティティのオプション情報には、EAV テーブルを使用します。

于 2013-09-16T15:39:54.057 に答える
5

出典：ウィキ

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

実際には、行指向のストレージ レイアウトは、対話型トランザクションの負荷が高い OLTP のようなワークロードに適しています。列指向のストレージ レイアウトは、OLAP のようなワークロード (データ ウェアハウスなど) に適しています。これは通常、すべてのデータ (場合によってはテラバイト) に対して少数の非常に複雑なクエリを実行します。

于 2013-09-16T15:28:35.207 に答える
3

Gordon Linoff が言及している問題に加えて、EAV データ モデルは非常にクエリが困難です。メーカーが BMW で、月が 12 ～ 24 で、コストが 10000 未満のすべての車を検索すると、厄介な SQL の巨大な寄せ集めになります。 '数値の文字列比較を行っています...

于 2013-09-16T16:20:31.773 に答える
0

私の経験から、EAV はアプリケーション設定の保存に最適です。データを結合して変換する必要がなく、比較的静的なデータです。それ以上のものはありません。

于 2015-05-15T08:41:06.223 に答える
0

一般的に、行指向および列指向は、低レベル (ディスク) でのストレージ メカニズムです。各ストレージの良さは、要件によって異なります。一部のシナリオでは、列指向のストレージの方が優れており、一部のシナリオでは行指向のストレージの方が優れています。

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

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

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

このリンクにアクセスして、さまざまなシナリオの長所と短所を例とそれらの要約の違いで説明しています。

ここをクリック: http://geekrandomstuff.blogspot.tw/2014/04/row-directional-database-vs-column.html

于 2014-04-24T11:12:25.727 に答える