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

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

成都创新互联公司长期为上千余家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为冷水江企业提供专业的做网站、成都网站设计，冷水江网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。

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

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

尾部更新

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

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

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

原理如下：

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

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

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

非时间排序数据

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

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

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

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

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

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

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

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

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

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

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