我的任务是为大型零售连锁店设计解决方案。他们希望允许其120万客户中的每一个都登录到网站上，以查看大约50个类别中最近购买的商品分布（当月，上个月，年初至今）。数据每天更新一次。
我正在考虑建立基于SQL Server 2012的OLAP多维数据集，并让网站直接利用主动缓存等功能来查询此多维数据集。但是，作为一名开发人员，我几乎没有SQL Server分析服务部分的经验，因此非常关注此解决方案的性能。
将网站直接连接到OLAP多维数据集听起来是否可行？这样的系统是否像SQL Server那样对来自多个用户的负载做出反应，使其成为一个合理的解决方案，还是它们的行为完全不同？
我不希望用户经常检查其状态，我当然会在Web服务器上使用缓存等。
Answers:
您可以使用OLAP系统执行此操作-SSAS对于此类应用程序的一些好处包括：
SSAS可以轻松扩展-特别是因为这是一个只读应用程序，不需要多维数据集写回。
可以调整聚合以最小化I / O，从而可以调整多维数据集的效率。
OLAP客户端软件和第三方控件（Web和富客户端）很容易从许多供应商处获得。
SQL Server 2012商业智能版几乎具有SSAS的所有可伸缩性功能，因此它可以用作在SQL Server企业版（或第三方）数据库中放置多维数据集的具有成本效益的平台。请注意，由于BI版本仅CAL，因此许可可能是一个问题。
SSAS具有数据挖掘功能，可用于对数据进行购物篮分析并在网站上提供“建议购买”功能。
另一方面，要求是显示相对受约束的数据集，因此OLAP服务器的临时分片和分片功能可能过高，无论是软件成本还是运行它的硬件基础设施成本（ SSAS非常耗费资源）。您可以通过定期刷新的摘要数据库来满足您的即时需求，并以更少的硬件和许可成本来实现。
乍一看，我认为OLAP可能不是满足您现有要求的必要条件。但是，肯定可以通过这种方式完成，并且您可能会从数据挖掘功能中获得一些帮助，以提供“建议的购买”功能。
SSAS是一个非常棘手的话题。您几乎不了解数据库引擎的任何知识都可以应用于Analysis Services。如果唯一的目标是为该报告提供后端，则与定期刷新存储在数据库中的某些摘要数据的更常规方法相比，加快Analysis Services的速度并实现OLAP数据库将是相当可观的开销。关系数据库，或创建从定期生成的执行快照运行的Reporting Services报表。
就是说，如果您确实长期需要Analysis Services的某些优势，例如临时多维报告和MDX表达式（您可以做一些非常酷的事情），并且您正在使用大量数据仓库，它可以大大胜过关系数据库，那么值得学习。但是，不要指望在一天之内捡起来。