データベース（OLTP）とレポート

Question

私は、ビジネスの大きな部分としてレポートを作成している取引プラットフォームで作業しています。

設定は次のとおりです。 SQL OLTPデータベース（約200テーブル） - レコード数はかなり少ないです。 （2万レコードが最大のテーブルですが、毎週増え続けています） レポートサービスの場合、SQLビューはライブトランザクションデータベースのクエリに使用されています。データウェアハウスアプローチの考え方で、ビューの結果セットが正規化されていないビューを想像してみてください。次に、これらのデータセットをTableau、Power Bi、SiSenseなどのサードパーティ製のレポートプラットフォームに渡します。これらのデータセットはCubes（おそらくmono db、hadoopなどの一部の円柱構造）にスローされます。そこからレポートが生成されます。

現在の課題。 SQLビュー（約8）。巨大で維持が非常に難しいです。例を挙げると、ビューの1つは100個のフィールドを出力します。しかし、これらの各フィールドは、複雑なCASE文、ネストされたIF文、インライン関数、およびそうでないものを含む計算フィールドです。このビューは700行のSQLコードと同じくらい大きいものになります。私はこれを他の従業員から継承しましたが、現在悲しみには、私はそれらを維持しなければなりません。 データは毎週数百レコード増加し（移行およびトランザクションによって）、ビュー内のフィールド数も増加するため（毎週数回）、キューブ構築にはより長い時間がかかります。例をあげると、数か月前に、データをリフレッシュするために10分前に再構築されたキューブをセットアップしました（これは5分かかりました）。現在は構築に12-15分かかるので、30分ごとに設定します。あなたが想像しているように、これはデータとフィールドの数が増え続けるにつれて悪化します。できるだけ最新のデータが必要となります。

唯一の良いことは、キューブが構築されると、サードパーティのプラットフォームからプルされているため、レポートが高速に読み込まれるということです。

は、私は心の で持っている私は、私はmaintenanaceのプロセスを容易にしても、最低でもキューブ再構築された時間を保つことができるので、景色を取り除くしたいと思います。

オプション：

1. データウェアハウスを構築します。 SSISパッケージを作成して、この構造にライブトランザクションデータを移入します。正規化されていない構造は、おそらく上記のビューと非常によく似ています。実際のところ、OLTPからOLAP（データウェアハウス）へのデータ移行であるもう1つのレイヤーを追加すると、私はそれほど単純化していないようです。そして私はまだキューブを再構築する必要があります。
2. 現在のビューをSQLインデックス付きビュー（マテリアライズドビュー）に変換するには、現在の状態で、アグリゲート関数とインライン関数がビュー全体で多く使用されているため、単純にできません。
3. もう1つの選択肢は、ODS（オペレーション・データ・ストア - これは私が今使っているSQLビューに似た必要なテーブルを含むデータベースになります）を構築し、それを常にリフレッシュすることです。ログ？しかし、私はそのようなものを構築するために何が関係しているのか、そして維持することがどれほど難しいかはわかりません

質問： 私は何なアプローチを取る必要がありますか？ 上記3のいずれかが意味を成しますか？ もちろん、他のアイデアや提案にも興味があります。

ありがとうございました！

Answer 1

私の経験から、あなたの最善のアプローチは1となります。費用がかかりますが、より良い利益をもたらすでしょう。列挙型データストア（amazon redshiftやsap sybase iqなど）とすべてのcase文、ネストされたifsなどを使用する場合は、ROLAP DWHを作成します（Kimballのベストプラクティスとデザインパターンについては「データウェアハウスツールキット」をお勧めします）あなたが言及したすべての操作はETL時間に適用されるため、ROLAPではすべてが事前計算され、消費に最適化されます。そして、あなたが使っている信頼技術に依存して、索引付けを忘れることはありません。一部のデータベースベンダーはすでにROLAPのための「ベストプラクティスの索引付け」を公開しているため、表のタイプ（ディメンション）とデータ型に応じてどのタイプの索引が使用されるかを示します。