私は大規模な小売チェーン向けのソリューションの設計を任されています。彼らは、120万人の顧客のそれぞれがWebサイトにログオンして、約50のカテゴリーにわたる最近の購入(当月、前月、年初から現在まで)の分布を確認できるようにしたいと考えています。データは毎日1回更新されます。
SQL Server 2012ベースのOLAP=キューブを配置し、プロアクティブキャッシュなどの機能を利用して、Webサイトにこのキューブを直接クエリさせることを考えています。ただし、開発者である私は、 SQL Serverの分析サービスの部分に関する経験があるため、このソリューションのパフォーマンスについてはかなり心配しています。
WebサイトをOLAPキューブに直接接続すると、実行可能なソリューションのように聞こえますか?そのようなシステムは、SQL Serverのように複数のユーザーからの負荷に反応して、これを合理的なソリューションにしますか、それともまったく違う行動をしますか?
ユーザーが自分のステータスを頻繁に確認することは期待していません。もちろん、Webサーバーなどでキャッシュを使用します。
これは、OLAPシステムを使用して行うことができます。このタイプのアプリケーションに対するSSASの利点には、次のようなものがあります。
SSASは容易にスケールアウトできます。これは特に、キューブの書き戻しを必要としない読み取り専用アプリケーションであるためです。
集約を調整してI/Oを最小限に抑え、効率を上げるためにキューブを調整することができます。
OLAPクライアントソフトウェアとサードパーティコントロール(Webおよびリッチクライアント)は、多くのベンダーから簡単に入手できます。
SQL Server 2012ビジネスインテリジェンスエディションは、SSASのスケーラビリティ機能のほとんどすべてを備えているため、SQL Serverエンタープライズエディション(またはサードパーティ)データベースのキューブをフロントエンドするコスト効率の高いプラットフォームとして使用できます。ライセンスは、B.I。エディションはCALのみです。
SSASにはデータマイニング機能があり、これを使用してデータの買い物かご分析を行い、Webサイトで「購入提案」機能をフィードできます。
一方、要件は比較的制約されたデータセットを表示することであるため、OLAPサーバーのアドホックスライスアンドダイス機能は、ソフトウェアのコストとハードウェアインフラストラクチャを実行するためのコスト(SSASはリソースを大量に消費します)定期的に更新されるサマリーデータベースを使用して当面の要件を達成し、ハードウェアとライセンスのコストを削減することができます。
一見すると、OLAPはおそらく既存の要件を満たすために必要ではありません。しかし、それは確かにこの方法で行うことができ、提供するデータマイニング機能からいくらかのメリットを得られるかもしれません。 「おすすめの購入」機能。
SSASはveryの重要なトピックです。データベースエンジンについて知っていることのほとんどをAnalysis Servicesに適用することはできません。唯一の目標がこのレポートのバックエンドを提供することである場合、Analysis Servicesを最大限に活用し、OLAPデータベースを実装することは、従来のアプローチに比べてかなりのオーバーヘッドになります。リレーショナルデータベースに格納されている一部のサマリーデータを定期的に更新する、または定期的に生成される実行スナップショットから実行されるReporting Servicesレポートを作成する。
つまり、アドホックな多次元レポートやMDX式など、Analysis Servicesの長所の一部が本当に長期的に必要であり、非常に大規模な作業を行っている場合リレーショナルデータベースのパフォーマンスを大幅に向上させることができるデータウェアハウスの場合、学習する価値があります。ただし、1日で受け取ることはできません。
はい、これは非常に合理的な解決策です。同様の負荷のSSASを使用しているクライアントがいて、問題なく動作します。他のデータベース設計と同様に、得られるパフォーマンスは、キューブの設計の良さに直接関係します。