我被委托为一家大型零售连锁店设计一个解决方案。他们希望允许每个120万名顾客登录网站,查看近期购买的分布情况(本月、上月、年度)涉及约50个类别。 数据将每天更新一次。 我考虑建立一个基于SQL Server 2012的OLAP立方体,并让网站直接查询该立方体,利用主动缓存等功能。然而,作为一名开发人员,我对SQL Server的分析服务部分几乎没有经验,所以对这个解决方案的性能非常担心。 将网站直接连接到OLAP立方体听起来是否可行?这样的系统是否像SQL Server一样对多用户负载做出反应,使得这个解决方案合理,还是它们完全不同? 我不指望用户经常检查他们的状态,当然我会在Web服务器上使用缓存等技术。
你可以使用OLAP系统来实现这个功能 - SSAS在这种应用中的一些好处包括: - SSAS可以轻松扩展 - 特别是因为这是一个只读应用,没有立方体写回的要求。 - 聚合可以调整以最小化I/O,从而使立方体能够高效运行。 - OLAP客户端软件和第三方控件(Web和富客户端)可以从多个供应商处轻松获取。 - SQL Server 2012 Business Intelligence版本几乎具备了所有SSAS的可扩展性功能,因此它可以作为一个成本效益高的平台,用于为SQL Server企业版(或第三方)数据库提供立方体前端。请注意,许可证可能是一个问题,因为B.I.版本仅限于CAL。 - SSAS具有数据挖掘功能,可以用于对数据进行购物篮分析,并在网站上提供“推荐购买”功能。 另一方面,要求展示一个相对受限的数据集,因此使用OLAP服务器的即席切片和切块功能可能过于复杂,无论是软件成本还是运行所需的硬件基础设施成本(SSAS对资源需求较高)。您可能可以通过定期刷新的摘要数据库来满足您的直接需求,并且可以以更少的硬件和许可成本完成。 初步看来,我建议您不需要使用OLAP来满足您现有的需求。然而,您当然可以这样做,并且可能会从数据挖掘功能中获得一些收益,以提供“推荐购买”功能。
SSAS是一个非常庞大的主题。关于数据库引擎的知识几乎都无法应用到分析服务上。如果唯一的目标是为这个报表提供后端支持,那么学习分析服务并实现OLAP数据库相较于定期刷新一些储存在关系数据库中的摘要数据或创建一个从定期生成的执行快照中运行的报表服务报告来说,将会增加相当大的额外开销。 话虽如此,如果你确实长期需要分析服务的某些优势,比如自由多维报表和MDX表达式(可以做一些非常酷的事情),并且你正在处理一个非常庞大的数据仓库,使其能够明显优于关系数据库,那么学习它可能是值得的。然而,请不要期望在一天内就能掌握它。