正文
这是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,已经出现了巨额的提升——这就是发明专利加持的力量