CN113312415A - 用于数据库操作的近存储器加速 - Google Patents

Abstract

尽管增加了存储器容量和CPU计算能力，但是由于数据量和应用需求的不断增长，存储器性能仍然是内存数据库管理系统的瓶颈。由于数据工作负载的规模已经超过了传统的CPU缓存和存储器带宽，因此可以改善从存储器到计算单元的数据移动，从而提高内存数据库方案中的性能。近存储器数据库加速器框架通过或向近存储器计算引擎分流数据密集型数据库操作。数据库加速器的系统架构可以包括数据库加速器软件模块/驱动器和带有数据库加速器引擎的存储器模块。可以提供应用编程接口(API)以支持数据库加速器功能。数据库加速器的存储器是CPU直接可访问的。

Description

用于数据库操作的近存储器加速

对相关申请的交叉引用

本申请要求于2020年2月27日提交的美国临时申请No.62/982,683的权益，在此通过引用将其并入本文。

技术领域

本公开涉及用于数据库操作的近存储器加速。

背景技术

尽管存储器容量和CPU计算能力有所提高，但是数据处理工作负载规模的不断扩大仍在继续挑战内存数据库管理系统的性能。因此，存在改进的空间。

发明内容

提供本发明内容以简化形式介绍一些概念，这些概念将在下面的详细描述中进一步描述。本发明内容既不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。

实施例包括一种方法，所述方法包括：在内存数据库管理系统环境中，接收对源数据中表示的多个值执行数据库操作的请求，其中，源数据存储在近存储器数据库加速器的设备存储器中；将数据库操作分流到近存储器数据库加速器；以及从近存储器数据库加速器接收数据库操作的结果可用的指示。

另一实施例包括一种系统，包括：一个或多个处理单元；一个或多个处理单元直接可访问的主存储器或扩展存储器；以及近存储器数据库加速器驱动器，被配置为接收对存储在近存储器数据库加速器的设备存储器中的源数据执行数据库操作的请求，近存储器数据库加速器包括与一个或多个处理单元分开的至少一个数据库加速器引擎，将数据库操作分流到近存储器数据库加速器，以由与一个或多个处理单元分开的至少一个数据库加速器引擎执行，以及从近存储器数据库加速器接收数据库操作的结果可用的指示；其中，主存储器或扩展存储器包括近存储器数据库加速器的设备存储器。

另一实施例包括一个或多个计算机可读介质，包括计算机可执行指令，所述计算机可执行指令在被执行时使计算系统执行方法，所述方法包括：从内存数据库管理系统接收应用编程接口(API)调用，请求将数据库操作分流到近存储器数据库加速器，其中，对根据位打包压缩格式压缩的数据库表的内存列执行数据库操作，API调用指定位数参数；响应于API调用，向近存储器数据库加速器发送请求，其中，发送包括：中继位数参数，并且近存储器数据库加速器以位数参数执行数据库操作；从近存储器数据库加速器接收数据库操作已经完成的指示；以及通知内存数据库管理系统数据库操作已经完成。

根据以下参照附图进行的详细描述，前述和其他目的、特征和优点将变得更加明显。

附图说明

图1是可以实现用于数据库操作的近存储器加速的示例硬件环境的框图。

图2是可以实现用于数据库操作的近存储器加速的示例存储器模块硬件环境的框图。

图3是可以实现用于数据库操作的近存储器加速的示例扩展存储系统环境的框图。

图4是实现用于数据库操作的近存储器加速的示例性系统架构的框图。

图5是实现用于数据库操作的近存储器加速的示例系统的框图。

图6是在存储器环境中用于数据库操作的近存储器加速的示例方法的流程图。

图7是在存储器环境中用于数据库操作的近存储器加速的示例更详细方法的流程图。

图8是在存储器环境中实现用于数据库操作的近存储器加速的示例操作序列的序列图。

图9是示出执行与本文的技术一起使用的数据库操作的请求的示例内容的框图。

图10是示出用于测量近存储器数据库加速器的性能的所提出的系统的架构的框图。

图11是支持用于数据库操作的近存储器加速的微架构的框图。

图12是内存数据库中的示例扫描操作的框图。

图13是行向量输出的示例调整大小处理的框图。

图14是在查找数据库操作中的位打包(bit-packed)压缩的示例的框图。

图15是在稀疏压缩情况中的查找数据库操作的示例方法的流程图。

图16是示出间接压缩情况中的查找数据库操作的框图。

图17是在间接压缩情况中的查找数据库操作的示例方法的流程图。

图18是用于在内存数据库管理系统中的数据库分量的位打包压缩中使用的数据结构的框图。

图19是位打包(即，压缩的)ValueID数组的框图。

图20是示出不同列存储压缩情况的框图。

图21是在内存数据库管理系统中使用的稀疏压缩的示例方法的流程图。

图22是在内存数据库管理系统中使用的稀疏解压缩的示例方法的流程图。

图23是在内存数据库管理系统中使用的间接压缩技术的示例的框图。

图24是在内存数据库管理系统中使用的间接压缩技术的示例的另一框图。

图25是在内存数据库管理系统中使用的间接压缩方法的流程图。

图26是在内存数据库管理系统中使用的间接解压缩方法的流程图。

图27是在内存数据库管理系统中使用的间接压缩中的集群字典处理的框图。

图28是显示通过增加扫描而导致的在线交易处理(OLTP)吞吐量变化的条形图。

图29是用于技术评估的系统设置的系统图。

图30是示出通过数据库加速的在线交易处理吞吐量增益的图。

图31是示出具有/不具有TPCC的扫描吞吐量的图。

图32是示出一般数据库加速器优点的框图。

图33是可以实现所描述的实施例的示例计算系统的框图。

图34是可以与本文描述的技术结合使用的示例性云计算环境的框图。

具体实施方式

示例1-概述

低成本、大容量DRAM加速了内存数据库管理系统(IMDBMS)的市场。能够在单个系统中同时运行在线事务处理(OLTP)和在线分析处理(OLAP)应用的最新的IMDBMS架构消除了数据冗余并提供了更高的性能和效率，而总拥有成本(TCO)却更少。然而，随着数据量和应用需求的不断增长，存储器性能已成为IMDBMS的主要性能瓶颈。

对OLTP/OLAP应用的研究表明，性能可能受到昂贵的数据密集型操作(例如表扫描和OLAP工作负载的聚合)的约束。这样的数据密集型操作很少有数据可重复使用以进行进一步的计算，但是在许多情况下会消耗50％以上的CPU资源和几乎所有的存储器带宽。其他任务关键型工作负载遭受缓存冲突(或缓存颠簸)和存储器带宽瓶颈的困扰。因此，有机会更好地处理从存储器到计算单元的数据移动。

改善IMDBMS中此类数据移动的一种方法是在存储器设备中处理此类数据密集型操作。代替将所有数据传送到计算单元，将过滤的结果转发到下一处理步骤可以使开销最小化。近存储计算试图通过最小化存储节点和处理节点(例如CPU)之间的数据传输开销来加速数据密集型操作。

然而，近存储计算无法为IMDBMS提供字节寻址能力并显着降低延迟。先前使用FPGA和GPGPU技术加速数据库操作的工作表明，计算密集型操作的性能提高了十倍。然而，由于数据移动开销，此类方法在数据密集型操作中显示出较小的增益。甚至Hybrid CPU-FPGA方法也涉及从主机存储器到加速器计算单元的数据移动，这具有很高的存储器带宽开销。

像UPMEM这样的内存中处理(Processing-In-Memory，PIM)方法是近存储器计算的高级概念，但它们仍处于早期阶段。此外，数据被重新格式化以利用处理单元，因此现有数据结构不被直接重用。

近存储器数据库加速器(DBA)可以将IMDBMS的数据密集型操作分流(offload)到存储器设备。通过如DIMM的存储器设备内DRAM附近放置简单的算术单元，可以：1)节省用于数据密集型操作的CPU周期，2)避免线程间的缓存颠簸，3)减少主机存储器瓶颈。如本文所述，可以使用带有附接的DIMM的FPGA来实现概念验证(PoC)系统。DBA内核被设计为完全利用内部存储器带宽以SIMD方式执行并行比较。评估表明，当分流数据密集型操作时，近存储器数据库加速器的OLTP工作负载性能提高了两倍以上。可以克服各种障碍以在存储器设备中体现该方法，从而使该技术得到广泛采用。

如本文所述，数据库操作可以被分流到近存储器数据库加速器。结果，可以减少CPU到存储器数据路径的带宽以进行其他处理，从而在内存数据库管理系统环境中总体上获得更好的性能。

示例2–示例数据库加速器硬件环境

数据库加速器硬件环境可以支持本文所述的数据库操作的近存储器加速。图1是示例数据库加速器硬件环境100的框图，可用于为本文任何示例中的数据库操作实现近存储器加速。在示例中，计算系统110包括中央处理节点120和一个或多个数据库加速器设备130。

中央处理节点120可以通过存储器通信信道127与数据库加速器设备130通信，诸如总线、CPU到存储器的互连、可字节寻址存储器接口、PCI、PCIe、DDR存储器接口(例如，DDR4)、计算快速链接(CXL)存储器接口、Gen-Z和OpenCAPI等。如本文所述，不同类型的通信信道是可能的，包括那些支持存储器映射I/O的通信信道。如本文所述，存储器通信信道127可以用于与一个或多个数据库加速器引擎170通信并且直接访问存储器180A或180B(例如，其中这种访问绕过数据库加速器引擎170)。尽管未示出，但是还可以包括控制器(例如，从中央处理节点120的角度来看，无论是在数据库加速器引擎170的前面还是后面)。

在该示例中，数据库加速器设备130采取包括一个或多个数据库加速器引擎170和存储器180A的硬件单元(例如，存储器设备)的形式。如图所示，数据库加速器引擎170可以经由存储器通信信道127通信回中央处理节点120，存储器通信信道127可以是中央处理节点120用于访问存储器180A或180B的常用信道。当经由通信信道127访问存储器180AS或180B时，中央处理节点120可以绕过数据库加速器引擎170。在实践中，如本文所述，只要数据库引擎170在存储器180B附近，存储器180B就可以位于数据库加速器设备的外部。

除了数据库加速器设备130上的存储器之外，中央处理节点120还可以与数据库加速器设备130外部和中央处理节点120外部的附接存储器模块接口。

示例3–示例中央处理节点

在本文的任何示例中，数据库应用的执行可以由中央处理节点执行。这样的中央处理节点可以包括一个或多个中央处理单元或被配置为执行软件的其他硬件。在实践中，中央处理节点可以包括附加硬件，诸如协处理器、图形处理器等。

为了方便，中央处理节点有时在本文中简称为“CPU”。

示例4–示例近存储器项

在本文的任何示例中，当将一个项(例如，数据库加速器引擎、数据库加速器内核等)描述为近存储器时，在物理或数据路径(例如，总线)的意义上，这样的项接近存储器(例如，体现存储器的存储器模块)。例如，这样的项可以在同一电路板、硬件单元、设备上，与由中央处理节点直接使用的存储器共驻留或接近(例如，与中央处理节点接近)，不管是主存储器还是扩展存储器等。

示例5–示例直接可访问存储器

在本文的任何示例中，数据库加速器所接近的存储器可以作为可由中央处理节点直接可访问的存储器来操作，并且可以是本文所述的内存数据库管理系统的主内存数据库存储的至少一部分。中央处理节点和数据库加速器引擎都可以访问近存储器加速器系统的存储器(例如，经由存储器控制器)。

经历分流数据库操作的数据(例如，内存数据库管理系统的列式主存储)可以在接收分流请求之前被放置在近存储器数据库加速器系统的直接可访问存储器中(例如，通过如本文所述的内存数据库配置)。

实践中，直接可访问存储器可以位于主存储器、扩展存储器等中并且包括其至少一部分。中央处理节点可以绕过数据库加速器直接(例如，使用主存储器总线或扩展存储器硬件)访问这种存储器。

在实践中，这样的安排可以提供以下优点：避免将数据移动到靠近主中央处理节点的位置(例如，因为数据已经在那里)和/或使中央处理节点不必访问存储用于数据库的操作源数据的存储器。结果，中央处理节点处的处理器-存储器带宽交互可以用于其他操作，而不是分流数据库操作，从而导致总体性能提高，如本文所述。

直接可访问存储器与为中央处理节点无法寻址的硬件加速而保留或专用的存储器有所区别。在这种情况下，硬件加速器可以是近存储器，但是不在中央处理器可以直接访问的存储器附近。

因此，“近存储器”数据库加速器可以采取数据库加速器的形式，其中实现硬件位于源数据所在的存储器附近，其中这种存储器是中央处理节点直接可访问的存储器。以这种方式，数据可以已经位于存储器中，并且中央处理节点和存储器之间的数据路径的带宽可以被释放并用于其他处理任务，而不是分流数据库操作所消耗。

例如，诸如数据库加速器引擎的项可以是中央处理节点的存储器对等方，因为数据库加速器引擎和中央处理节点都能够访问存储器；中央处理节点可以绕过数据库加速器引擎以直接访问存储器，数据库加速器引擎可以访问相同的存储器而不会消耗中央处理节点的资源。

由于存储器可以由数据库加速器和中央处理节点二者写入和读取，因此在执行分流数据库操作期间可能会发生数据一致性和/或读取/写入冲突。因此，可以通过在查询的生命周期(包括执行分流数据库操作)期间使主存储区在概念上保持只读状态的锁定机制来避免这种情况。

示例6–示例特定数据库加速器硬件环境

在图1的更具体的示例中，数据库加速器硬件环境可以包括存储器模块形式的数据库加速器(即，数据库加速器存储器模块)。图2是示例存储器模块硬件环境200的框图，其中在本文的任何示例中，用于数据库操作的近存储器加速可用于实现用于数据库操作的近存储器加速。在该示例中，计算系统210包括中央处理节点220和一个或多个数据库加速器设备230，采取存储器模块的形式。

中央处理节点220可以采用存储器控制器225，以通过存储器通信信道227与存储器模块230进行通信。不同类型的存储器通信信道是可能的。例如，可以使用PCI、PCIe、DDR存储器接口(例如DDR4)或其他总线标准；可以支持存储器映射I/O，如本文所述。

在示例中，数据库加速器设备采取包括一个或多个数据库加速器引擎270和存储器280的存储器模块230(例如，存储器设备)的形式。存储器模块230可以完全用作普通存储器设备，但是也具有执行本文所述的分流数据库操作的能力。如图所示，数据库加速器引擎270可以经由存储器通信信道227通信回中央处理节点220，该存储器通信信道227可以是中央处理节点220用于直接访问存储器280的相同信道，并且中央处理节点220可以在经由存储器通信信道227访问存储器280时绕过数据库加速器引擎270。在实践中，数据库加速器引擎270可以与存储器280放置在同一设备(例如，电路板)上。

除了存储器模块上的存储器，中央处理节点220还可以与存储器模块230和中央处理节点220外部的附加存储器模块接口。

除了数据库加速器存储器模块230上的存储器280之外，中央处理节点220还可以与不具有数据库引擎的附加存储器模块或其他存储器接口。

示例7–示例特定数据库加速器硬件环境

在图1的更具体的示例中，数据库加速器硬件环境可以在扩展存储器环境中包括数据库加速器。图3是示例扩展存储系统环境300的框图，其中可以在本文的任何示例中实现用于数据库操作的近存储器加速。在该示例中，计算系统310包括中央处理节点320和一个或多个数据库加速器设备330。不同于图2的系统，从中央处理节点320的角度来看，存储器控制器350在数据库加速器引擎370的后面。

中央处理节点320可以在存储器通信信道327上与数据库加速器设备330进行通信。例如，PCIe、CXL(例如，结合PCIe)或其他CPU存储器互连标准可以用于与扩展存储器系统340通信，然后与访问存储模块380A-380N的存储控制器350接口。可以使用缓存一致性接口。

在示例中，数据库加速器设备330采取包括扩展存储器系统340的硬件单元(例如，诸如控制器的设备)的形式，该扩展存储器系统340包括一个或多个数据库加速器引擎370。在实践中，数据库加速器引擎可以被实现为具有专用数据库加速器引擎硬件(例如，片上系统等)的控制器或虚拟数据库加速器引擎，其中数据库加速器引擎逻辑被编程到控制器。

如图所示，数据库加速器引擎370可以经由存储器通信信道327通信回中央处理节点320，可以是中央处理节点320直接访问存储器380A-N所使用的相同信道，并且当经由存储器通信信道327访问存储器380A-N时，中央处理节点320可以绕过数据库加速器引擎370。在实践中，数据库加速器引擎370可以被放置在与扩展存储器系统340和存储控制器350相同的设备(例如，电路板上)上。

除了经由扩展存储器系统340访问的存储器380A-N之外，中央处理节点320还可以与经由扩展存储器系统340和中央处理节点320访问的那些外部的附加存储器模块接口。

示例8–示例近存储器数据库加速器系统架构

图4是实现可以在本文的任何示例中使用的数据库操作的近存储器加速的示例系统架构400的框图。在示例中，计算系统410包括(例如，在数据库加速器硬件环境中实现的)近存储器数据库加速器系统460和数据库加速器驱动器427。在示例中，有时近存储器数据库加速器系统460被称为“主机”是因为它可以接收和处理来自数据库应用440的分流请求(例如，通过数据库加速器驱动器427)。

在示例中，近存储器数据库加速器系统460包括一个或多个数据库加速器内核464(例如，由在此所示的相应数据库加速器引擎执行)、存储器子系统466和存储器块468A-468N。在实践中，存储器块468A-468N可以对应于存储器模块或者是存储器的逻辑块。

出于区分的目的，系统400的一些部分被描述为在“中央处理单元侧”412上，而其他部分被描述为在“DBA侧”417上。值得注意，数据库应用440和驱动器427由中央处理节点执行，该中央处理节点可以与执行数据库加速器内核464的近存储器数据库加速器系统460的硬件分开(例如，相应数据库加速器引擎)。

示例9–示例近存储器数据库加速器系统组件架构

图5是实现用于数据库操作的近存储器加速的示例系统500的框图。在示例中，计算系统510包括内存数据库应用520、分流设备驱动器530和近存储器数据库加速器系统540。

内存数据库应用520可以通过分流API 525与分流设备驱动器530接口。

为了区别起见，可以将系统描述为具有中央处理单元侧512和存储器侧516。中央处理单元侧512由与执行DBA侧516的硬件分开的硬件执行。

可以使用任何数量的存储器配置来实现近存储器数据库加速器技术。在示例中，近存储器数据库加速器系统540可以包括内存数据库主存储的至少一部分544。内存数据库主存储544可以存储内存数据库的一个或多个元素，包括用于分流操作546的源值。内存数据库主存储544存储在与执行分流操作546以生成结果输出548的数据库加速器的硬件附近的存储器中。例如，系统540的一个或多个数据库加速器引擎可以执行一个或多个数据库加速器内核以执行数据库操作。

数据库加速器存储器模块可以存储内存数据库主存储的部分544和结果输出548。这样的存储器模块可以与提供操作存储器567的现有存储器模块分开，存在于近存储器数据库加速器系统540的外部。其他存储器设备568可以是计算系统510的直接可访问存储器550的一部分；直接可访问存储器550可以包括也由近存储器数据库加速器系统540访问的主存储器以及扩展存储器。

在实践中，内存数据库主数据存储的部分544可以包括列式主存储(例如，列式内存数据库的数据库列中的压缩值)。数据库加速器存储器模块还可以存储临时数据(例如，作为数据库操作处理的一部分而生成的数据，诸如在解压缩期间确定的未压缩值、临时连接结果等)。可以将附加临时数据存储在操作存储器567中。通常可以在数据库操作处理完成之后删除这些临时数据。

诸如(例如，在查找期间的)未压缩值或(例如，扫描的)滤波值的结果可以保持在近存储器加速器系统540的存储器中。其他临时数据可以保留在普通存储器设备中560。

近存储器数据库加速器系统540还可以包括控制寄存器542，控制分流处理(例如，以指示哪些内核被占用等)。

在实践中，本文所示的系统(诸如系统500)的复杂度可以改变，并具有附加功能、更复杂的组件等。例如，在分流设备驱动器530内可以有附加功能。可以包括附加组件以实现安全性、冗余、负载平衡、报告设计等。

所描述的计算系统可以经由包括互联网的有线或无线网络连接来联网。可选地，系统可以通过内联网连接来连接(例如，在公司环境、政府环境等中)。

系统500和本文描述的任何其他系统可以结合本文描述的任何硬件组件，诸如以下描述的计算系统(例如，数据库加速器硬件、处理单元、存储器等)来实现。在本文的任何示例中，源数据、压缩参数、结果输出等可以存储在一个或多个计算机可读存储介质或计算机可读存储器设备中。本文描述的技术可以是操作系统或硬件的特定方面通用的，并且可以在任何各种环境中应用以利用所描述的特征。

示例10–示例近存储器内存数据库加速方法

图6是例如在参照图1、图4或图5的系统中可以实现的在内存数据库环境中用于数据库操作的近存储器加速的示例方法600的流程图。例如，方法600可以在接收将数据库操作分流到近存储器数据库加速器的请求的驱动器中执行。

在实践中，用于数据库操作的源数据可以已经存储在近存储器数据库加速器的设备存储器中。例如，在内存数据库管理系统中，数据库元素通常可以存储在存储器中或被配置为如本文所述存储。因此，可以在原位置对源数据执行数据库操作，而不必将源数据移动到专用于分流的存储器中。相反，源数据存储在由中央处理节点直接可访问的存储器中(例如，其可以绕过数据库加速器引擎和内核)。

因此，在接收到请求之前，可以将源数据存储在内存数据库管理系统配置信息指定的近存储器数据库加速器的设备存储器中。

在620，接收在内存数据库管理系统环境中执行数据库操作的请求。如本文所述，可以将这样的数据库操作指定为对存储在设备存储器中的源数据中表示的多个值执行。源数据被存储在近存储器数据库加速器的设备存储器中。在实践中，作为内存数据库管理系统进行处理的一部分，源数据可能已经被存储在此类设备存储器中。设备存储器能够是由中央处理节点可直接访问(例如，正在处理请求)的。

如本文所述，可以经由用于本文中所述的任何数据库操作(例如，扫描、查找等)的应用编程接口从内存数据库管理系统接收请求。

作为在内存数据库管理系统内确定要分流请求的结果，可以从数据库应用(诸如内存数据库管理系统)接收请求。例如，内存数据库管理系统中的托管应用可以发送对于数据库操作的多个请求，并且内存数据库管理系统可以基于分流标准来决定要分流哪些数据库操作。这样的标准可以包括操作是否涉及高CPU使用率，操作是否涉及具有高存储器带宽使用率的巨大数据访问，顺序访问(相对于随机访问)的比率是否高等。

扫描和查找操作是分流的典型候选。在某些情况下，可能会及时发送若干扫描和/或查找分流请求，这可能超出准备的近存储器加速器系统的容量。因此，在确定是否分流操作时也可以考虑请求队列的长度。响应于确定要在数据库加速器上执行的数据库操作集合的队列超过阈值长度，数据库操作可以绕过分流并改为在中央处理节点上执行。

在640，将数据库操作发送到近存储器数据库加速器(例如，分流以由近存储器数据库加速器执行)。如本文所述，近存储器数据库加速器既可以包括存储源数据的存储器，也可以包括对源数据执行数据库操作的硬件(例如，靠近存储有源数据的设备存储器)或作为扩展存储器系统的一部分。

近存储器数据库内核(例如，在近存储器数据库引擎上运行)可以对源数据执行数据库操作。这样的执行生成数据库操作的结果。

在660，从近存储器数据库加速器接收对源数据执行的数据库操作的结果。

在实践中，处理可以重复多次(例如，对于分流的多个数据库操作)。通过将操作分解为较小的部分(在数据库加速器上同时执行)，也可以支持并行性。

如本文所述，分流可以减轻中央处理单元到存储器的数据路径以用于其他处理(例如，除了所请求的数据库操作以外)。

方法600可以结合本文描述的系统中的任何方法或动作，以实现本文描述的近存储器数据库加速技术。

可以通过存储在一个或多个计算机可读介质(例如，存储或其他有形介质)中或存储在一个或多个计算机可读存储器设备中的计算机可执行指令(例如，使计算系统执行方法)来执行方法600和本文所述的任何其他方法。可以以软件、固件，硬件或其组合来执行这样的方法。这样的方法可以至少部分地由计算系统(例如，一个或多个计算设备)执行。

可以从替代的角度描述所示出的动作，同时仍然实现技术。例如，从驱动器发送请求也可以描述为在数据库加速器处接收请求。

示例11–示例数据库操作

在本文的任何示例中，数据库操作可以采取由内存数据库管理系统对源数据执行的任何操作的形式，作为数据库处理的一部分。在实践中，这样的操作是在数据库表、列或其部分上执行的。例如，可以在列式数据库上执行表扫描，以确定具有与指定谓词或条件匹配的值的那些行。本文描述的技术可以扩展到任何数量的数据库操作，包括查找、加法、乘法等。

这样的数据库操作计算结果，该结果被传递回调用应用。如本文所述，结果可以存储在数据库加速器本地的存储器中，并通过引用传递回调用应用。例如，在表扫描的情况下，可以返回指示数据库表的哪些行满足谓词或条件的向量(例如，位图等)。

如本文所述，内存数据库主存储中的源值可以是压缩形式；因此，数据库操作还可以进一步包括解压缩以访问本文所述的基础数据。

示例12–示例存储器模块

在本文的任何示例中，存储器模块可以采取硬件存储器的形式，其通常包括电路板上的一系列动态随机存取存储器集成电路。在硬件中实现的实际存储技术在实践中可能会有所不同。

存储器模块的硬件配置可以采取双列直插式存储器模块(DIMM)、单列直插式存储器模块(SIMM)等形式。

数据路径可以根据硬件考虑因素(例如32位、64位等)而变化。

在近存储器数据库加速器实现中，用于执行数据库操作的硬件可以包括在存储器模块附近(例如，在同一电路板、硬件单元、设备上，或者比主中央处理单元更靠近存储器)。

在实践中，本文中的近存储器数据库加速器技术可以独立于基础存储器模块技术来实现。

示例13–示例数据库加速器引擎

在本文的任何示例中，可以通过各种硬件来实现计算分流数据库操作的结果(例如，通过执行数据库加速器内核)的数据库加速器引擎。这样的硬件可以采取近存储器处理器(例如，执行可执行软件以实现内核)、FPGA、ASIC或其他特定或专用硬件的形式。

在实践中，数据库加速器引擎可以包括片上系统(SoC)硬件组件；可以将用于实现数据库加速器引擎和数据库加速器的支持子系统的附加芯片放置在存储器模块(例如，存储器模块230等)上。在实践中，数据库加速器使其支持本文所述的API的功能(例如，通过包括适当的库)。

示例14–示例数据库加速器内核

在本文的任何示例中，数据库加速器内核可以包括计算分流数据库操作的结果的软件或固件。这样的软件或固件可以采取各种形式，诸如可执行代码、硬编码逻辑、门逻辑等。如本文所述，内核还可以执行解压缩以访问基础数据值。

示例15–示例分开执行

在本文的任何示例中，用于执行分流数据库操作的数据库加速器引擎可以与正在执行数据库应用的中央处理节点(例如，主中央处理单元)分开。如本文所述，可以通过将数据库加速器引擎放置在与中央处理节点不同的电路板、不同的硬件单元、设备上，或者以其他方式远离存储器来实现这种分开。

示例16–示例内存数据库应用

在本文的任何示例中，内存数据库应用可以采用利用内存数据库技术的任何软件程序的形式。一个有用的示例是内存数据库管理系统(IMDBMS)。然而，内存数据库应用可以采用最终实现如本文所述的内存数据库技术的任何应用的形式(例如，通过分流数据库操作)。

内存数据库应用既可以请求数据库加速器对本文所述的源数据执行数据库操作，也可以通过绕过数据库加速器直接访问源数据。

在实践中，内存数据库应用可以支持托管应用，从而为此类应用提供对源数据的访问权限，以启用各种数据库用例。

内存数据库应用可以从托管应用接收对数据库操作的请求，然后内存数据库应用根据分流标准来决定是否分流。在实践中，如果不是所有的存储器都使用数据库加速，则可以提前(例如，在接收请求之前)做出是否分流的决定，使得源数据已经在可以受益于数据库加速的存储器位置中。

在实践中，对数据库加速的访问可以限于提升系统，诸如实现访问控制的内存数据库管理系统。任何数量的内存数据库应用都可以利用本文描述的技术，包括由德国Walldorf的SAP SE设计的SAP HANA系统以及其他内存数据库管理系统。

示例17–示例内存数据库技术

在本文的任何示例中，数据库加速器技术可以支持根据内存数据库技术(例如，通过近存储器数据库加速器)对包括存储在(例如，近存储器数据库加速器的设备存储器的)存储器中的内存数据库分量的源数据执行数据库操作。可以将诸如一个或多个表、一个或多个表列等的内存数据库分量存储在存储器中，与存储在二级存储(secondary storage)中相比，可以提高性能。如本文所述，近存储器数据库加速器所接近的存储器可以是内存数据库管理系统的主存储的至少一部分。

在实践中，由于通常只能使用有限数量的存储器，因此内存数据库技术可以利用数据压缩。例如，内存列式数据存储可以使用压缩来表示有限数量的存储空间中的大量值。

根据用例情况，可以使用不同类型的压缩，并且内存数据库技术可以支持跨不同列的这种压缩类型的混合。

当数据库加速器应用于压缩了源数据的内存数据库环境时，数据库加速器可以执行解压缩以访问数据库的基础数据，作为执行数据库操作的一部分。结果，解压缩处理从中央处理节点分流到数据库加速器。

如本文所述，源数据的压缩信息可以被包括在请求中。近存储器数据库加速器可以使用这样的信息对源数据进行解压缩。这样的信息可以包括在解压缩期间应用的参数。例如，如果源数据是根据位压缩格式压缩的，则压缩信息可以指定位打包压缩格式的位数。

如本文所述，源数据可以包括列格式的数据库表值。可以支持指定谓词的操作(诸如表扫描或查找)。结果表明谓词对哪些数据库列值有效。

值是否存储在存储器内可以由内存数据库管理系统控制，使用启发式方法确定哪些值(例如表、列、分区等)要存储在存储器中。可以支持手动指定内存数据库分量，以实现配置灵活性。

为了与本文描述的数据库加速器技术一起工作，内存数据库管理系统可以是近存储器数据库加速器感知。例如，在某些存储器由数据库加速器可访问而有些存储器不可访问的系统中，内存数据库管理系统的配置可支持指定哪些表或表元素要存储在数据库加速器可访问的存储器中。数据库表或数据库元素是否存储在这样的存储器中的这种配置可以由自动标准指导或由数据库管理员手动指定。

示例18–示例内存数据库存储器布局

在本文的任何示例中，内存数据库管理系统可以维护主存储以及包括增量区域的操作存储器。内存数据库的最新更改可以放置在增量区域中。因此，在周期性增量合并处理中，可以将增量区域中的信息定期合并到主存储中。在实践中，可以对主存储运行数据库操作。然后可以将结果与增量区域进行协调(如果有)。

在内存数据库管理系统中，数据库加速器引擎可以在主存储上执行数据库操作，并提供结果，然后可以将其与增量区域进行协调。在这样的布置中，包括增量区域的操作存储器可以与主存储分开。因此，例如，在图2中，可以将主存储的至少一部分存储在数据库加速器存储器模块230的存储器280中，而可以将包括对应的增量区域的操作存储器存储在其他存储器中(例如，在数据库加速器存储器模块230之外)。对于图3的扩展存储系统布置，类似的方法是可能的。可以但不必通过数据库加速器引擎来增强此类操作存储器。

在实践中，内存数据库的主存储(例如，因此数据库加速器在其上执行数据库操作的存储器)可以实现为非易失性存储器(例如，NVDIMM等)，而操作存储器和增量区域存储在DRAM中。

示例19–示例近存储器内存数据库加速器

在本文的任何示例中，近存储器内存数据库加速器(有时在本文中有时简称为“数据库加速器”或“DBA”)可以采用既具有存储器又具有以硬件(例如，靠近存储器)或扩展存储器系统实现的一个或多个数据库加速器引擎以及以硬件(例如，靠近存储器)中实现的一个或多个数据库加速器引擎的设备的形式。

内存数据库加速器的示例被示出为图1中的130、图2的230、图3的330、图4的460、图5的540和图11的1110。

近存储器数据库加速器系统有时被称为“主机”，因为它可以接收和处理来自内存数据库应用的分流请求(例如，通过数据库加速器驱动器)，如本文所述。

在实践中，这样的数据库加速器可以包括子系统，诸如执行相应内核(例如，计算数据库操作结果)的一个或多个数据库加速引擎、存储器子系统等。

存储器设备可以被改变为还包括数据库加速引擎，计算访问存储器设备上的存储器的数据库操作的结果作为源数据。然后可以将操作分流到这种存储器设备，这是数据库加速器的一种形式。

如本文中所描述，近内存数据库加速器可在适当位置(或“原位”)在内存源数据上本地执行分流的数据库操作，并且可以通过中央处理节点预先将源数据放置在直接可访问存储器中，如本文所述，而不必将其移动到与直接可访问的存储器分开的专用区域。这种方法大大减少了执行分流数据库操作所需的数据移动量。例如，对于分流数据库操作，不需要由中央处理节点进行值的比较。因此，数据解压缩计算也可以分流到数据库加速器，如本文所述。

因为中央处理节点也可以直接访问数据库加速器引擎可用的直接可访问存储器(例如，绕过将处理被分流到的数据库加速器引擎)，所以可以容易地获得由数据库加速器引擎放置在直接可访问存储器中的结果，如本文所述。

示例20–示例数据库加速器驱动器

在本文的任何示例中，可以实现近存储器数据库加速器驱动器(或本文中简称为“驱动器”)。在实践中，这样的驱动器可以在利用数据库加速器技术的软件和实现实际数据库加速器的基础硬件的详情之间提供抽象层。例如，驱动器可以实现为软件功能库，可以执行CPU到数据库加速器通信功能。

可以由代表应用与近存储器数据库加速器交互的驱动器从内存数据库应用接收请求。如本文所述，数据库操作可以分为由近存储器数据库加速器并行执行的较小的操作。

可以将源数据指定到驱动器作为虚拟地址。驱动器可以将虚拟地址转换为设备物理地址。驱动器首先可以通过参考页表来获得系统物理地址。然后，可以基于来自系统BIOS的信息将设备物理地址转换为系统物理地址，在引导时将设备存储器的启动系统物理地址存储在基址(BAR)寄存器中。

如本文所述，驱动器可以被配置为接收对存储在近存储器数据库加速器的设备存储器中的源数据执行数据库操作的请求，该近存储器数据库加速器包括与一个或多个处理单元(中央处理节点)分开的至少一个数据库加速器引擎，将数据库操作分流到近存储器加速器，以由与一个或多个处理单元分开的至少一个数据库加速器引擎执行，并从近存储器数据库加速器接收数据库操作可用的结果的指示。然后，调用应用可以检索结果。如本文所述，源数据可以存储在一个或多个处理单元的直接可访问存储器中。这样的处理单元可以直接访问直接可访问存储器，从而绕过数据库加速器。因此，主存储器或扩展存储器包括近存储器数据库加速器的设备存储器。设备存储器因此是主存储器或扩展存储器的一部分，由中央处理单元直接可访问。

示例21–示例更详细的方法

图7是在内存环境中用于数据库操作的近存储器加速的示例更详细的方法700的流程图，该方法可在本文的任何示例中实现，诸如图1、图2、图3、图4和图11所示的系统。

可以响应于确定数据库操作将被分流(例如，通过内存数据库管理系统)到近存储器数据库加速器而执行，如本文所述。

在710，发送分流请求。例如，内存数据库应用可以通过分流API将请求发送到分流设备驱动器，如本文所述。在实践中，发送方(例如，进程、线程等)然后可以进入睡眠状态，直到请求的操作完成。

在720，分配数据库加速器引擎，并且请求被转发到适当的硬件。在实践中，驱动器可以选择具有执行操作的源数据的硬件，可以根据请求中的虚拟地址确定。

内存数据库应用可以仅请求分流操作，并且可以将请求插入请求队列中。然后，数据库加速器内核可以逐一执行队列中的请求。

在730，内存数据库加速器执行分流操作，这产生了本地存储在数据库加速器的硬件中的结果。

在740，分流处理完成消息从数据库加速器发送回驱动器。

在750，分流处理完成条件被中继回到请求者。例如，可以将唤醒消息发送回调用API的发送者。

在760，数据库应用可以直接从存储结果的存储器中访问结果。例如，可以将输出缓冲区参数指定为请求的一部分，然后可以将结果存储在输出缓冲区参数中以进行访问。结果的位置可以传递回发送者以进行直接访问。

在驱动器请求分流之前，内存数据库应用可以为结果准备输出区域，并指定为请求的一部分。数据库加速器执行操作并将结果存储在指定输出区域中。

示例22–示例存储器通信信道

在本文的任何示例中，可以在中央处理节点和数据库加速器之间提供存储器通信信道。在实践中，用于访问存储器的同一通信信道可用于与数据库加速器通信。当中央处理节点直接访问存储器时，它仅绕过数据库加速器。

例如，驱动器和数据库加速器之间的通信可以通过支持存储器映射I/O(MMIO)(例如，PCIe等)的总线标准来实现，以在与主机存储器相同的地址空间中映射设备存储器。可以支持对数据库加速器的存储器的字节寻址访问，以实现数据的快速通信。

可用于通信信道的示例性存储器接口包括DDR(例如DDR4)等。诸如计算快速链接(CXL)、Gen-Z和OpenCAPI的存储器接口可以启用在内存数据库管理系统中托管列式主存储的新存储器池。

示例23–示例操作顺序

图8是在内存数据库环境中实现用于数据库操作的近存储器加速的示例操作序列800的序列图。这样的一系列操作可以由协同工作的内存数据库应用810、分流设备驱动器830和在近存储器内存数据库加速器850处执行的存储器内核来执行。

在860，内存数据库应用810向分流设备驱动器830发送分流请求。如本文所述，驱动器830可以支持用于发送请求，接收通知以及提供结果的API，使得应用不受近存储器内存数据库加速器850的硬件详情的影响。驱动器830将请求862分配给近存储器数据库加速器850，然后执行数据库操作。

在完成分流数据库操作的执行之后，近存储器内存数据库加速器850向分流设备驱动器830发送864分流处理完成消息，随后将处理完成条件中继866到内存数据库应用810。

然后，如本文所述，内存数据库应用810可以通过通信信道从近存储器内存数据库加速器850检索868结果。检索结果可以包括经由存储器映射I/O将结果(例如，从设备存储器中)检索到中央处理单元，如本文所述。可以使用字节寻址技术。

在实践中，发送860分流请求的内存数据库应用的进程或线程可以在等待处理完成条件的同时休眠，这将唤醒该进程或线程，然后可以如图所示检索结果。

示例24–执行数据库操作的示例请求

图9是示出执行数据库操作的请求920的示例内容的框图。在实践中，这样的请求920从内存数据库应用(例如，经由API)发送到分流设备驱动器930(例如，数据库加速器设备驱动器)，其将请求编排并将其中继到近存储器内存数据库加速器950，对源数据955上原位执行操作，源数据955存储在加速器950的数据库加速器引擎附近的存储器中。

如所示，请求920可以包括输入数据的指示，诸如指向输入数据缓冲区的指针927。还可以包括要存储结果的位置。

如本文所述，还可以包括源数据955的压缩详情928。例如，当源数据955以位打包格式表示列值时，可以指示每个值的位数。当这样的操作还涉及对源数据955进行解压缩时(例如，确定哪些值与指定谓词匹配时，也可以包括在请求920中)，这样的信息可以由近存储器内存数据库加速器950执行数据库操作。也可以包括压缩类型(例如，内存数据库应用910已知的压缩类型)。

如在本文的API的描述中所指出的，其他参数可以被包括在请求920中(例如，以传回结果等)。

示例25–示例微架构

图11是支持用于数据库操作的近存储器加速的微架构1100的框图。在该例中，近存储器内存数据库加速器1110与数据库加速器驱动器1105通信。

近存储器内存数据库加速器1110包括主机接口1120、一个或多个DBA内核1130以及最终与其中存储内存数据库分量的存储器1160A-N交互的存储器子系统1140。

如示例中所示，主机接口1120可以包括通信信道端点1122，在与数据库加速器驱动器1105交互时支持通信(例如，总线)协议。通信信道1120可以提供对存储器交叉开关1145的访问，使得可以在不涉及数据库加速器内核1130的情况下实现到存储器的部分通信。主机接口1120还可以支持与一个或多个DBA内核1130交互的编程接口1126，从而可以将分流数据库操作通信到内核1130以进行执行。

数据库加速器内核1130通过与存储器子系统1140进行交互而享有对存储器1160A-N的紧密访问。在实践中，给定DBA内核1130可以包括预取器1132、SIMD引擎1134和结果处理器1136。

为了增加并行度，数据库加速器内核可以将数据库操作拆分为多个较小的计算，从而有效地实现单指令多数据方法的本地(近存储器)版本。不同内核可以获取源值的不同子集，并独立于其他内核执行简单比较；可以将分开的结果打包并写回到设备存储器1160A-N，然后作为合成结果读取。

这样的布置可以利用SIMD方法，而不消耗宝贵的存储器到中央处理节点带宽。

在实践中，也可以并行执行多个数据库操作。分配给操作的并行单元数可以通过传入数据或其他标准中的值数来确定。

示例26–示例应用编程接口

在本文的任何示例中，可以提供应用编程接口(API)来促进内存数据库应用和一个或多个数据库加速器之间的通信。API的详情可能会根据各种标准而有所不同。在实践中，API可以用作将应用与硬件实现的详情隔离开的抽象层。

示例27–示例API：返回代码

在本文的任何示例中，API可以接受分流数据库操作的请求，并返回指示请求状态的返回代码值。例如，一个代码值可以指示成功，而其他值可以指示失败。如果需要，还可以提供部分完成的值。

值方案可以将零用于成功完成，将负值用于失败，将正值用于部分完成。例如，-1可以表示未接受；-2可以指示请求超时；等。

部分完成可以指示需要调整大小(例如，以适应行向量输出)，如本文所述。

示例28–示例API：扫描

在本文的任何示例中，API可以接受分流扫描数据库操作的请求。示例扫描操作在图12中示出。扫描数据库操作有效地搜索数据库表，并在指定的行标识符范围内(例如，通过起始偏移和计数)返回满足所提供的谓词的行标识符。

输出可以是行向量。可以将满足谓词的行标识符存储在向量中。分流设备可以改用最初为空的指针。在完成分流处理之后，将输出写入给定向量，数据库应用可以在其中读取输出。

可选地，输出可以是位向量，其中一位代表一行。可以设置满足谓词的行的位(例如，为1)。

谓词可以采取多种形式。范围谓词可以使用两个无符号整数值(例如，从和到)定义值标识符的范围。可选地，列表中谓词可以被定义为满足值标识符的位被设置为1(即，“匹配”)的位向量。源数据表中具有满足谓词的正在处理的列(例如，或其一部分)中的值的行被认为是匹配的，并且包括在结果中(例如，以本文所述的格式)。

示例29–示例API：扫描函数定义

扫描函数定义(例如，分流/执行扫描数据库操作的请求)可以根据扫描情况而变化：

//(1)Range Predicate&Row Vector Output

int mgetSearch_offloading_impl(uint64_t index,uint64_t count,uint32_trangeFrom,uint32_t rangeTo,

uint64_t*scan_count,const unsigned*prev_start,const unsigned*start,uint64_t*size,uint64_t capacity,

const unsigned bits,const uint64_t*data,const uint64_t mask)；

//(2)Range Predicate&Bit Vector Output

int mgetSearch_offloading_impl(uint64_t index,uint64_t count,uint32_trangeFrom,uint32_t rangeTo,

const uint64_t*output,const unsigned bits,const uint64_t*data,constuint64_t mask)；

//(3)In-list Predicate&Row Vector Output

int mgetSearch_offloading_impl(uint64_t index,uint64_t count,uint64_t*match,

uint64_t*scan_count,const unsigned*prev_start,const unsigned*start,uint64_t*size,uint64_t capacity,

const unsigned bits,const uint64_t*data,const uint64_t mask)；

//(4)In-list Predicate&Bit Vector Output

int mgetSearch_offloading_impl(uint64_t index,uint64_t count,uint64_t*match,

const uint64_t*output,const unsigned bits,const uint64_t*data,constuint64_t mask)；

功能参数可以如下：

因此，输入数据缓冲区用作扫描的源数据，并且结果被放置在位向量输出指针中。其他布置也是可能的。

示例30–示例API：扫描调整大小处理

在本文的任何示例中，在由数据库加速器处理数据库操作期间，输出缓冲区的大小(例如，请求中指定的容量)可能不够大。在这种情况下，响应于在数据库加速器处检测到输出缓冲区的大小不足(例如，基于容量参数)，API可以返回部分完成的结果。然后，内存数据库管理系统可以分配附加空间，并且可以恢复处理。

例如，行向量输出缓冲区的大小可能不够大。图13是行向量输出的示例调整大小处理的框图。

在对结果进行初始分配的分流调用之后，数据库加速器检测到缓冲区不足。例如，如果(容量大小＝<阈值)，则数据库加速器返回向量调整大小请求作为返回代码。

向量调整大小处理可以包括数据库加速器的请求，以请求对向量调整大小。内存数据库管理系统可以执行重新分配。数据库加速器可以复制先前向量中的数据。内存数据库管理系统可以在调整大小之后恢复具有新参数的API。

内存数据库管理系统可以在使用之后管理分配和释放分配的存储器。

这种处理的详情可以如下：

变量scan_count(到目前为止扫描的行数)可以设置为零。

变量大小(输出数组中的行数)可以初始设置为零。

除非start_ptr1为null，否则数据库加速器扫描引擎可以将start_ptr1中的数据复制到atart_ptr2。当复制数据时，要复制的行数是按大小定义的。

数据库加速器扫描引擎开始从[索引+scan_count](包括)扫描到[索引+计数](排除)。

可以在数据库加速器扫描期间从start_ptr2[size]添加满足谓词的行的行标识符。

当从分流返回时，数据库加速器以变量scan_count返回到目前为止扫描的行数和可变大小的输出数组中的行数。

在对结果缓冲区进行充分分配之后，可以恢复扫描。

示例31–示例API：查找数据库操作

在本文的任何示例中，数据库加速器可以处理分流查找数据库操作。在内存数据库情况中，查找可能涉及在由起始偏移量和计数指定的行标识符范围内解压缩列向量。然后可以将未压缩的值标识符存储到目标指针指定的数组中。

查找(例如，mget)的基本实现的示例如下：

get()可以在指定索引处返回未压缩的valueID。根据使用稀疏压缩还是间接压缩，对get()的处理可能会有所不同。

示例32–示例API：查找函数定义

查找函数定义可以根据情况而变化：

(1)Lookup for bit-packed compression

int mget_offloading_impl(uint64_t index,uint64_t count,unsigned*dest,void*cache,

const unsigned bits,const uint64_t*data,const uint64_t mask)；

(2)Lookup for sparse compression

int mget_offloading_impl(uint64_t index,uint64_t count,unsigned*dest,void*cache,

const SparseMemoryDocumentsWrapper*doc)；

(3)Lookup for indirect compression

int mget_offloading_impl(uint64_t index,uint64_t count,unsigned*dest,void*cache,

const IndirectMemoryDocumentsWrapper*doc)；

功能参数可以如下：

示例33–示例API：位打包压缩中的查找

查找可以涉及已经历位打包压缩的源值。为了处理查找，数据库加速器可以对范围内的向量解包并将值标识符存储到目标数组。图14是在查找数据库操作中的位打包压缩的示例的框图。可以提供查询数据库操作的其他参数，如下所示：

示例34–示例API：稀疏压缩中的查找

查找可以涉及已经历稀疏压缩的源值。输入参数可以包括用于这种高级压缩的类型调整。SparseMemoryDocumentsWrapper结构可以如下：

这样的结构可以反映内存数据库管理系统的基础结构，并具有如图所示的bitsNonZeroValues和bitsPositions的添加字段。这样的class-wise数据结构可以用原始类型展平。

数据结构中的类成员可以包括以下内容：

itsValueCount，其包含不同值的数量；

itsZeroValue，其包含最频繁值的valueID；

itsNonZeroDocuments，它是一位值的列表，指示如果值的集合为零(最频繁的一个)，则值不为零(不是最频繁的一个)；

itsNonZeroValues(又称为非零向量)，它是位打包的非零值(除了最频繁的一个)和每个值的位数：与稀疏压缩之前的位打包压缩数据中的值相同；

itsPositions，它是值的位打包向量，指示每组128个值的非零向量的起始位置以及每个值的位数：根据列向量中的数据项数量(不根据非零向量的大小[itsNonZeroValues]。例如，如果数据项的数量为2,000,000,000，则每个值的位数为31；以及

itsZeroOffset，其包含带有零值的前缀值的数量(128的倍数)。

图15示出在稀疏压缩情况中的查找的示例方法1500。在此示例中，itsZeroOffset是稀疏压缩中组大小(128)的倍数。docid＝0被保留，即使应用了前缀压缩。

示例35–示例API：以稀疏压缩伪代码查找

可以通过以下伪代码来实现稀疏压缩情况中的查找：

Get(int docID)

If docID＝0&&itsZeroOffset>0then//if docid＝0&&prefix compression isapplied

Return itsValueCount//docID＝0is reserved to represent the number ofdistinct values

Else if docID<itsZeroOffset||itsNonZeroDocuments[docID-itsZeroOffset]＝0//if it is zero value

Return itsZeroValue

Else

GROUP_INDEX＝(docID–itsZeroOffset)/128

FIRST_INDEX＝GROUP_INDEX*128

POSITION＝itsPositions[GROUP_INDEX]

If FIRST_INDEX<(docID–itsZeroOffset)then

POSITION+＝{The number of bit sets in itsNonZeroDocuments from FIRST_INDEX to(docID–itsZeroOffset)}

Return itsNonZeroValues[POSITION]

示例36–示例API：间接压缩中的查找

查找可以涉及已经历间接压缩的源值。为了处理查找，数据库加速器可以根据需要执行解压缩。图16是示出间接压缩情况中的查找数据库操作的框图。

IndirectMemoryDocumentsWrapper结构可以如下：

这样的结构可以反映内存数据库管理系统的基础结构，具有bitsValues的添加字段，如图所示。这样的class-wise数据结构可以用原始类型展平。

IndBlockInfos的包装器可以如下：

struct IndBlockInfosWrapper{

int offset；//from IndBlockInfos::offset

unsigned bits；//from IndBlockInfos::ind::m_bitsPerValue,set to 32ifthe cluster is uncompressed

uint64_t*data；//from IndBlockInfos::ind::m_buffer,set to nullptr ifthe cluster is uncompressed

}；

数据结构中的类成员可以包括以下内容：

itsValues：包含集群字典(如果应用)或未压缩集群(如果非应用)的位打包向量；每个值的位数：与间接压缩之前的位打包压缩数据中的位数相同

itsClusters：IndBlockInfos::offset：每个集群的索引向量的起始索引(itsValues)；IndBlockInfos::ind：压缩集群的位压缩块(如果应用)(每个值的位数为0～10，具体取决于每个集群中不同值的数量；如果每个值的位数＝0，则集群中的行的valueID是相同的

itsZeroValue：包含不同值的数量

itsPrefixValue：如果应用了前缀压缩，则包含docid＝1(保留0)处的值itsPrefixOffset：包含前缀值的数量和前缀值(1024的倍数)。

图17示出在间接压缩情况中的查找的示例方法1700。在示例中，itsPrefixOffset是间接压缩中集群大小的倍数(例如，1024)。docid＝0被保留，即使应用了前缀压缩。

示例37–示例API：间接压缩伪代码中的查找

可以通过以下伪代码来实现间接压缩情况中的查找：

示例38–示例数据压缩

内存数据库管理系统

在本文的任何示例中，内存数据库管理系统可以在将数据存储在内存中时实现压缩，并且此类数据可以是数据库加速器的源值，该数据库加速器对存储在存储器中的数据执行数据库操作。如本文所述，可以支持多种压缩方案。内存数据库管理系统可以跟踪哪些数据库元素正在使用哪种压缩类型。列存储可以利用高级压缩技术在较小的存储器占用空间中表示大量的值。

示例39–示例数据压缩

内存数据库管理系统：位打包压缩

默认情况下可以使用位压缩方案。图18是用于在内存数据库管理系统中的数据库分量的位打包压缩中使用的数据结构1800的框图。

在示例中，列数据由字典和ValueID数组存储。可以压缩ValueID数组以节省存储器使用量。因此，在实践中，可以将位打包压缩与本文所述的其他压缩方案(例如，稀疏、集群、游程编码、间接等)一起使用。

图19是位打包(即，压缩)ValueID数组的框图。仅需要使用有意义的位来保留值。在示例中，可以将值以比解包时(例如，通常确实与字节边界对齐，诸如在示例中的32位)更少的位数(例如，不需要与字节边界对齐，诸如示例中的17位)存储。位数可以由内存数据库跟踪，并作为参数提供给数据库加速器以促进解压缩。

内存数据库管理系统：列存储压缩

如本文所述，多种压缩方案可以用于列存储。可以在主存储的ValueID数组上使用这种压缩。还可以维护单独的增量存储，并且可以在增量存储与主存储合并时(例如，在合并操作中)在增量合并期间计算和执行压缩结果。图20是示出不同的列存储压缩情况2000的框图：前缀编码、游程编码、集群编码、稀疏编码和间接编码。可以将数据库加速器配置为以任何压缩格式对源数据执行数据库操作。因此，可以实现多重压缩方案感知的数据库加速器。

前缀编码：如果列以具有相同值V的长序列开头，则序列将通过一次存储值和出现次数来替换。如果列中有一个主要值，而其余值大多是唯一的或具有低冗余，则这是有意义的。

游程编码将相同值的序列替换为该值及其起始位置的单个实例。之所以选择游程编码的这种变体，是因为与存储每个值的出现次数相比，它可以加快访问速度。

集群编码将数组划分为N个固定大小的块(例如1024个元素)。如果集群仅包含单个值的出现，则集群将被该值的单个出现替换。长度N的位向量指示哪些集群被单个值替换。

稀疏编码会删除最常出现的值V。位向量指示从原始数组中删除了哪些位置V。

间接编码也基于划分为1024个元素的块。如果块仅包含几个不同的值，则将使用附加字典对该块中的值进行编码。图以8个元素的块大小说明了这一概念。第一和第三块由不超过4个不同的值组成，因此具有4个条目的字典和具有2位的值的编码是可能的。对于第二个块，这种压缩是没有意义的。使用8个不同的值，字典就需要与未压缩数组相同的空间。实现还需要存储哪些块已使用其他词典进行了编码以及到其他词典的链接的信息。

内存数据库管理系统：稀疏压缩

图21是用于在内存数据库管理系统中的稀疏压缩的示例方法2100的流程图。最后，IndexVector itsNonZeroValues包含非零值(例如，除了最频繁的一个以外的所有值)，也称为非零向量。BitVector itsNonZeroDocuments包含一位值得列表，指示值是零还是非零。IndexVector itsPositions是值的位打包向量，指示每组(例如128个)值中非零向量的起始位置。

条件是需要找到零值(最频繁的值)。压缩还可以应用零值的前缀压缩(例如SpDocuments:itsZeroOffset[按照128对齐])。

假定位置粒度为4的带前缀的第一示例漫游如下：

输入:(3),0,0,0,0,1,2,1,1,1,1,1,1,1,2,2,2,2,2,2,0,0,0,1,0,0,0,0,1,1,1,1,1,1,1,1,0,1,2,0,0,0,0,0,0

零值:0

零偏移:4

非零向量:1,2,1,1,1,1,1,1,1,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,2

位向量:0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,1,0,0,0,0,1,1,1,1,1,1,1,1,0,1,1,0,0,0,0,0,0

位置:0,3,7,11,15,16,16,20,24,26,26

当应用前缀压缩时，docID＝0被忽略，因为它是保留的。

位向量中的位数与不包括前缀的数据大小匹配。

位置向量中的值的数量与没有前缀的组的数量匹配。

假设位置粒度为4的无前缀漫游的第二示例如下：

输入:(3),0,0,0,0,1,2,1,1,1,1,1,1,1,2,2,2,2,2,2,0,0,0,1,0,0,0,0,1,1,1,1,1,1,1,1,0,1,2

零值:1

零偏移:0

非零向量:(3),0,0,0,0,2,2,2,2,2,2,2,0,0,0,0,0,0,0,0,2

位向量:1,1,1,1,1,0,1,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,1,1,1,1,0,0,0,0,0,0,0,0,1,0,1

位置:0,4,6,6,8,12,15,19,19,19

没有前缀压缩，因为除了docid＝0处的值以外，这些值都不是零值。

图22是在内存数据库管理系统中使用的稀疏解压缩的示例方法2200的流程图。

内存数据库管理系统：间接压缩

在本文的任何示例中，间接压缩也可以用于值标识符。图23是在内存数据库管理系统中使用的间接压缩技术2300的示例的框图。索引向量包含新字典，对于未压缩的块，包含原始值。

位压缩块形成如下：使用字典的索引对每个块进行重新编码，然后进行位压缩，然后将其依次存储在位压缩块向量中。

偏移向量：对于每个块，结构保留以下信息的记录：与块有关的数据在索引向量中的起始位置，在这种情况下在位压缩块向量中的起始位置，以及多少位用于编码。

图24是用于内存数据库管理系统中的间接压缩技术2400的示例的另一框图。

假设集群的大小为8，则无前缀的间接压缩示例如下：

输入:(7),0,0,1,0,0,1,0,0,1,1,1,2,1,1,1,0,2,2,1,2,2,2,3,4,0,5,6,3,4,5,2,2,4,2,2,4,2,4,2

前缀值:0

前缀偏移:0

索引向量:(7),0,1,2,0,2,1,3,4,0,5,6,3,4,5,2,2,4

IndBlockInfos的向量

–[0].offset＝0,[0].ind＝0,1,1,2,1,1,2,1(2-bit)

–[1].offset＝0,[1].ind＝1,2,2,2,3,2,2,2(2-bit)

–[2].offset＝4,[2].ind＝0,1,1,2,1,1,1,3(2-bit)

–[3].offset＝8,[3].ind＝empty(uncompressed)

–[4].offset＝16,[4].ind＝0,1,0,0,1,0,1,0(1-bit)

没有前缀压缩，因为除docid＝0处的值外，集群中并非所有值都相同。

图25是在内存数据库管理系统中使用的间接压缩方法2500的流程图。

对于间接压缩，输出如下：

索引向量包含

–集群字典(如果应用)或列向量的未压缩集群(如果未应用)；；以及and

IndBlockInfos的向量

–IndBlockInfos::offset–每个集群的索引向量的起始索引

–IndBlockInfos::ind–在应用的情况下压缩集群的位压缩块(索引向量)。

间接压缩的条件是，对于每个集群，集群字典的大小加上位压缩块的大小应较小。

还可以使用IndDocuments::itsPrefixValue和IndDocuments::itsPrefixOffset(例如，按1024对齐)对第一值进行前缀压缩

图26是在内存数据库管理系统中使用的间接解压缩方法的流程图。可以使用以下内容：

writePtr[i]＝clusterDict[clusterBuffer[i]]；

内存数据库管理系统：集群字典

数据库加速器还可以对涉及集群字典的值进行数据库操作，作为间接压缩的一部分。集群字典可以采用每个集群中不同值的向量以及向量中映射索引列表的形式，以帮助在向量中查找值。

集群字典的属性是集群字典中的值是整数valueID，并且它们无序，以避免在合并集群字典时重建先前的位压缩块。

合并的结果条件是，不同值的数量的位宽在前一个和下一个之间是相同的。当n＝2^(k-1)时，它可以被接受，其中k是位宽。同样，下一个集群字典中的其他不同值的数量不需要任何其他位。

在合并操作期间，将其他不同值附接到先前集群字典中。可以基于合并字典重建当前集群的位压缩块。

图27是在内存数据库管理系统中使用的间接压缩中的集群字典处理的框图。

示例40–传统方法的性能下降示例

图28显示了由于扫描工作负载对具有4个套接字和72个物理核心的服务器中的在线分析处理(OLAP)数据的干扰，在线事务处理(OLTP)工作负载的性能下降。由两个单独的进程管理的两个工作负载访问不同的数据集合，但由于CPU、缓存和存储器带宽等有限的硬件资源而相互竞争。随着扫描线程数量的增加，分配给OLTP工作负载的CPU资源会减少，因此OLTP工作负载的吞吐量会下降。

由于SIMD(单指令、多数据)在同时利用数据级并行性的多个数据点上执行相同的操作，因此可以将SIMD指令应用于DBMS内的如扫描的数据密集型操作。可以观察到，当使用SIMD命令(如AVX2或AVX 512)执行扫描操作时，OLTP工作负载表现出更大的性能下降，这是因为存储器带宽使用量大大增加。如表1所示，在具有SIMD的情况下，64个扫描线程几乎消耗了4个套接字的所有存储器带宽，而在没有SIMD的情况下，仅消耗了12％的存储器带宽。有趣的是，SIMD和NO-SIMD之间的CPU使用率没有差异，但是OLTP吞吐量显示SIMD会导致更大的性能下降。在图1中，使用64个扫描线程，OLTP的CPU使用率降低了30％，但是在没有SIMD的情况下，OLTP吞吐量降低了约40％，在具有SIMD的情况下，降低了50％以上。这支持以下说法：数据密集型工作负载使用更大的存储器带宽会进一步降低OLTP性能。

表1：通过扫描工作负载的存储器带宽使用率(％)

#线程	AVX2	AVX512	No_SIMD
				4	11.3	6.0	0.8
8	21.8	12.3	1.3
				16	41.3	23.0	2.8
32	73.8	46.3	5.5
				64	94.8	85.3	11.3

示例41–内存数据库管理系统(IMDBMS)中的示例扫描操作

可以将最新的内存数据库管理系统设计为支持OLTP工作负载和OLAP工作负载两者，并将数据保留在列存储中，以实现对表的快速读取访问，将每列的大部分数据存储在读取优化的主存储中，并维护单独的增量存储以优化写入。增量存储将定期合并到主存储。为了减少存储器占用量(或总拥有成本)，主存储使用字典编码，其中将不同的值存储在字典中，并将各个值分别替换为字典的相应值ID，并进行位压缩。IMDBMS中的扫描会使用过滤条件读取此值ID数组。在本文描述的示例中，两种常见的扫描操作：范围搜索(具有从/到过滤条件)和内列表搜索(具有过滤值的列表)可以被分流到数据库加速器，因为它们是通常会消耗相对较高的CPU使用率(本身占5-10％)的简单且常见的数据密集型操作。它们包括值ID(整数)数组的解压缩和满足谓词的返回行ID。仅分流查询计划中的低级数据访问运算符可减少将它们与现有查询优化器集成的工作量。

示例42–示例数据库加速器架构：FPGA

图10中示出用于测量近存储器数据库加速器的性能的所提出的系统的架构。该示例演示了当前生态系统中分流的可行性，提供了测量独立数据库加速器引擎性能的框架，并能够研究该技术对系统的影响。为了消除不必要的数据移动，数据库加速器将在存储源数据的设备存储器中执行数据库操作。在数据库加速器完成操作之后，结果输出将写回到FPGA中的设备存储器中。主机可以通过存储器映射I/O(MMIO)访问设备存储器。这消除了研究中PCIe接口的速度和一致性限制，但仍利用当前驱动器软件堆栈与OS和应用。

图11示出示例数据库加速器FPGA微架构，其具有主机接口1120、多个DBA内核1130和存储器子系统1140的功能分区。主机接口1120将数据库加速器控制参数公开给管理从应用API调用分流到硬件加速器的驱动器1105。给定数据库加速器内核1130可以包括读取数据的数据预取器1132，将数据与谓词进行比较的SIMD引擎1134以及写入结果的结果处理器1136。存储器子系统1140提供访问FPGA上的设备存储器1160A-N的架构。

在内部，数据库加速器内核1130可以从存储器1160A-N读取位压缩的源数据(例如，一次一块，诸如64B)。可编程提取器逻辑可以将源数据拆分为多个值。可以将多个值馈送到简单处理单元的数组中，每个单元可以独立执行简单比较。数组中并行单元的数量可以由数据块中的值的数量确定，使得数据库加速器内核可以跟上输入数据速率。与固定长度的基于指令的处理器相比，由于硬件设计的灵活性，数据库加速器内核可以充分利用数据流中的并行性。结果被打包到块(例如，64B)中并写回到设备存储器中。因此，可以对可用存储器带宽高度优化数据流。

图5和图8示出示例数据库加速器软件架构。与GPU/FPGA加速器不同，数据库加速器引擎位于存储器设备中。因此，它允许具有性能和能量增益的零数据复制。每个请求，数据库加速器设备驱动器都会将一个数据库加速器引擎分配给内存数据库管理系统应用的线程。一旦分流，请求分流的线程将释放中央处理节点以进行处理。当完成分流时，数据库加速器驱动器将唤醒请求者以恢复。

通常，应用使用虚拟地址(VA)访问主机系统中的存储器，而数据库加速器引擎使用设备物理地址(DPA)访问存储器。这意味着DBA驱动器负责将分流请求的所有VA参数转换为DPA。数据库加速器驱动器首先通过参考页表来获得对应的系统物理地址(SPA)。然后，将DPA转换为SPA是微不足道的，因为系统BIOS在引导时已将设备存储器的起始SPA存储在PCI设备的BAR寄存器中。

示例43–评估：示例设置

用于评估的系统设置具有在内存数据库管理系统中的嵌入式事务处理性能委员会基准C(TPCC)基准，以及用于在单个服务器中生成扫描工作负载的单独的微基准程序，如图29所示。

在示例中，可以将TPCC基准用于在线事务处理工作负载。它的生成器嵌入在内存数据库管理系统引擎中，以消除通信和会话管理开销，因为总吞吐量通常由会话层而不是内存数据库管理系统引擎约束。为了基准化，可以尝试使TPCC消耗尽可能多的CPU资源。

微基准在CPU上或通过FPGA执行扫描工作负载。它的数据是随机生成和位压缩的。用于扫描的单独数据避免了内存数据库管理系统的内部开销(如被两个不同的工作负载锁定)，并使其可以专注于硬件资源对性能的影响。在示例中，扫描读取20亿个位压缩的整数值，并返回满足过滤条件的行ID。当它在CPU上运行时，相同数量的扫描线程绑定到每个套接字，以防止工作负载在4套接字服务器上的套接字之间倾斜(Intel Xeon Gold 6140@2.30GHz，每个套接字18个内核和6*64GB存储器)。对于数据库加速器分流，每个套接字可以附接一个Ultrascale+FPGA@250MHz，每个FPGA可以放置6个具有4*64GB DDR4 DIMMs@1866MHz的扫描引擎。扫描数据被复制到每个FPGA的存储器中，以模拟DBA分流在数据所驻留的存储器设备中运行。可以比较TPCC工作负载的性能变化，并在两种选择中(在CPU上还是在FPGA上)测量扫描工作负载的延迟和吞吐量可扩展性，同时增加扫描线程的数量。

示例44–评估：结果

可以将数据库加速器结果的概念证明结果与具有72个物理核心的最新4套接字Skylake系统进行比较。

图30表明内存数据库管理系统的系统性能增益。TPCC工作负载在服务器中运行时，扫描微基准在具有不同线程数量的CPU或数据库加速器上运行。结果，随着扫描线程数量的增加，数据库加速器分流显示出较少的性能下降。因此，与所有64个线程在CPU上使用AVX2相比，当所有64个扫描线程都被分流时，数据库加速器分流显示TPCC工作负载中的tpmC(每分钟事务数)提高了115％。结果证实，数据库加速器分流可以通过数据密集型操作减轻CPU冲突，缓存抖动和存储器带宽冲突。

当在没有在先事务处理工作负载的情况下运行扫描时，数据库加速器分流在扫描操作本身中显示出更好的性能。如表2所示，数据库加速器分流显示的延迟(秒/扫描)是AVX2的1.5倍，NO-SIMD是14.3倍。

关于吞吐量(扫描/秒)的可伸缩性，数据库加速器分流显示出非常有希望的性能，如图31所示。实线表示同时执行TPCC工作负载时的扫描吞吐量。虚线表示没有TPCC工作负载的扫描吞吐量。无论是否存在TPCC工作负载，数据库加速器分流都显示出相似的性能，而由于TPCC工作负载的干扰，使用SIMD/NO-SIMD的扫描显示出显着的性能下降。数据库加速器的分流性能优于使用多达16个线程的SIMD/NOSIMD扫描，并且表现出与具有32个线程的SIMD扫描类似的性能。在评估实现中，每个数据库加速器FPGA都有6个扫描引擎和4个DIMM时隙。结果表明，由于FPGA中4个存储信道和资源的有限存储带宽，DBA分流的吞吐量已达到16个线程(每个FPGA4个线程)饱和。每个CPU有6个DDR信道，带宽为128GB/秒，而每个FPGA有4个DDR信道，带宽为60GB/秒。当数据库加速器具有相同数量的线程时，其性能要优于运行SIMD的CPU。在将数据库加速器分流嵌入到真正存储器设备中的SoC(片上系统)实现中，这些限制将得到缓解，并且更高的时钟频率或更多的数据库加速器引擎将进一步提高整体性能。

在示例中，无论是在范围扫描还是inlist扫描中，都具有相似的性能增益，并且无论在位打包压缩中使用的位情况如何，结果都相似。

示例45–示例存储器设备和可访问性

尽管一些示例涉及DRAM-DIMM，并且中央处理器经由存储器映射的I/O访问DRAM上的数据，但是本文描述的特征可以在任何存储器设备上实现并且可以通常经由DDR协议或通过诸如CXL、Gen-Z等接口访问。

因此，数据库加速器引擎可以在存储器设备上实现。这样的存储器设备可以由中央处理单元按字节寻址，并且存储器设备与中央处理单元之间的通信可以经由诸如DDR(例如，DDR4、DDR5等)的通用协议或其他协议(诸如CXL、Gen-Z等)来实现。

因此，可以通过字节寻址技术来检索结果。

特征还可以通过与PCIe连接的存储器设备通过存储器映射I/O来实现。

设备存储器可以包括一个存储器设备或多个存储器设备。

示例46–示例优化

尽管本文使用术语“优化”，但是这些术语并不意味着必须找到最佳可能的解决方案。相反，优化可以采用改进的解决方案的形式(例如，比其他解决方案更好的解决方案)。在某些情况下，所谓的“优化的”数据移动可能根本不涉及任何移动(例如，就地处理源数据)。

示例47–评估的进一步描述

所描述的评估是使用DIMM附接的FPGA进行的。主机系统通过将设备存储器映射到主机存储器的相同地址空间中，通过PCIe MMIO(存储器映射I/O)访问设备存储器。即使在PCIe中MMIO的性能较慢，分流性能也不会受到影响，因为一旦分流操作开始，已实现的分流仅访问FPGA上的本地设备存储器。

数据库加速器分流可以在各种存储器形式因素上实现，各有其优缺点。基于DIMM的存储器非常普遍而且非常快速，但是存储器控制器自然会在存储器信道之间交织数据。因此，即使在两个DIMM上可以交叉一个值，数据库加速器驱动器也可以在处理分流的操作时处理数据交织。

其他可能的接口，例如CXL(计算快速链接)、Gen-Z和OpenCAPI，将启用在IMDBMS中托管列式主存储的新存储器池。尽管这些接口比DIMM引入了更高的延迟，但是这些存储器设备不是主机存储控制器池的一部分，在该池中数据通常以64B粒度进行交织。这允许数据库加速器在其附接的存储器中采用连续数据布局，并且在操作时无需考虑跨存储信道的数据交织。虚拟地址空间中连续数据的物理地址空间中可能存在非连续性。数据库加速器分流可以通过构建页面转换表来提供所谓的“分散和收集”功能。

在云环境中，内存数据库管理系统的微服务可以根据其角色(如计算或存储)分布在多个节点(服务器)之间。可以轻松扩展用于处理前端事务(或查询)的计算节点，以处理更多工作负载，但是不能简单地扩展存储节点。数据库加速器分流可以有助于解决云中的这种情况。

示例48–示例优点

描述的分流技术的可能优点包括当在内存数据库中执行数据库操作时改善的总体性能。

在没有数据库加速器的情况下，可以在处理器和DRAM之间形成存储器墙，从而导致延迟时间长、带宽少和功耗大。内存数据库可能涉及大量的数据访问，从而导致存储器瓶颈增加，导致更多的缓存崩溃，传输数据时出现存储器绑定条件(CPU暂停)等。

如本文所述，可以使用近存储器处理将就内存数据库环境中的存储器访问而言昂贵的数据库操作分流到数据所驻留的位置(例如，存储器设备)。尽管在概念验证中使用了扫描(例如，范围/列表内搜索)和查找(例如，具有一定范围的行的批检索，以进行聚合)，但是任何数据库操作都可以带来好处。结果是更少的CPU使用率，更少的缓存未命中以及更少的存储器绑定条件。一般效果在图32中示出。释放了CPU到存储器的数据路径，以进行分流数据库操作以外的其他处理。

在本文的任何示例中，可以在诸如德国Walldorf的SAP SE的HANA的内存数据库管理系统或其他内存中系统中实现该技术。可以放置一个驱动器来处理各种硬件实现，同时维护抽象层(例如，应用编程接口)，该层允许应用以可预测的统一方式利用DBA，而与基本硬件实现无关。

尽管示例中显示了范围和inlist数据库操作，但是可以实现其他数据库操作。可以通过分流API函数将任何此类数据库操作分流到DBA。

观察表明，像OLTP这样的任务关键型工作负载可能会受到大规模扫描等数据密集型操作的干扰。近存储器数据库加速器(DBA)可以改善(例如避免)数据移动，并且在存储器设备中执行昂贵的扫描操作可以减轻CPU负载、缓存冲突和主机存储器带宽瓶颈。为了确认其可行性，使用带有DIMM的FPGA来实现示例分流系统。结果表明，在分流数据密集型操作时，OLTP工作负载的性能提高了2倍以上，并且在分流扫描工作负载中具有更高或类似的吞吐量可扩展性，具有更好的延迟。

聚合是IMDBMS中的另一种数据密集型操作，根据工作负载，其消耗大约20-50％的CPU使用率。它读取海量数据，但大多数数据不会在后续处理步骤中重复使用。正在研究聚集时的DBA分流作为下一个目标操作。

在本文的任何示例中，可以通过与存储源数据的硬件相关联或与之集成的硬件对源数据在原位(就地，而数据驻留在存储器中)上执行操作。

示例49–示例计算系统

图33描绘了可以实现所描述的创新的合适的计算系统3300的示例。由于可以在各种计算系统中实现本创新，因此计算系统3300无意建议对本公开的使用范围或功能进行任何限制。

参照图33，计算系统3300包括一个或多个处理单元3310、3315和存储器3320、3325。在图33中，该基本配置3330包括在虚线内。处理单元3310、3315执行计算机可执行指令，诸如用于实现本文示例中描述的特征。处理单元可以是通用中央处理单元(CPU)、专用集成电路(ASIC)中的处理器或任何其他类型的处理器。在多处理系统中，多个处理单元执行计算机可执行指令以增加处理能力。例如，图33示出中央处理单元3310以及图形处理单元或协处理单元3315。有形存储器3320、3325可以是易失性存储器(例如，寄存器、高速缓存、RAM)、非易失性存储器(例如，ROM、EEPROM、闪存等)，或两者的某种组合，由处理单元3310、3315可访问。存储器3320、3325以适于由处理单元3310、3315执行的计算机可执行指令的形式存储实现本文描述的一种或多种创新的软件3380。

在本文描述的任何示例中，可以包括专用存储器硬件以实现DBA功能。

计算系统3300可以具有附加特征。例如，计算系统3300包括存储设备3340、一个或多个输入设备3350、一个或多个输出设备3360以及一个或多个通信连接3370，包括输入设备、输出设备和用于与用户交互的通信连接。诸如总线、控制器或网络的互连机制(未示出)将计算系统3300的组件互连。通常，操作系统软件(未示出)为在计算系统3300中执行的其他软件提供操作环境，并且协调计算系统3300的组件的活动。

有形存储器3340可以是可移动的或不可移动的，并且包括可用于以非暂时性方式存储信息并且可以在计算系统3300内访问的磁盘、磁带或盒带、CD-ROM、DVD或任何其他介质。存储器3340存储用于实现本文描述的一种或多种创新的软件3380的指令。

输入设备(或多个)3350可以是诸如键盘、鼠标、笔或轨迹球的输入设备，语音输入设备，扫描设备，触摸设备(例如，触摸板、显示器等)或提供输入到计算系统3300的其他设备。输出设备3360可以是显示器、打印机，扬声器、CD刻录机或提供计算系统3300输出的其他设备。

通信连接(或多个)3370使得能够通过通信介质与另一计算实体进行通信。通信介质在调制数据信号中传达诸如计算机可执行指令、音频或视频输入或输出或其他数据的信息。调制数据信号是具有以在信号中编码信息的方式设置和改变的一种或多种特征的信号。作为示例而非限制，通信介质可以使用电、光、RF或其他载体。

可以在目标真实或虚拟处理器上的计算系统中执行(例如，最终在一个或多个硬件处理器上执行)的计算机可执行指令(诸如程序模块中包括的那些指令)的上下文中描述本发明。通常，程序模块或组件包括执行特定任务或实现特定抽象数据类型的例程、程序、库、对象、类、组件、数据结构等。在各个实施例中，程序模块的功能可以根据需要在程序模块之间进行组合或拆分。用于程序模块的计算机可执行指令可以在本地或分布式计算系统内执行。

为了呈现，详细描述使用诸如“确定”和“使用”的术语来描述计算系统中的计算机操作。这些术语是对计算机执行的操作的高级描述，不应与人类执行的操作相混淆。与这些术语相对应的实际计算机操作根据实现方式而变化。

示例50–计算机可读介质

本文中的任何计算机可读介质都可以是非暂时性的(例如，诸如DRAM或SRAM的易失性存储器，诸如磁性存储、光学存储等的非易失性存储器)和/或有形的。可以通过在一个或多个计算机可读介质(例如，计算机可读存储介质或其他有形介质)中存储来实现本文描述的任何存储动作。被描述为存储的任何事物(例如，在实现期间创建和使用的数据)可以被存储在一个或多个计算机可读介质(例如，计算机可读存储介质或其他有形介质)中。计算机可读介质可以限于不包括信号的实现。

本文描述的任何方法都可以由一个或多个计算机可读介质(例如，计算机可读存储介质或其他有形介质)或一个中或多个计算机可读存储设备(例如，存储器、磁存储、光存储等)的计算机可执行指令来实现(例如，存储在其上，在其上编码等)。这样的指令可以使计算系统执行该方法。本文描述的技术可以以多种编程语言来实现。

示例51–示例云计算环境

图34描绘了可以实现所描述的技术的示例云计算环境3400。云计算环境3400包括云计算服务3410。云计算服务3410可以包括各种类型的云计算资源，诸如计算机服务器、数据存储库、网络资源等。云计算服务3410可以位于中央(例如，由企业或组织的数据中心提供)或分布式(例如，由位于不同位置(诸如不同数据中心和/或位于不同城市或国家/地区)的各种计算资源提供)。

云计算服务3410被诸如计算设备3420、3422和3424的各种类型的计算设备(例如，客户端计算设备)利用。例如，计算设备(例如，3420、3422和3424)可以是计算机(例如，台式机或笔记本电脑)、移动设备(例如，平板电脑或智能手机)或其他类型的计算设备。例如，计算设备(例如3420、3422和3424)可以利用云计算服务3410来执行计算操作(例如，数据处理、数据存储等)。

在实践中，可以支持基于云、基于本地或混合的方案。

示例52–示例实现

尽管为了方便呈现以特定的顺序顺序描述了一些所公开的方法的操作，但是这种描述方式包括重新安排，除非本文阐述的特定语言要求特定的顺序。例如，顺序描述的操作在某些情况下可以重新安排或同时执行。

示例53–其他示例

可以实现以下任何条款：

条款1.一种系统，包括：

在包括存储在设备存储器中的源数据的内存数据库管理系统环境中，多个数据库加速器引擎被配置为直接对源数据原位执行数据库操作。

条款2.根据条款1所述的系统，其中：

数据库加速器引擎包括在近存储器处理器上执行的可执行数据库加速器引擎。

条款3.根据条款1-2中任一项所述的系统，其中：

数据库加速器引擎可操作以从中央处理单元接收请求；

数据库加速器引擎由中央处理单元外部的硬件执行；以及

请求指定数据库操作。

条款4.根据条款1所述的系统，其中：

数据库加速器引擎在与中央处理单元分开的近存储器处理器上执行。

条款5.根据条款1-4中任一项所述的系统，其中：

中央处理单元经由字节寻址技术检索由数据库加速器引擎计算的数据库操作的结果。

条款6.根据条款1-5中任一项所述的系统，其中：

中央处理单元经由DDR协议检索由数据库加速器引擎计算的数据库操作的结果。

条款7.根据条款1-6中任一项所述的系统，其中：

中央处理单元经由存储器映射I/O检索由数据库加速器引擎计算的数据库操作的结果。

条款8.根据条款1-7中任一项所述的系统，其中：

数据库加速器引擎可操作以从中央处理单元接收请求；

数据库加速器引擎由与中央处理单元分开的访问源数据的硬件来执行；以及

请求指定数据库操作。

条款9.根据条款1-8中任何一项所述的系统，其中：

数据库加速器引擎可操作以从中央处理单元接收请求；

数据库加速器引擎由与中央处理单元分开的访问源数据的近存储器硬件来实现；以及

请求指定数据库操作。

条款10.一种方法，包括：

在内存数据库管理系统环境中，接收对存储在设备存储器中的源数据中表示的多个值执行一系列数据库操作的请求；以及

在设备存储器中原位执行一系列数据库操作。

条款11.根据条款10所述的方法，其中：

从中央处理单元接收到将一系列数据库操作分流到多个数据库加速器引擎的请求。

条款12.根据条款10-11中任一项所述的方法，还包括：

通过存储器映射I/O将一系列数据库操作的结果检索到中央处理单元。

条款13.一种系统，包括：

在包括存储在设备存储器中的源数据的内存数据库管理系统环境中，多个数据库加速器引擎，被配置为直接对源数据原位执行数据库操作；以及

处理器，被配置为将数据库操作分流到数据库加速器引擎并从中检索结果。

条款14.根据条款8所述的系统，还包括：

硬件处理器，被配置为将数据库操作分流到数据库加速器引擎并从中检索结果。

条款15.一种基本如所示出和描述的方法。

条款16.一种基本如所示出和描述的系统。

示例54–其他进一步的示例

可以实现以下任何条款：

条款1.一种方法，包括：

在内存数据库管理系统环境中，接收对在源数据中表示的多个值执行数据库操作的请求，其中，源数据被存储在近存储器数据库加速器的设备存储器中；

将数据库操作分流到近存储器数据库加速器；以及

从近存储器数据库加速器接收数据库操作的结果可用的指示。

条款2.根据权利要求1所述的方法，其中：

在源数据中表示的多个值以压缩形式存储在内存数据库管理系统的主存储中。

条款3.根据条款1-2中任一项所述的方法，还包括：

在接收请求之前，将源数据存储在内存数据库管理系统配置信息所指定的近存储器数据库加速器的设备存储器中。

条款4.根据条款1-3中任一项所述的方法，其中：

通过用于扫描数据库操作的应用编程接口(API)从内存数据库管理系统接收请求。

条款5.根据条款1-4中任一项所述的方法，其中：

作为在内存数据库管理系统内确定请求的数据库操作要被分流的结果，从内存数据库管理系统接收请求。

条款6.根据条款1-5中任一项所述的方法，其中：

源数据包括存储在近存储器数据库加速器的设备存储器中的内存数据库分量；以及

近存储器数据库加速器对存储在近存储器数据库加速器的设备存储器中的内存数据库分量执行数据库操作。

条款7.根据根据权利要求6所述的方法，其中：

源数据被压缩；以及

请求包括源数据的压缩信息，近存储器数据库加速器使用压缩信息对源数据进行解压缩。

条款8.根据权利要求7所述的方法，其中：

根据位打包压缩格式压缩源数据，并且压缩信息指定位打包压缩格式的位数。

条款9.根据条款1-8中任一项所述的方法，其中：

近存储器数据库加速器包括与设备存储器共驻留并被配置为执行数据库操作的数据库加速器引擎；以及

设备存储器与中央处理节点分开。

条款10.根据条款1-9中任一项所述的方法，其中：

在中央处理单元处接收请求；

设备存储器由中央处理单元直接可访问；以及

近存储器数据库加速器包括与中央处理单元分开的数据库加速器引擎，其中数据库加速器引擎被配置为执行数据库操作。

条款11.根据根据权利要求10所述的方法，其中：

分流减轻用于处理除数据库操作之外的中央处理单元到存储器数据路径。

条款12.根据条款1-11中任一项所述的方法，其中：

源数据包括列格式的数据库表值；

数据库操作包括对指定谓词的表扫描；以及

结果指示指定谓词对于哪些数据库列值有效。

条款13.根据条款1-12中任一项所述的方法，其中：

请求是由近存储器数据库加速器驱动器从内存数据库应用接收，近存储器数据库加速器驱动器代表内存数据库应用与近存储器数据库加速器交互。

条款14.根据条款1-13中任一项所述的方法，其中：

数据库操作由近存储器数据库加速器在设备存储器中原位执行。

条款15.根据条款1-14中任一项所述的方法，还包括：

将结果从设备存储器检索到中央处理单元，其中，检索绕过数据库加速器。

条款16.根据条款1-15中的任一项所述的方法，其中，请求包括指定输出缓冲区的大小的容量参数，并且所述方法还包括：

在近存储器数据库加速器中，基于容量参数检测输出缓冲区的大小不足以保存结果；以及

响应于检测到输出缓冲区的大小不足，返回部分完成的结果。

条款17.一种系统，包括：

一个或多个处理单元；

主存储器或扩展存储器，一个或多个处理单元直接可访问；以及

近存储器数据库加速器驱动器，被配置为接收对存储在近存储器数据库加速器的设备存储器中的源数据执行数据库操作的请求，近存储器数据库加速器包括与一个或多个处理单元分开的至少一个数据库加速器引擎，将数据库操作分流到近存储器数据库加速器，以由与一个或多个处理单元分开的至少一个数据库加速器引擎执行，以及从近存储器数据库加速器接收数据库操作的结果可用的指示；

其中，主存储器或扩展存储器包括近存储器数据库加速器的设备存储器。

条款18.根据权利要求17所述的系统，其中：

近存储器数据库加速器驱动器被配置为：如果结果对于在请求中指定的输出缓冲区容量太大，则返回部分完成结果。

条款19.根据条款17-18中任一项所述的系统，其中：

一个或多个处理单元经由存储器映射I/O检索由至少一个数据库加速器引擎计算的数据库操作的结果。

条款20.一种或多种计算机可读介质，包括计算机可执行指令，该计算机可执行指令在被执行时使计算系统执行一种方法，所述方法包括：

从内存数据库管理系统接收应用编程接口(API)调用，请求将数据库操作分流到近存储器数据库加速器，其中，对根据位打包压缩格式压缩的数据库表的内存列执行数据库操作，API调用指定位数参数；

响应于API调用，向近存储器数据库加速器发送请求，其中，发送包括：中继位数参数，并且近存储器数据库加速器以位数参数执行数据库操作；

从近存储器数据库加速器接收数据库操作已经完成的指示；以及

通知内存数据库管理系统数据库操作已经完成。

条款21.一种或多种计算机可读介质，包括计算机可执行指令，计算机可执行指令在被执行时使计算系统执行条款1-16中任一项所述的方法。

示例55–示例替代

来自任何示例的技术可以与在任何一个或多个其他示例中描述的技术结合。鉴于可以应用所公开技术的原理的许多可能的实施例，应当认识到，所示出的实施例是所公开技术的示例，并且不应被视为对所公开技术的范围的限制。而是，所公开的技术的范围包括所附权利要求的范围和精神所覆盖的范围。

Claims (20)

1.一种方法，包括：

在内存数据库管理系统环境中，接收对在源数据中表示的多个值执行数据库操作的请求，其中，源数据被存储在近存储器数据库加速器的设备存储器中；

将数据库操作分流到近存储器数据库加速器；以及

从近存储器数据库加速器接收数据库操作的结果可用的指示。

2.根据权利要求1所述的方法，其中：

在源数据中表示的多个值以压缩形式被存储在内存数据库管理系统的主存储中。

3.根据权利要求1所述的方法，还包括：

在接收请求之前，将源数据存储在内存数据库管理系统配置信息所指定的近存储器数据库加速器的设备存储器中。

4.根据权利要求1所述的方法，其中：

通过用于扫描数据库操作的应用编程接口(API)从内存数据库管理系统接收请求。

5.根据权利要求1所述的方法，其中：

作为在内存数据库管理系统内确定请求的数据库操作要被分流的结果，从内存数据库管理系统接收请求。

6.根据权利要求1所述的方法，其中：

源数据包括存储在近存储器数据库加速器的设备存储器中的内存数据库分量；以及

近存储器数据库加速器对存储在近存储器数据库加速器的设备存储器中的内存数据库分量执行数据库操作。

7.根据权利要求6所述的方法，其中：

源数据被压缩；以及

请求包括源数据的压缩信息，由近存储器数据库加速器使用压缩信息对源数据进行解压缩。

8.根据权利要求7所述的方法，其中：

根据位打包压缩格式压缩源数据，并且压缩信息指定位打包压缩格式的位数。

9.根据权利要求1所述的方法，其中：

近存储器数据库加速器包括数据库加速器引擎，其与设备存储器共驻留并被配置为执行数据库操作；以及

设备存储器与中央处理节点分开。

10.根据权利要求1所述的方法，其中：

在中央处理单元处接收请求；

设备存储器由中央处理单元直接可访问；以及

近存储器数据库加速器包括与中央处理单元分开的数据库加速器引擎，其中数据库加速器引擎被配置为执行数据库操作。

11.根据权利要求10所述的方法，其中：

分流减轻用于处理除数据库操作之外的中央处理单元到存储器数据路径。

12.根据权利要求1所述的方法，其中：

源数据包括列格式的数据库表值；

数据库操作包括对指定谓词的表扫描；以及

结果指示指定谓词对于哪些数据库列值有效。

13.根据权利要求1所述的方法，其中：

请求是由近存储器数据库加速器驱动器从内存数据库应用接收的，近存储器数据库加速器驱动器代表内存数据库应用与近存储器数据库加速器交互。

14.根据权利要求1所述的方法，其中：

数据库操作由近存储器数据库加速器在设备存储器中原位执行。

15.根据权利要求1所述的方法，还包括：

将结果从设备存储器检索到中央处理单元，其中，检索绕过数据库加速器。

16.根据权利要求1所述的方法，其中，请求包括指定输出缓冲区的大小的容量参数，并且所述方法还包括：

在近存储器数据库加速器中，基于容量参数检测输出缓冲区的大小不足以保存结果；以及

响应于检测到输出缓冲区的大小不足，返回部分完成的结果。

17.一种系统，包括：

一个或多个处理单元；

一个或多个处理单元直接可访问的主存储器或扩展存储器；以及

近存储器数据库加速器驱动器，被配置为接收对存储在近存储器数据库加速器的设备存储器中的源数据执行数据库操作的请求，将数据库操作分流到近存储器数据库加速器以由与一个或多个处理单元分开的至少一个数据库加速器引擎执行，以及从近存储器数据库加速器接收数据库操作的结果可用的指示，近存储器数据库加速器包括与一个或多个处理单元分开的至少一个数据库加速器引擎；

其中，主存储器或扩展存储器包括近存储器数据库加速器的设备存储器。

18.根据权利要求17所述的系统，其中：

近存储器数据库加速器驱动器被配置为：如果结果对于在请求中指定的输出缓冲区容量太大，则返回部分完成结果。

19.根据权利要求17所述的系统，其中：

一个或多个处理单元经由存储器映射I/O检索由至少一个数据库加速器引擎计算的数据库操作的结果。

20.一个或多个计算机可读介质，包括计算机可执行指令，所述计算机可执行指令在被执行时使计算系统执行一种方法，所述方法包括：

从内存数据库管理系统接收应用编程接口(API)调用，请求将数据库操作分流到近存储器数据库加速器，其中，对根据位打包压缩格式压缩的数据库表的内存列执行数据库操作，API调用指定位数参数；

响应于API调用，向近存储器数据库加速器发送请求，其中，发送包括中继位数参数，并且近存储器数据库加速器利用位数参数执行数据库操作；

从近存储器数据库加速器接收数据库操作已经完成的指示；以及

通知内存数据库管理系统数据库操作已经完成。

Images