性能优化技巧 - 集群维表
【摘要】
事实表和维表进行关联计算时,需要对维表进行频繁的随机访问,因此维表要尽量放在内存中,才能提高关联计算的性能。如果维表较大,单机内存放不下,就应该考虑用集群方式,将维表分段读入多台机器的内存。请通过性能优化技巧 - 集群维表中的例子了解集群维表的用法。
假设有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引用集群维表,并参与关联计算。