事实表和维表进行关联计算时，需要对维表进行频繁的随机访问，因此维表要尽量放在内存中，才能提高关联计算的性能。如果维表较大，单机内存放不下，就应该考虑用集群方式，将维表分段读入多台机器的内存。下面举例说明集群维表的用法。
假设有2个计算节点，分别为127.0.0.1:8281、127.0.0.1:8282。执行如下脚本，可将产品表加载到节点机内存中：
|
|
A | B |
| 1 | =["127.0.0.1:8281","127.0.0.1:8282"] |
|
| 2 | fork [[1,20000000],[20000000,40000000]];A1 | =connect("demo1").query@x("select productID,name,price from product where productID>? and productID<=? order by productID ",A2(1),A2(2)).keys(productID) |
| 3 |
|
=env(product,B2) |
A2:语句fork可在多个节点机上并行执行任务，其中[1,20000000]是第1台节点机的入口参数。
B2：各节点按入口参数分别查询产品表。其中1号节点取出编号在1-20000000之间的产品。需要注意的是：各节点数据不能有重合，需按维表主键排序，需用key函数建立物理键。
B3：函数env用来在节点机设置全局变量，各节点机变量名相同，。
接下来实现业务算法：
|
|
A |
| 1 | =["127.0.0.1:8281","127.0.0.1:8282"] |
| 2 | =memory(A1, product) |
| 3 | =connect("demo1").cursor@x("select orderID,productID,client, quantity from order") |
| 4 | =A3.switch(productID,A2: productID) |
| 5 | =A4.groups(client;sum(productID.price *quantity)) |
A2：按名字product在各节点机寻找全局变量，返回集群维表。注意集群维表是个远程引用，对应的数据在各节点机。
A3：从数据库取出订单事实表。事实表通常数据量较大，需要用游标返回。事实表的来源不限于数据库，任意游标都可以。
A4：对事实表和集群维表进行关联计算。除了cs.switch()函数，也可以用cs.join()函数进行关联计算。
A5：对关联结果进一步计算，这里以分组汇总为例。
上述例子中，集群维表来自于数据源，底层数据结构为序表，但序表无压缩，占用空间较大。如果以SPL组表为数据源，则内存中的数据结构为内表，而内表有压缩，占用空间较小。
假设维表已分成2份，各自存为组表，名字都叫product.ctx，分别放置在两个节点机的0数据区上，则加载数据的脚本如下：
|
|
A |
| 1 | =file@z0("product.ctx", ["127.0.0.1:8281","127.0.0.1:8282"]) |
| 2 | =A1.create().memory() |
| 3 | =env(product,A2) |
A1：在各节点机的0数据区，寻找名为product.ctx的组表，定义为分布组表。
A2：将分布组表加载到各节点机内存，形成集群维表。
A3：在汇总机定义全局变量product，指向集群维表。
实现业务算法的脚本如下：
|
|
A |
| 1 | =connect("demo1").cursor@x("select orderID,productID,client, quantity from order") |
| 2 | =A1.switch(productID,product: productID) |
| 3 | =A2.groups(client;sum(productID.price *quantity)) |
A2：直接用全局变量名product引用集群维表，并参与关联计算。