データベースは、Excel、GSheet、または大規模なORMシステムを使用して実装できます。 私のビジネス分析の実践では、さまざまなソリューションに出会いました。 そして、私は財務と監査からビジネス分析に来たので、新しいシステムに出会うたびに、私は自分自身に質問をしました。 いくつかの答えが見つかりました。 この記事では、データベースの2つの主な目的について説明します。
1-オペレーションのアカウンティング、
2-データ分析
最初のタイプのタスクはOLTPシステムによって解決されます： O n L ine Transaction Processingから。 2番目のタイプはOLAPシステムによって解決されます。On L ine A分析処理から
OLTP
OLTPストレージモデルは、電話帳のエントリと比較できます。 テーブルの行は、インデックスおよび対応するデータインデックスとして表示されます：（indexN、data）。 したがって、このようなテーブルをテーブルと呼ぶことはできません。 それは、番号の付いた行のある、普通の本です。 ブックに新しい操作を書き込む必要がある場合は、行を追加し、インデックスを割り当ててブックを閉じます。 すぐにO（log n）になり、目的の行を見つけてCRUDを実行できるようにする、本から突き出たラベル
運用会計の目的では、これはわかりやすい表示です。 しかし、データ分析には不向きです。データ分析では、行自体は重要ではなく、これらの行の内容に基づいて計算されます。 そして、行の内容に基づいて分析クエリを作成する場合、つまり インデックス化されていないフィールドの場合、このようなクエリの動作は遅くなります。
ご存知のように、すべてのレコードにインデックスを付けることはオプションではありません。 ブックはテーブルのようになりますが、属性がクイック検索で使用可能になると、新しい行の作成と既存の行の更新が遅くなります。 これらの操作では、アレイ全体を再ソートする必要があるためです。
OLAPとOLTPのトレードオフ
1Cソリューションでは、次のように妥協が実装されます。 データベースへの書き込み時のイベントは、一度に複数の場所に書き込まれます。 1つの場所では、レコードのインデックスがほとんどなく、OLTPロード用に最適化されていますが、別の場所では、レコードはすべてのフィールドによってインデックス付けされ、OLAPロードに適合しています。 このようなテーブルは、累積レジスタおよび情報レジスタと呼ばれます。 複数の場所に書き込むと占有スペースが数倍増加するため、すべてのトランザクション属性が保存するレジスタに分類されるわけではなく、分析会計のこのセクションで重要と見なされる属性のみが含まれます。 このような妥協はROLAPモデルと呼ばれます。 リレーショナル分析マッピング。
OLAP
SAPでは、ドイツの対応する1Cがさらに前進しました。 このソフトウェアのリレーショナルOLTPモデルは、OLAPモデルに複製できます。 SAP HANAはストレージ列構造を実装しています。 これは、「テーブル」が行のセットとしてではなく、列のセットとしてそこに格納されることを意味します。
同様のストレージスキームは、Google Bigquery、Microsoft SSAS Tabular、Amazon Redshift、Yandex ClickHouseなどのソリューションに実装されています。
列ストレージと行ストレージの違い
行単位の構造でデータが「水平」タプルの形式で保存されている場合、それぞれがトランザクションです：
period, product, department (Q1, SKU1, 1) (Q1, SKU2, 1) (Q1, SKU1, 1) ... (Q2, SKU1, 1) (Q2, SKU1, 1) (Q3, SKU1, 1) (Q3, SKU1, 1) ...
次に、そのようなデータは列に「垂直に」保存されます。
(Q1, Q1, Q1, ... Q2, Q2, Q3, Q3, ...) (SKU1, SKU2, SKU1, ... SKU1, SKU1, SKU1, SKU1, ...) (1,1,1, ... 1,1,1,1, ...)
繰り返しは、次のように条件付きで最適化できます。
period = (Q1, {start: 0, count: n}, Q2, {start: n+1; count: m}, ...) product = (SKU1, {start: 0, count: 1}, SKU2, {start: 1; count: 1}, SKU1, {start: 2; count: m}, ...) department = (1,{start:0, count:m}...)
そのような最適化によって初期ボリュームが削減されない列がある場合、データは元の形式で保存されます。
列テーブルのエンジン自体が列の並べ替え順序を選択しますが、データがわかっていて手動で並べ替える場合、多くの場合、これにより圧縮が増加し、分析負荷が軽減されます。 個々のテーブルの圧縮が300回を超えました。 実際には、このようなデータストレージ構造は次のとおりです。
- データをRAMに配置するときにレベルに圧縮できます。 リレーショナルデータベースへのクエリと速度が比較できないメモリ内計算を使用可能にする
- データモデルを構築するための独自のルールを設定し、OLTPのような正規化を必要としなくなりました
- 分析式を構築するためのセマンティクスを定義します。
式の詳細について詳しく説明します。
これはGoogle BigQuery用です。
これはMicrosoft DAX用です。
列ベースのインフラストラクチャとしてのBI
BIは、分析負荷に対応するソリューションです。 また、列データベースの上に構築すると、生活がずっと楽になります。 これは、自家製のClickHouse-Grafana-PythonバンチまたはGoogleスタックバンチ：Bigquery-Data Studio-Dataprep-DataflowまたはモノリシックPower BIです。
多次元キューブは、列ストレージに代わる別のOLAP代替手段です。 しかし、私にとっては、MQ式は、BQまたはDAXのSQLと比較すると、冗長で複雑です。