当前位置：首页 > news >正文

从Oracle和TiDB的HTAP说起

news 来源：原创 2025/8/22 14:36:24

除了数据库行业其他技术群体很多不知道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 SQLNet 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

TIDB走水平路线

也构造一定数量的表。并且安装的时候安装了tiflash组件。

数据从TiKV加载TiFlash中行列混存（在官网文档中没有直接写，在论坛中有实践文档）
相比较而言有些国产，可能没有论坛。只能靠交付和支持的人了。

mysql> ALTER TABLE xxg SET TIFLASH REPLICA 1;
Query OK, 0 rows affected (0.14 sec)

在没有加载tiflash时候，执行计划是这样的。task一列是tikv。

注意过程，这也是今天这里要说的。

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)

也同样是零点几秒。

观点

无论怎么做，大方向都是要列存的，水平的内存和垂直的内存都是内存。省是省不掉的。至于细节的向量化以及并行今天不讨论。主要说明。硬件代价是必须付出的。