PingCAP CTO 黄东旭：我眼中的未来数据库技术趋势
|
说完了存储层，接下来说一说执行器。TiDB 在接下来会做一个很重要的工作，就是全面地 leverage SIMD 的计算。我先简单科普一下 SIMD 是什么。
图 15 SIMD 原理举例(1/2) 如图 15，在做一些聚合的时候，有这样一个函数，我要去做一个求和。正常人写程序，他就是一个 for 循环，做累加。但是在一个数据库里面，如果有一百亿条数据做聚合，每一次执行这条操作的时候，CPU 的这个指令是一次一次的执行，数据量特别大或者扫描的行数特别多的时候，就会很明显的感受到这个差别。
图 16 SIMD 原理举例(2/2) 现代的 CPU 会支持一些批量的指令，比如像 _mm_add_epi32，可以一次通过一个32 位字长对齐的命令，批量的操作 4 个累加。看上去只是省了几个 CPU 的指令，但如果是在一个大数据量的情况下，基本上能得到 4 倍速度的提升。 顺便说一句，有一个很大的趋势是 I/O 已经不是瓶颈了，大家一定要记住我这句话。再过几年，如果想去买一块机械磁盘，除了在那种冷备的业务场景以外，我相信大家可能都要去定制一块机械磁盘了。未来一定 I/O 不会是瓶颈，那瓶颈会是什么?CPU。我们怎么去用新的硬件，去尽可能的把计算效率提升，这个才是未来我觉得数据库发展的重点。比如说我怎么在数据库里 leverage GPU 的计算能力，因为如果 GPU 用的好，其实可以很大程度上减少计算的开销。所以，如果在单机 I/O 这些都不是问题的话，下一个最大问题就是怎么做好分布式，这也是为什么我们一开始就选择了一条看上去更加困难的路：我要去做一个 Share-nothing 的数据库，并不是像 Aurora 底下共享一个存储。 5. Dynamic Data placement
图 17 Dynamic Data placement (1/2) 分库分表方案与 TiDB 对比 在今天大家其实看不到未来十年数据增长是怎样的，回想十年前大家能想到现在我们的数据量有这么大吗?不可能的。所以新的架构或者新的数据库，一定要去面向我们未知的 Scale 做设计。比如大家想象现在有业务 100T 的数据，目前看可能还挺大的，但是有没有办法设计一套方案去解决 1P、2P 这样数据量的架构?在海量的数据量下，怎么把数据很灵活的分片是一个很大的学问。 为什么分库分表在对比 TiDB 的时候，我们会觉得分库分表是上一代的方案。这个也很好理解，核心的原因是分库分表的 Router 是静态的。如果出现分片不均衡，比如业务可能按照 User ID 分表，但是发现某一地方/某一部分的 User ID 特别多，导致数据不均衡了，这时 TiDB 的架构有什么优势呢?就是 TiDB 彻底把分片这个事情，从数据库里隔离了出来，放到了另外一个模块里。分片应该是根据业务的负载、根据数据的实时运行状态，来决定这个数据应该放在哪儿。这是传统的静态分片不能相比的，不管传统的用一致性哈希，还是用最简单的对机器数取模的方式去分片(都是不能比的)。 在这个架构下，甚至未来我们还能让 AI 来帮忙。把分片操作放到 PD 里面，它就像一个 DBA 一样，甚至预测 Workload 给出数据分布操作。比如课程报名数据库系统，系统发现可能明天会是报名高峰，就事先把数据给切分好，放到更好的机器上。这在传统方案下是都需要人肉操作，其实这些事情都应该是自动化的。
图 18 Dynamic Data placement (2/2) Dynamic Data placement 好处首先是让事情变得更 flexible ，对业务能实时感知和响应。另外还有一点，为什么我们有了 Dynamic Placement 的策略，还要去做 Table Partition(今天上午申砾也提到了)?Table Partition 在背后实现其实挺简单的。相当于业务这边已经告诉我们数据应该怎么分片比较好，我们还可以做更多针对性的优化。这个 Partition 指的是逻辑上的 Partition ，是可能根据你的业务相关的，比如说我这张表，就是存着 2018 年的数据，虽然我在底下还是 TiDB 这边，通过 PD 去调度，但是我知道你 Drop 这个 Table 的时候，一定是 Drop 这些数据，所以这样会更好，而且更加符合用户的直觉。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
