近数据处理(NDP)，为GaussDB(for MySQL)性能提升“加冕”

在上一篇文章《首席科学家为您揭秘：我们介绍了GaussDB(for MySQL)的体系架构，这篇文章我们将重点介绍GaussDB(for MySQL)如何将查询处理卸载到存储层，我们将这一特性称之为近数据处理（Near Data Processing），简称NDP。

NDP出现的契机

在计算节点实例上执行查询操作首先需要将数据页面加载到InnoDB缓冲池(buffer pool)。相对传统数据库使用本地存储，云数据库需要通过网络获取数据，因此从存储节点读取页面数据的延迟要高得多。相比社区版MySQL，GaussDB(for MySQL)支持并行查询，可通过多线程并行将数据读取到缓冲池中，但当表数据量较大(包含数百万甚至更多的数据行)，分析查询需要扫描大量数据时，将所需数据全部加载到缓冲池中，IO成本将变得非常高。因此，我们需要一种更优的方法来解决此问题。

我们的解决方案是基于GaussDB(for MySQL) 计算节点与存储节点之间的紧密集成，将部分查询处理操作下推至靠近数据的分布式存储系统，数据库术语中称为算子下推。通过这种方式，我们可以利用多存储节点的总带宽。在云环境中，存储系统包含数百节点，我们希望充分利用存储系统的可扩展性，同时避免网络成为性能瓶颈点。NDP允许部分查询处理以大规模并行的方式在存储节点执行，并显著的减少网络IO。

NDP有诸多好处，包括：

• 利用多租户大规模分布式云存储系统，在多节点并行处理数据
• 显著减少网络IO，只返回满足WHERE条件的行(过滤)和查询涉及的列(投影)或聚合操作的结果，而不是将完整的数据页面从存储节点返回至计算节点
• 避免大数量扫描导致经常访问的数据页面从缓存池中移除

那么存储层是如何处理的呢？

算子下推通常适用于全表扫描、索引扫描、范围查询等场景。WHERE条件可下推至存储层，当前支持的数据类型包括：

• 数值类型(numeric, integer, float, double)
• 时间类型(date, time, timestamp)
• 字符串类型(char, varchar)等

算子下推可以与计算节点的并行查询完美结合，从概念上讲，一个查询首先在计算层(垂直扩展)拆分为多个worker线程并行处理，每个worker线程均可触