多年后再思考MOLAP、HOLAP和ROLAP
ROLAP(relational OLAP)，明细数据、聚合后的数据都保存在关系型的数据库中。这种⽅式查询效率最低，每次查询都需要计算，效率⾼不⾼完全靠数据库。数据库需要持续调优。
HOLAP(hybrid OLAP)，明细数据保留在关系型数据库的事实表中，但是聚合后的数据保存在cube中。
MOLAP(multidimensional OLAP)，将明细数据和聚合后的数据均保存在cube中，在查询性能上有很⼤提⾼，其实就是空间换时间。需要额外购买产品，⽽且会⽽外增加管理维护成本。
我们原来在某⼤⾏⾥⾯试过多次Cube，虽然都知道MOLAP效率快，但是因为早期版本（现在不知道是否改善）权限、数据刷新、模型不稳定维度经常变化以及产品功能原因，屡试屡败。我们最终⽅案是ROLAP，采⽤greenplum搭建了128台机器的集作为访问数据库，底层全部存储明细数据，前端采⽤cognos query studio 作为⾃由拖拽。实现了灵活查询与效率之间的⼀个相互平衡和制约，查询效率不会太⾼，但是业务更关注的是能够出数据⽽不是效率本⾝，当然也感谢业务部门的包容。⽽且咨询过同业经验，基本都抛弃了CUBE，采⽤ROLAP。
基于明细数据的多维模型、雪花模型能够⽀持业务灵活⽤数的问题，但是性能问题是⼀⼤头痛的事情，ROLAP开发简单但是效率完全依靠数据库本⾝，当数据量到⼀定程度后很难保证性能，所以在模型之后
⼜出现了⼤量为了解决性能⽽开发的报表物理表（宽表）。MOLAP固然能解决效率⽅⾯很多的问题，但是相对ROLAP也会带来产品本⾝的管理运维成本的增加，⽽且屡试屡败的经验确实留下了阴影。
套⽤⼀句话，我们要的是⾦融服务⽽不是银⾏，时⾄今⽇我们⼀年还有⼏次步⼊银⾏柜台，但是银⾏⽣意照样红⽕我们每天也离不开⾦融服务。其实不管是ROLAP还是MOLAP，我们要的是查询效率和业务期待之间的平衡，⽽不在乎后台的实现技术本⾝。是否有⼀种产品，既具备ROLAP开发设计、使⽤的灵活性，⼜能够很好解决查询效率问题？同时⽀持横向扩展，⽀持海量数据的⼤并发查询。
>greenplum数据库

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。