除了数据库行业其他技术群体很多不知道HTAP的
时至今日还是有很多人迷信Hadoop，觉得大数据就是Hadoop。这是不正确的。也难怪这样，很多人OLTP和OLAP也分不清，何况HTAP。
Oracle是垂直方向实现
TiDB是水平方向实现
我个人认为这是两种流派，清蒸和红烧就看自己的主观口味了
OceanBase和Polardb的HTAP也是大同小异
需要的就是类似具体如何实现的中文化文档
仅为简单应用对比不涉及详细
因工作上涉及到了TIDB，那么就想既然用了就把他最大限度发挥出来。TiDB其中一大特性就是HTAP。出于对于HTAP的认可以及对于Hadoop的不喜欢，只要是能替换的我绝对支持。可能有人问我为什么不喜欢Hadoop，因为我学习以后觉得浪费了我的钱和时间。然后在工作中遇到的简单问题复杂化，硬是让企业走了很多弯路还解决不了问题，给所有人只是增加了麻烦。
Oracle走垂直路线
select * from v$inmemory_area;
查看内存区域大小
alter system set inmemory_size=800M scope=spfile;
这个需要重启实例，且要在CDB执行。
XXG@xxg> alter system set inmemory_max_populate_servers=2;
alter system set inmemory_max_populate_servers=2
*
第 1 行出现错误:
ORA-65040: 不允许从插接式数据库内部执行该操作
这个也要在CDB执行。
XXG@xxg> select * from v$inmemory_area;
POOL ALLOC_BYTES USED_BYTES
POPULATE_STATUS CON_ID
1MB POOL 586153984 0
DONE 8
64KB POOL 234881024 0
DONE 8
查询分配的内存。然后把表加载到内存中用列存。
数据加载到内存行列混存（在官网文档中有）
XXG@xxg> alter table big inmemory;
表已更改。
这个是有一个过程的。其实今天写这个像说明，第一次这种做转换都是要过程的。
做好了以后后续就实时的行列混存了。如果表大这里可以看到USED_BYTES会变化。
加载完成后。
XXG@xxg> set timing on;
XXG@xxg> set autotrace on;
XXG@xxg> select count(n) from big;
COUNT(N)
9000000
已用时间: 00: 00: 00.11
执行计划
Plan hash value: 3110421800
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 6 | 566 (7)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 6 | | |
| 2 | TABLE ACCESS INMEMORY FULL| BIG | 9000K| 51M| 566 (7)| 00:00:01 |
统计信息
213 recursive calls
0 db block gets
284 consistent gets
0 physical reads
0 redo size
551 bytes sent via SQLNet to client
387 bytes received via SQL Net from client
2 SQL*Net roundtrips to/from client
20 sorts (memory)
0 sorts (disk)
1 rows processed
XXG@xxg> select avg(n) from big;
AVG(N)
4222223.22
已用时间: 00: 00: 00.02
执行计划
Plan hash value: 3110421800
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 6 | 566 (7)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 6 | | |
| 2 | TABLE ACCESS INMEMORY FULL| BIG | 9000K| 51M| 566 (7)| 00:00:01 |
在千万级别（数据是900万）都在零点几秒就完成了。从执行计划看几乎就是读了几下内存而已。
TIDB走水平路线
也构造一定数量的表。并且安装的时候安装了tiflash组件。
数据从TiKV加载TiFlash中行列混存（在官网文档中没有直接写，在论坛中有实践文档）
相比较而言有些国产，可能没有论坛。只能靠交付和支持的人了。
mysql> ALTER TABLE xxg SET TIFLASH REPLICA 1;
Query OK, 0 rows affected (0.14 sec)
在没有加载tiflash时候，执行计划是这样的。task一列是tikv。
mysql> explain select * from xxg;
±----------------------±------------±----------±--------------±---------------------+
| id | estRows | task | access object | operator info |
±----------------------±------------±----------±--------------±---------------------+
| TableReader_5 | 11600116.00 | root | | data:TableFullScan_4 |
| └─TableFullScan_4 | 11600116.00 | cop[tikv] | table:xxg | keep order:false |
±----------------------±------------±----------±--------------±---------------------+
2 rows in set (0.00 sec)
在加载tiflash时候，执行计划是这样的。task一列是tiflash。
mysql> explain select * from xxg;
±-------------------------±------------±-------------±--------------±--------------------------------------+
| id | estRows | task | access object | operator info |
±-------------------------±------------±-------------±--------------±--------------------------------------+
| TableReader_12 | 11600116.00 | root | | MppVersion: 2, data:ExchangeSender_11 |
| └─ExchangeSender_11 | 11600116.00 | mpp[tiflash] | | ExchangeType: PassThrough |
| └─TableFullScan_10 | 11600116.00 | mpp[tiflash] | table:xxg | keep order:false |
±-------------------------±------------±-------------±--------------±--------------------------------------+
3 rows in set (0.01 sec)
注意过程，这也是今天这里要说的。
PROGRESS从0到1的过程就是观测加载的进度。
mysql> SELECT * FROM information_schema.tiflash_replica;
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| zhigate | request_api_log_bak | 233 | 1 | | 1 | 1 |
| zhigate | request_api_log | 112 | 1 | | 1 | 1 |
| xxg | xxg | 339 | 1 | | 0 | 0 |
| xxg | t | 173 | 1 | | 1 | 1 |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
4 rows in set (0.01 sec)
mysql> SELECT * FROM information_schema.tiflash_replica;
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| zhigate | request_api_log_bak | 233 | 1 | | 1 | 1 |
| zhigate | request_api_log | 112 | 1 | | 1 | 1 |
| xxg | xxg | 339 | 1 | | 0 | 0.2 |
| xxg | t | 173 | 1 | | 1 | 1 |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
4 rows in set (0.00 sec)
mysql> SELECT * FROM information_schema.tiflash_replica;
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| zhigate | request_api_log_bak | 233 | 1 | | 1 | 1 |
| zhigate | request_api_log | 112 | 1 | | 1 | 1 |
| xxg | xxg | 339 | 1 | | 0 | 0.6 |
| xxg | t | 173 | 1 | | 1 | 1 |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
4 rows in set (0.00 sec)
mysql> SELECT * FROM information_schema.tiflash_replica;
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
| zhigate | request_api_log_bak | 233 | 1 | | 1 | 1 |
| zhigate | request_api_log | 112 | 1 | | 1 | 1 |
| xxg | xxg | 339 | 1 | | 1 | 1 |
| xxg | t | 173 | 1 | | 1 | 1 |
±-------------±--------------------±---------±--------------±----------------±----------±---------+
4 rows in set (0.00 sec)
执行完毕后。查询结果是这样的。
mysql> SELECT * FROM information_schema.tiflash_replica where table_name='xxg';
±-------------±-----------±---------±--------------±----------------±----------±---------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
±-------------±-----------±---------±--------------±----------------±----------±---------+
| xxg | xxg | 339 | 1 | | 1 | 1 |
±-------------±-----------±---------±--------------±----------------±----------±---------+
1 row in set (0.01 sec)
再看效果。
mysql> select count() from xxg;
±---------+
| count() |
±---------+
| 11600116 |
±---------+
1 row in set (0.11 sec)
mysql> select sum(id) from xxg;
±---------------+
| sum(id) |
±---------------+
| 67281351406786 |
±---------------+
1 row in set (0.08 sec)
也同样是零点几秒。
观点
无论怎么做，大方向都是要列存的，水平的内存和垂直的内存都是内存。省是省不掉的。至于细节的向量化以及并行今天不讨论。主要说明。硬件代价是必须付出的。