我们知道，Dynamic Cubes在DQM Server中被创建。因此，理解dynamic cube如何在DQM Server存在，管理命令、元数据以及数据请求如何传递给dynamic cube就很关键。
下面我们从dynamic cube和report server的关系，dynamic cube 和 DQM server的关系两个方面阐述这个问题。
1. dynamic cube 和 report server
一个dispatcher最多可以托管一个DQM Server，并以QueryService的形式，出现在它的服务列表中。运行在某个dispatcher之下的所有report server，通过一个特定端口和DQM 实例通信。也就是说，任何发布到某个dispatcher上的dynamic cube，都由同一个DQM 实例托管。
- 把一个dynamic cube配置到多个dispatcher上是有必要的，这可以为用户提供一定的拓展性。但是要注意，每个DQM实例都托管了cube的一个独立副本，这个副本无论是和底层数据仓库交互，还是自身的缓存，都是独立于其他dispatcher托管的cube的。因此，多用户访问某个逻辑cube，会为系统带来额外的开销。
- 每个包含dynamic cube的计算节点，都要有与其托管的cube以及预期的用户数量相适应的资源，包括CPU数量，内存大小。同时还要考虑负载均衡。
- 如果一个dynamic cube部署到了多个节点上，在执行cube启动，重启以及数据缓存刷新操作时，由于多个节点同时从底层数据库加载内存内聚合，底层数据库的负载会成倍增加。
- 同一个cube在不同节点上的缓存是不同步的。如果某个用户在一个节点上执行了某个查询，然后再另一个节点上又执行了同样的查询，响应速度可能有很大的差异。
- 因为每个cube节点都独立于其他节点，从底层数据库中加载数据。所以，底层数据库必须额外考虑这部分负载。
- dispatcher并不“知道”自己托管的cube的状态。所以不管其托管的cube是否可用，它都会把请求转发给相应的cube。因此，我们要采取额外的步骤，以保证每个dispatcher上的cube都是可用的。这样才可以避免用户因为cube不可用收到错误信息。
2. dynamic cube 和 DQM server
Dynamic cube存在于DQM server的内存中。在某个dynamic cube在DQM之内运行时，涉及到如下的缓存：
- 内存内成员缓存
每个层级结构（hierarchy）的成员都驻留在内存中，用来遍历父子关系和级别关系。当DQM查询验证成员唯一名称，执行成员或成员集操作时，会使用此缓存。例如：MEMBERS( [Level Name])
- 内存内聚合缓存
如果Aggregate Advisor的内存内聚合建议发布到CM，并且cube也为内存内聚合分配了内存，cube会把聚合值存放在独立cube成员中（cubelets）。每个cube成员存在独立的缓存内。直到达到配置给cube的空间上限。
- 内存内数据缓存
任何从底层数据库检索数据的查询，或者聚合缓存中的数据的进一步汇总，都储存在独立的缓存中作为cube成员（cubelets）
- 内存内安全缓存
任何唯一的安全视图组合都会驻留在内存中，用来为查询提供有效的安全过滤。
下图展示了一个dynamic cube中的各种缓存
这些结构驻留在DQM之内cube架构中。DQM server通过以下三种方式影响cube：
- 管理命令
- 元数据请求
- 查询执行
管理命令可以通过JMX（Java Management Extension）或BI bus命令获取。这些管理命令由DQM重定向给Dynamic Cube管理界面依次执行，比如stop，start等操作。
典型的元数据请求由BI客户端发出，用来填充元数据浏览器（Metadata Browser）。
DQM server把接收到的查询转换为MDX查询，然后由DQM server的MDX引擎运行。在MDX引擎运行过程中，可能需要执行成员操作，比如获取某成员的子成员。这些操作通过cube的元数据接口执行。MDX引擎还可能请求度量值，这个操作通过一个叫做的query strategy的接口来执行。
无论是元数据请求还是数据请求，在返回成员元数据或度量值之前，都要调用模型中的安全定义。
数据请求，通过cube的query strategy接口，使用cube的聚合缓存和数据缓存。
下图展示了DQM Server中的命令调度。
一个DQM Server可以托管一个或多个dynamic cube。如果DQM Server中有虚拟cube，那么虚拟cube的源cube必须存在同一个DQM Server中。