性能优化技巧 - 组表数据更新

浏览: 1111

组表是集算器提供的高性能存储格式,其原理在于将数据事先排序并以压缩方式紧致存储,好处是占用空间更小,可利用有序进行快速定位。

但这种存储方式在数据更新时会遇到麻烦,这是因为新数据也要和历史数据一起排序并压缩,常常会要求重写整个组表,重写操作非常耗时,但又不得不做。

不过,有些场景下却有高性能的数据更新手段,我们来看一下。

尾部更新

我们知道,组表允许修改少量数据。但修改量积累较多时,就要做一下reset(重整),否则会影响运算性能(因为修改部分无法紧致压缩存储,细节原理可参考其它文档)。

但是reset动作相当于重写整个组表,在组表很大时就会花费大量时间。有没有更快的手段呢?

如果组表中修改的记录都是近期的(键顺序靠后),则重整组表时可以使用reset@q,能够大幅度减少重整时间。

原理如下:

如前所述,组表数据分成了两个区域:紧致且高效的正文区、松散且低效的补充区,修改的数据只存放在补充区,并不会改动正文区。执行reset时将重写整个文件,把补充区数据和正文区合并。而reset@q时,组表会先在正文区找到重整位置(补充区中最早被修改的记录位置),将该位置之后的数据与补充区合并整理就可以了。

比如组文件以时间为键,存储了1-12月的数据,其中12月份的数据有改动。执行reset@q时,不会动前11月的数据,只将12月份的正文区数据和补充区合并,在重整过程中,只涉及12这1个月的数据。

如果不用@q选项,组表在reset时会把1-12月数据全部重写一遍,涉及12个月的数据,时间就会长很多。

 

非时间排序数据

按账户查询历史记录是很常见的需求,我们只需把数据按帐户排序,就能获得较好的查询性能,即使并发较多也可以支持。

比如下面代码,将历史报税单按帐户排序并生成组表:

image.png

然后基于这个有序的组表,按帐户查询就能获得很好的性能:

image.png

 

但是,生产系统会源源不断产生新增数据,而这些新增数据却不是按账户排序的(一般来讲会按产生时间为序)。如果要将新增数据也加入到历史中,就需要将两者归并排序。

组表提供了append@m函数,可以自动将新增数据与历史数据归并排序,但它的时间成本却相当大,因为即使归并排序也需要将历史数据全部重写一遍 ,而历史数据往往非常巨大。

那么,有什么好办法能减少归并排序的时间,从而提高数据更新的性能呢?

使用组表文件组可以解决该问题。

文件组原理是将多个同构文件模拟成一个文件,该文件在逻辑上可当作普通文件使用,即支持普通文件所有的函数。特别地,文件组还支持自动归并。我们可以把数据分为历史组表和增量组表两个文件,查询时使用这两个文件构成的文件组,这相当于对一个组表进行查询。每次定时更新时只对增量组表做小归并,这样可以提高日常更新的性能。而积累到一定程度后,才将增量组表和历史组表做一次大归并。

比如报税单日增10万条,可在每天执行如下脚本,用来处理新增数据:

image.png

上述代码中taxMonth.ctx是增量组表,最多存储一个月的数据,每天新增数据会追加到该组表中,月初再将该组表与历史组表taxHis.ctx合并。函数reset@m用于重整文件组,可将所有数据写入第一个组表中,并清空其他组表中的数据。函数append@m可将同构同序的游标以归并方式追加到组表中。

实现业务计算时,可将历史组表与增量组表在逻辑上合并,以文件组的形式进行查询,其性能和单一组表文件相差不大。代码如下:

image.png

 

推荐 0
本文由 润乾软件 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

0 个评论

要回复文章请先登录注册