OBIEE

　　OBIEE 的缓存主要有两种类型：

　　一种table cache，

　　一种query cache，

　　table cache 在模型设计（rpd 模型库）里面，对应每一个phisical table，更新的方式就是定时更新。或者不cache。

　　query cache 就由模型库自动生成的SQL，管理的细节主要有设置大小，缓存文件存放位置。 条数，每个sql 最大占内存大小（完全不清楚为啥要后面两个参数），更新的粒度包括按表更新，按sql 更新，全部刷新（不知道为啥要全部刷新）。

　　特别注意的有几点。 一个就是它有一个event polling table，用来控制程序自定义的刷新时间，你做完ETL 之后，你自己往这个表插几条记录写下你更新了那些表，然后OBIEE Server 不停的读这个表的数据，发现变化了就刷新对应的这部分表的数据，包括table cache 和query cache。

　　对于什么时候要把cache 一定放在主内存里面，什么时候可以把过大的内存或者不经常用的内存放在硬盘上，OBIEE 通过一个session 变量row-wise initialization 来控制 （这个设定也让我有点无语，你不能自动统计计算不，亲）

　　OBIEE 的cache 默认是用户之间不共享的。 你要显示的在rpd 设计器里面Manage> Security -> Logon 里面设定用同一个用户名+密码登录，然后他们的connection pool 才能一致，如果不共享的话，相同权限的不同用户即使使用同一张报表得出的结果完全一样也是使用两个cache。 这坑爹的设定就是因为他的用户认证是在Weblogic 端，所以connection pool 都是跟user 绑定死的。 所以你一个数据库里面的用户密码变了，你所有rpd 里面用的这个用户都要改一遍。

　　OBIEE 也支持aggregate table。 但是你要自己写aggregate table 的生成sql。 定义他的aggregate level，它提供一个向导。 这个概念跟oracle database materialized view 是一样的。

　　Actuate

　　Actuate 的缓存设定概念上算是比较简单，就是对象有点多。

　　cache connection definition，cache object，cache tables，cache data

　　主要用在ad-hoc query 里面生成报表的。 基本对应table cache 和query cache。

　　Document 每个报表的设计格式（。rptdesign） 文件都可以先生成一个（。rptdocument） 文件，设计器里面也显示包含这个选项，你用web 的时候用的servlet 也可以指定这个。 这个document 是包含了所有数据的一种中间格式。 所以你同一个报表按照不同参数执行多次的时候，你直接用这种document，不用你的Actuate Server 从cache 里面取数据了，多次生成报表的时候更快。 如果你不生成document 格式，则你可以显示的指定报表去取最新的数据。

　　cache information object 这个对应的就是aggregate table，不过他只支持3种数据库，DB2，Oracle，SQL Server 。 不太清楚是不是直接就是使用的数据库底层的materialized view。

　　data object : Actuate 新的针对cube 出的，相当于是把所有事实表和维表都连接起来的冗余最大的情况，这个是完全在内存中的。 主要针对crosstab 的，一般的报表也可以使用，不过这种data object 的刷新很耗资源，如果你报表用的这个数据的话你要自己确保这个数据是不变的。 他不可能提供你一个servlet 直接重新从数据库底层执行SQL取最新数据。

　　MicroStrategy

　　MicroStrategy 的缓存分为4种类型:

　　Element Cache : 经常查看的对象的所有的值，类似于数据库维表的所有值

　　Object Cache : MicroStrategy 自己用的元数据的所有表，这个是可以配置一只在内存中的

　　Report Cache : 生成过一次的报表的结果。

　　Document Cache : microstrategy 自己的document 生成的结果。（ document 基本就是dashboard 了，不包括权限，下转等等）

　　其中前面两个是可以放在客户端（ Microstrategy Desktop ） 里面的。 也可以放在 Server 的内存里，后面两个比较大的缓存可以放在Server 的内存里，也可以写到文件里面。

　　microstrategy 的aggregate table 可以直接使用数据库里面的表，然后在设计器用模型定义好，不用显示的手工去针对模型表创建然后指定aggregate level，但是他不保证这个aggregate table 的数据是最新的。 他的执行计划可以显示打印出来SQL，他会自动根据你报表展示的级别判断使不使用aggregate table 。

　　MicroStrategy 也有Intelligent Cube。 也是基于内存的（也可以写文件） 。

　　总结：

　　总体来说，OBIEE 的缓存做的最差，更新机制完全不符合用户的使用条件，借用的oracle database 的cache 设计思路，没有以report 为中心，另外没有report 这种级别的缓存，对于大量用户请求同一张报表的时候显然有压力。

　　Actuate 的缓存功能上跟MicroStrategy 大同小异。 但是概念对象过多。 更新机制上Server 的管理需要一点维护工作量。

　　MicroStrategy 执行引擎设计的很NB，尤其是生成的SQL 比较高效，然后缓存什么时候该用，什么时候可以不用都是自动判断的。 aggregate table 又是自动聚合感知的。 更新的粒度和机制上都设计的很合理 。 缓存的内容哪些放内存，哪些放硬盘，都可以自动通过统计信息来控制，管理起来基本自动化。