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

数据运维 2023-12-29 醒在深海的猫手机阅读

我们经常听到大数据产品宣传自己性能好，“万亿秒查”是个常见的说法，大概意思就是上万亿行数据中找出查出满足条件的数据，可以秒级返回。

这是真地吗？

看过“1T 数据到底有多大”那期的同学大概都会觉得不可能。万亿行数据，得有几十上百 T 了，想秒级处理，岂不是得要几万几十万块硬盘，这不太现实。

其实不然，秒查并不一定意味着全遍历。如果是用唯一标识号去查找（比如电话号码，不过也没有万亿个），建好索引后的计算量并不是很大，读取和比较次数大概是 40 次左右，现代计算机在 1 秒内完成这个计算量毫无压力，甚至还能有不少并发。这种定点查找任务的计算复杂度是对数级别的，数据量从 100 万行涨到 1 万亿行，查找计算量仅仅涨到 2 倍而已。只要存得下，几乎所有数据库都有这个本事，这毫不稀奇。当然，建索引会很慢，但那是另一回事了。

如果是需要遍历才能完成的运算呢？比如计算某个列的合计，索引在这里没有用了。

嗯，这件事，万亿行上想秒查是不太现实了，但针对 TB 级数据却是可能的。如果这些数据总共有 100 列，统计一列时只要读 1% 的数据量，可能也就只有 10G，这样有 10 块硬盘就能在数秒内扫描一遍了，这点配置对于现代服务器集群而言是个小菜，再大 10 倍也不是问题。

嗯，倒还真不是。

Oracle 的重点不是分析业务，也就说常说的 AP 业务，它主要是用来做交易的，也就是常说的 TP 业务。TP 数据库要采用行式存储。而 AP 数据库通常会采用列式存储。对于一个 100 列的数据表，某个运算只要用到其中两列。Oracle 采用行式存储时，基本上要把这 100 列都要读一遍，而采用列式存储的 AP 数据库，只要读 2 列就可以，这个读取量就会差了几十倍。这时候，快个 N 倍是很正常的，这也毫不稀奇，如果不能快个 N 倍那才是问题。

除了列存比行存外，还可能发生的是集群比单机，内存比外存等，就是比 Oracle 多用了数倍资源后跑出更快速度。总之，都是胜之不武。

所以，所谓比 Oracle 快 N 倍，很可能是这个意思，这不是假的，但并不值得夸耀。

所以，考察大数据产品的性能，不能只是简单地看宣传语中说多大数据量能跑多快，那些说法都可能是真地，但并没什么意义。有了好算法，100T 可以秒查，没有好算法，10G 也可能 N 小时。

但是，跳出 SQL 体系，就可能搞出新的算法了。上面说的天文台任务，其实也有算法能让乘法的一边对数一下，计算量大概 10 * 50万 * log50万 * 2，能少 1 万倍。采用这个算法，esProc SPL 在 4 核笔记本上用了 2 分钟就跑出来了。