看看关系型数据库是怎么吊打Hadoop的

    题目有点过分是不是？大家看完文章再看看是不是过分。不少公司OLTP的数据库都是关系型数据库，这些数据库在OLAP的场景上表现一般。所以在不少架构中，会看到使用ETL的方式将数据库送到Hadoop中，使用其分布式存储和分布式计算的特点来进行分析。但是ETL很难解决实时性问题，而且如果上游删除数据，ETL是干瞪眼没有办法解决，只能承担数据的不一致。还有就是严重依赖上游时间戳。有人可能会问，存在的就是合理的，这不是也在用着吗？对，但是能用和用的爽不完全划等号。

    现在随着实时数仓的兴起于落地，不少企业使用一些列式数据库来进行替换。主要有ClickHouse和Startrocks等。其实这些数据库之所以被选择是因为在分析场景上性能优秀。而其优秀的原理，我个人认为主要是因为他是列式数据库。

    换句话时候，哪个数据库列式都差不多。MySQL PostgreSQL还有Oracle都一样（或者说差不多）。而实际上这三个数据库真的有。

    这里仅仅以Oracle为例，下面这里有三个表，都是1亿数量级的规模。可以看到在这个量级下，Oracle的聚合分析，几乎都在100毫秒以下。硬件配置（操作系统层面识别到的）：22C  220G内存。使用了Oracle的In-Memory。

   

  在单表聚合上什么列数数据库都没有问题。这个其实是列式存储的优势。虽然Oracle也支持了向量数据库，但是这里仅仅用到的是向量执行，算不上向量数据库。30毫秒出结果。

  其实即使在列式数据库上，如果进行多表关联。ClickHouse和Startrocks上多表关联会有很大的性能衰减。所以看看在Oracle上效果如何？

  首先2表关联（两个1亿的表，全表关联聚合）。现实工作中除非故意，理论上不会这样。 这种极端情况下，看到执行耗时2.5秒。确实衰减了，而且不少。但是也勉强说得过去。毕竟是极端情况。

  

 然后3表关联（3个1亿的表，全表关联聚合）。 这种要极力避免，看到执行耗时4秒。看来是线性的变慢了。当然了这种也是有其他解决方案的。

 

  不过毕竟有几个业务表上亿的数据的企业不多，而且也不会这样不带条件查询。如果带上条件那么1000万的2表关联结果是240毫秒。

  

  如果带上条件那么1000万的3表关联结果是390毫秒。

  

  以上一切的执行都是在OLTP数据库上直接执行的，只是因为用到了数据库自带的列式而已。

  这中间没有ETL，不需要CDC技术栈，不需要依赖时间戳。不需要数据加工，不需要数据清洗，也不需要制作成大宽表。以上这些不需要的总节约时间，单位都是以小时计的。更不用说这个SQL的执行时间，MapReduce的任务还没分解呢，我这里已经出结果了。

  Hadoop在大家都是烂硬件的时代，依靠多机器全表IO打赢了单机器的全表IO（如果单机是用索引的话，那连20年前的单机也打不赢）。而对于现在HTAP或者说超融合的多模数据库来说，比如MySQL的HeatWave等列式存储的优势（这里包括MySQL Oracle PostgreSQL TiDB和OceanBase Polardb等等，不一一列举了），使得聚合运算场景上也是可以轻松分析。列数存储的分析对行式存储的分析优势明显，何况还少了巨大的中间环节的过程。有点降维打击的意思。

  之所以不少系统还是用OLTP+OLAP的原因，主要是在线的数据库本身不支持列式存储，所以必须要有CDC传输的过程。或者担心OLAP的场景乱用影响OLTP，那么就把数据复制一份，实时同步，单独运行OLAP。