GPU数据库的过去与未来

GPU数据库是什么？

GPU数据库是近十年来数据库产品的一个分支，它解决了大量大型数据密集型应用用户所面临的关键问题。尽管GPU数据库经常出现在各种新闻报道中，但业界对GPU数据库的定义、GPU数据库的发展历史和GPU数据库能够解决的基本应用需求仍知之甚少。基于这一点，本文试图回答这些问题，讨论GPU数据库的发展现状和未来的展望。

定义GPU数据库系统

GPU数据库是一个频繁使用的术语，但是它的本质是指“数据库管理系统”，它使用GPU设备来处理某些数据处理功能，这一功能可以涵盖广泛的范围，比如从特定函数的处理到整个查询引擎(或其他数据库组件)。由于资料库管理系统的特点之一就是允许使用者加入定制的功能，以扩展资料库的功能，所以有不同的场景来了解GPU如何访问资料库系统，其中包括：场景(1)数据库管理系统本身并不提供任何GPU设备的管理和使用，但是数据库管理系统提供了扩展功能的功能，使用户能够使用GPU设备定制功能，从而完成某些操作；(2)直接在GPU设备上实现一些内置功能，而且数据库管理系统可以直接管理基础GPU设备，但是它可以允许更高级别的应用或者其他扩展功能使用，或者访问GPU设备。

GPU数据库概念定义包含以上两种情况：只要数据库系统的某项功能使用GPU设备时，这个数据库系统就可以称为GPU数据库。大多数GPU数据库形式(目前的主流形式)是使用GPU设备来执行SQL查询，但是对不同产品来说，一个完全SQL查询涉及到的多个操作，将什么放在GPU上执行还不确定；这样的任务调度方法就可以在查询运行的动态中全部完成。值得注意的是，理论上GPU并不局限于执行查询处理，许多学术研究工作也表明了在GPU上执行key/value查询和事务处理的可能性。所以，如果需要的话，我们应该区分主流产品的GPU数据库的可能性和具体形式。从工业发展现状来看，本文讨论的GPU数据库都涉及使用GPU来加快查询处理的数据库系统。

GPU数据库发展史

自2003至今，GPU数据库这一产品形态或数据库形式已走过18年！众所周知，最早的学术研究是SIGMOD的2003年论文：“HardwareAccelerationforSpatialSelectionsandJoins”。这一研究是在通用GPU诞生之前，首先对如何利用GPU硬件的rendering和searching能力，来解决复杂的几何算法的性能问题。在NvidiaCUDA生态系统之前，本文中描述的技术方案属于对复杂数据库操作与底层硬件相匹配的早期探索的核心问题。自2010年以来，GPU数据库随着各种新应用的出现逐渐增长。在GPU数据库方面，学术界已经开发了许多原型系统，如GDB、GPUDB、Ocelot等，主要研究各种数据库并行算法、系统结构和各种优化技术。工业部门的GPU数据库有两种类型，一种是从PostgreSQL等传统开放源码CPU数据库中进行扩展的。比如日本的HeteroDB和英国的Brytlyt数据库；另外一个新的数据库从零开始为GPU开发，比如美国的Kinetica和OmniSci。RateupDB，以及以色列的SQream等等。

工业与GPU数据库

随着人类社会进入所谓的数据驱动时代，各种新的应用需求层出不穷，其根本驱动原因是各种新的经济模式(如手机)，如典型的移动计算带来的各种应用需求。这些需求往往超过了传统关系数据库提供和优化的数据处理能力，需要新的数据库。我们总结了以下三个需求:

对实时业务价值的需求:这是最重要的业务需求，其目标是利用各种计算分析在各种及时更新的数据集中获取瞬时业务价值。典型的场景是实时车辆位置管理带来的一系列业务应用，典型的代表是Uber内部使用的AresDB方案和USPS中使用的Kinetica方案。对于一家运营数百万客车的旅游服务公司来说，实时路线规划和偏航率分析不仅可以降低运营成本，改善客户体验，而且是实时恶意行为检测和犯罪预警的重要手段。

对极端计算能力的需求

目前对非结构化数据有爆炸性的分析需求，这些分析必须依靠极其强大的计算能力，尤其是这些数据的大规模增长与CPU有限计算能力的矛盾，使得很多分析无法有效进行。典型的例子包括图形数据分析、DNA序列分析、空间数据分析、3D结构分析等。虽然传统数据库在处理这些数据时存在性能问题，如OracleSpatialandGraph，但各行业的用户仍然首选一个数据库平台来进行这些分析，因为用户最需要数据库的简单接口来分离上层应用和底层系统。

对综合数据平台的需求:随着实时分析、智能分析和扩展分析的重要性日益突出，传统企业内部多套数据库集成方案越来越不能满足核心需求，尤其是多套数据库之间的业务延迟、协调管理和维护费用随着业务规模的增长越来越严重。例如，从数据库中提取大量数据并发送到智能分析平台进行智能分析，严重违背了用户对实时智能分析的需求。传统的数据库系统试图通过添加各种扩展来解决这些问题，比如TeradataVantage。然而，由于CPU的计算能力有限，许多复杂的分析只能使用其他非数据库内置的模块，如TensorFlow。由于这些模块本身不受数据库系统的管理，存在各种数据格式转换和资源调度冲突。