正文

这是Star Schema Benchmark 标准测试集优化的第二篇，前一篇提到了优化表结构。

表结构优化完之后，我们分析了下表数据，

一、验证数据的标准性

这几个表，除了lineorder是根据factor成倍增长，其它的表记录数增长应该是缓慢的，对吧，有的表甚至没有随着factor增长，对吧？

上面是架构师问让我调研的，我查了下，customer、supplier、lineorder三张表是成倍增长的（1:10:100）。dates表固定不变（1:1:1），part表增长缓慢（1:4:7）；最大表（也即事实表） lineorder 除外，成倍增长的 supplier 和 lineorder 表虽然是成倍增长的，但基数也是不大，1000G 大小的数据集，customer 表才 3000万数据（lineorder是60亿数据）。

调查结果表明该数据集确实符合 Star Schema 的特点：星型模式将业务流程数据分为事实数据和维度数据，事实数据包含关于业务的可测量量化数据，维度是与事实数据相关的描述性属性。事实数据的例子包括销售价格、销售数量、时间、距离、速度和重量测量。相关的维度属性示例包括产品型号、产品颜色、产品大小、地理位置和销售人员名称。

二、验证数据结果的准确性

oracle数据库最好也安装一个，用它来比较查询结果；用它作为标准来验证查询结果，不能用别的数据库，因为我们不知道他们有没有bug，Oracle是绝对可信的。

这一步，我导入了1G，10G大小的数据到咱们的数据库，还有Oracle数据库。分别执行了13 条标准SQL，经过检验得知：咱们数据库得查询结果和 Oracle 数据库查询结果完全一致。

PS: 结合咱们数据库最新的多维分析专利技术，咱们除了多维数据这块的第一个版，使用 30G 大小的数据集，测得所有SQL的查询时间总计是 122s，100G大小的数据之前是 2800s，已经出现了巨额的提升——这就是发明专利加持的力量