我们经常听到大数据产品宣传自己性能好，“万亿秒查”是个常见的说法，大概意思就是上万亿行数据中找出查出满足条件的数据，可以秒级返回。
这是真地吗？
看过“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 个小时。 本文来源
GitHub：https://github.com/SPLWare/esProc
重磅！开源SPL交流群成立了
简单好用的SPL开源啦！
为了给感兴趣的技术人员提供一个相互交流的平台，
特地开通了交流群（群完全免费，不广告不卖课）
需要进群的朋友，可长按扫描下方二维码
本文感兴趣的朋友，请到阅读原文去收藏 ^_^
