万亿秒查是真地吗?比 ORACLE 快 N 倍是不是吹牛?

我们经常听到大数据产品宣传自己性能好,“万亿秒查”是个常见的说法,大概意思就是上万亿行数据中找出查出满足条件的数据,可以秒级返回。
这是真地吗?
看过“1T 数据到底有多大”那期的同学大概都会觉得不可能。万亿行数据,得有几十上百 T 了,想秒级处理,岂不是得要几万几十万块硬盘,这不太现实。

其实不然,秒查并不一定意味着全遍历。如果是用唯一标识号去查找(比如电话号码,不过也没有万亿个),建好索引后的计算量并不是很大,读取和比较次数大概是 40 次左右,现代计算机在 1 秒内完成这个计算量毫无压力,甚至还能有不少并发。这种定点查找任务的计算复杂度是对数级别的,数据量从 100 万行涨到 1 万亿行,查找计算量仅仅涨到 2 倍而已。只要存得下,几乎所有数据库都有这个本事,这毫不稀奇。当然,建索引会很慢,但那是另一回事了。
如果是需要遍历才能完成的运算呢?比如计算某个列的合计,索引在这里没有用了。
嗯,这件事,万亿行上想秒查是不太现实了,但针对 TB 级数据却是可能的。如果这些数据总共有 100 列,统计一列时只要读 1% 的数据量,可能也就只有 10G,这样有 10 块硬盘就能在数秒内扫描一遍了,这点配置对于现代服务器集群而言是个小菜,再大 10 倍也不是问题。
所谓能秒级处理 TB 级数据量的,很可能是这个意思!大家都能做到。

还有些产品喜欢和老牌知名数据库对比,比如 Oracle,经常听到宣称比 Oracle 快 N 倍的,这是不是吹牛吗?毕竟 Oracle 是世界级标杆产品,哪能随随便便就被快了 N 倍。
嗯,倒还真不是。
Oracle 的重点不是分析业务,也就说常说的 AP 业务,它主要是用来做交易的,也就是常说的 TP 业务。TP 数据库要采用行式存储。而 AP 数据库通常会采用列式存储。对于一个 100 列的数据表,某个运算只要用到其中两列。Oracle 采用行式存储时,基本上要把这 100 列都要读一遍,而采用列式存储的 AP 数据库,只要读 2 列就可以,这个读取量就会差了几十倍。这时候,快个 N 倍是很正常的,这也毫不稀奇,如果不能快个 N 倍那才是问题。
除了列存比行存外,还可能发生的是集群比单机,内存比外存等,就是比 Oracle 多用了数倍资源后跑出更快速度。总之,都是胜之不武。
所以,所谓比 Oracle 快 N 倍,很可能是这个意思,这不是假的,但并不值得夸耀。
事实上,Oracle 的优化器很强,如果不占列存和资源的便宜,很多专业 AP 数据库还不见得能跑得过 Oracle,特别基于 Hadoop 的的技术。

前面说了对数级算法的威力,万亿行的规模,对数一下后的计算量就剩几十了。其实还有反过来的情况,看起来不大的数据量,但运算量会大如天文数字。SPL 论坛上有个国家天文台的例子,数据只有 11 个 50 万行的表,总共不到 10G,但某分布式数据库动用了 100 个 CPU 算了 3.8 小时。因为这个运算是个乘法级的复杂度,总计算量是 10*50 万 *50 万 =2.5 万亿,3.8 小时能跑出来已经算是不错的了。
所以,考察大数据产品的性能,不能只是简单地看宣传语中说多大数据量能跑多快,那些说法都可能是真地,但并没什么意义。有了好算法,100T 可以秒查,没有好算法,10G 也可能 N 小时。
从这个意义上讲,考察大数据技术的性能,关键在于这东西是不是有提供与众不同的好算法,能把计算量降下去。

不过,在 SQL 体系下这些产品的差异,差能差到没边,好却好不到哪里去。因为 SQL 已经发展了几十年,成熟的优化算法全世界都知道,也很难有什么新东西,结果就是,那些不掌握这些算法的厂商真能差到没边,而掌握这些算法的厂商好却好不到哪里去,因为你能会我也能会。
但是,跳出 SQL 体系,就可能搞出新的算法了。上面说的天文台任务,其实也有算法能让乘法的一边对数一下,计算量大概 10*50 万 *log50 万 *2,能少 1 万倍。采用这个算法,esProc SPL 在 4 核笔记本上用了 2 分钟就跑出来了。
很遗憾,用 SQL 写不出这个算法,仅是正确描述计算逻辑就很费劲,写出代码就以 K 计了,数据库优化器也只能晕掉,老老实实执行就是 N 个小时。