CN106462578B - 数据库条目查询和更新的方法 - Google Patents

Abstract

本发明涉及一种用于查询和更新数据库条目的方法，所述数据库包括用于存储数据库条目的主数据结构和用于存储新条目的增量数据结构，所述方法包括以下步骤：接收(101)多个数据库查询；聚合(103)所述接收的多个数据库查询以获得批量数据库查询；使用所述批量数据库查询执行(105)所述主数据结构的共享扫描，其中所述主数据结构中的所述数据库条目结合所述批量数据库查询中的每个数据库查询进行查询；在所述执行(105)所述共享扫描的步骤之后，合并(107)所述主数据结构与所述增量数据结构以随着所述接收的新条目更新所述主数据结构。

Description

数据库条目查询和更新的方法

背景技术

已经开发用来查询数据库条目的技术和系统有很多。最重要的是，自八十年代以来，已经对主内存数据库系统进行了大量研究。代表性的例子有：微软的Hekaton【1】、甲骨文的TimesTen【2】和SAP的Hana【3】产品。这些系统通常在点查询和点更新方面或者在复杂查询方面表现很好，但是很少在这两方面都表现很好。例如，Hekaton和TimesTen在复杂查询方面可能表现不好。

近来，很多技术已经在研究文献中提出，用来专门解决混合工作负载。其中一个例子是超级系统【4】，其采用“写时拷贝”硬件原语以有效地分离更新和查询处理同时实现良好隔离。另一方法是ClockScan【5】。ClockScan方法以共享扫描为基础，这些共享扫描已经在数据仓库【6】中的复杂查询处理的环境中广泛探讨过。然而，迄今为止，以共享扫描为基础的系统在点查询和更新方面表现不好。

另一种常用来处理复杂查询的技术是垂直分区。这一技术已经在设计诸如MonetDBm【8】和C-Store【9】等所谓的列存储时采用。

发明内容

本发明的目标是提供一种查询和更新数据库的有效概念。

该目的由独立权利要求的特征来实现。其它实施方式从从属权利要求、描述内容和附图中显而易见。

根据第一方面，本发明涉及一种用于查询和更新数据库条目的方法，所述数据库包括用于存储数据库条目的主数据结构和用于存储和/或接收新条目的增量数据结构，所述方法包括以下步骤：接收多个数据库查询；聚合所述接收的多个数据库查询以获得批量数据库查询；使用所述批量数据库查询执行所述主数据结构的共享扫描，其中所述主数据结构中的所述数据库条目结合所述批量数据库查询中的每个数据库查询进行查询；以及，在所述执行所述共享扫描的步骤之后，合并所述主数据结构与所述增量数据结构以随着所述新条目更新所述主数据结构。

根据所述第一方面，在所述方法的第一可能实施形式中，所述方法包括接收又一多个数据库查询，其中在所述合并所述主数据结构与所述增量数据结构以随着所述新条目更新所述主数据结构的步骤之后执行以下步骤：聚合所述接收的又一多个数据库查询以获得又一批量数据库查询；使用所述又一批量数据库查询执行所述主数据结构的又一共享扫描，其中所述主数据结构中的所述数据库条目结合所述又一批量数据库查询中的每个查询进行查询；在执行所述又一共享扫描之后，合并所述主数据结构与所述增量数据结构以随着所述增量数据结构中存储的或所述增量数据结构接收的新条目更新所述主数据结构。

根据所述第一方面，在所述方法的第二可能实施形式中，所述执行所述共享扫描和合并所述主数据结构与所述增量数据结构的步骤在不同的时间点执行。

根据所述第一方面，在所述方法的第三可能实施形式中，所述执行所述共享扫描和合并所述主数据结构与所述增量数据结构的步骤在预定时间点执行。

根据所述第一方面，在所述方法的第四可能实施形式中，所述方法包括建立不同类别的数据库查询的队列，尤其是建立点查询或分析查询的队列。

根据所述第四可能实施形式，在所述方法的第五可能实施形式中，所述方法包括根据每类数据库查询的响应时间需求调度所述批量数据库查询中的所述类别的数据库查询。

根据所述第一方面，在所述方法的第六可能实施形式中，所述方法包括接收多个新条目，聚合接收的多个新条目以获得批量新条目，以及在更新步骤中随着所述批量新条目更新所述增量数据结构。

根据所述第一方面，在所述方法的第七可能实施形式中，通过使用索引或至少一个哈希表执行：所述共享扫描或所述主数据结构与所述增量数据结构的所述合并或随着新条目更新所述增量数据结构。

根据所述第一方面，在所述方法的第八可能实施形式中，所述方法包括接收数据库查询，确定所述接收的数据库查询的一个类别，以及根据所述确定的类别，将所述数据库查询包括在所述批量批数据库查询中，或根据哈希表使用所述接收的数据库查询直接查询所述主数据结构。

根据所述第八可能实施形式，在所述方法的第九可能实施形式中，所述方法包括：执行所述批量数据库查询以及以交叉方式或以共享方式直接查询所述主数据结构。

根据所述第一方面，在所述方法的第十可能实施形式中，所述方法包括执行所述批量数据库查询的快照隔离。

根据所述第一方面，在所述方法的第十一可能实施形式中，所述方法包括接收新条目用于更新所述增量数据结构。

根据第二方面，本发明涉及一种计算机程序，所述计算机程序在计算机上运行时用于执行所述第一方面或所述第一方面的所述实施形式之一的所述方法。

根据第三方面，本发明涉及一种数据处理系统，包括：数据库，所述数据库包括用于存储数据库条目的主数据结构和用于存储和/或接收新条目的增量数据结构；通信接口，用于接收多个数据库查询以及用于接收新条目；以及处理器，其中所述处理器用于：聚合所述接收的多个数据库查询以获得批量数据库查询；使用所述批量数据库查询执行所述主数据结构的共享扫描，其中所述主数据结构中的所述数据库条目结合所述批量数据库查询中的每个数据库查询进行查询；以及，在所述执行所述共享扫描的步骤之后，合并所述主数据结构与所述增量数据结构以随着所述新条目更新所述主数据结构。

所述数据处理系统可执行所述方法。所述数据处理系统的更多特征可直接由所述方法的功能产生。

根据所述第二方面，在所述系统的第一可能实施形式中，所述处理器用于在不同时间点或在预定时间点执行所述共享扫描以及合并所述主数据结构与所述增量数据结构。

根据所述第二方面，在所述系统的第二可能实施形式中，所述数据处理系统，尤其是所述处理器，可编程地用于执行所述第二方面的所述计算机程序。

根据一些实施形式，所述系统，尤其是所述处理器，用于执行根据所述第一方面或根据所述第一方面的任一实施形式的所述方法。

所述方法步骤以电子方式自动执行。

本发明可以在硬件和/或软件中实施。

附图说明

更多实施形式将结合以下附图进行描述，其中：

图1所示为根据一实施形式的一种用于查询和更新数据库条目的方法的图；

图2所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图；

图3a所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图；

图3b所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图；

图4所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图；

图5所示为根据一实施形式的数据库更新的图；

图6所示为根据一实施形式的数据库更新和查询的图；

图7所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图；

图8所示为根据一实施形式的哈希表的图；

图9所示为根据一实施形式的数据库更新和查询的图；

图10所示为根据一实施形式的单指令流多数据流(single instructionmultiple data，SIMD)处理方案的图；

图11所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图；

图12所示为根据一实施形式的一种用于查询和更新数据库条目的系统的性能图；

图13所示为根据一实施形式的一种用于查询和更新数据库条目的系统的性能图；以及

图14所示为根据一实施形式的一种用于查询和更新数据库条目的系统的性能图。

具体实施方式

图1所示为一种用于查询和更新数据库条目的方法的图。所述数据库包括用于存储数据库条目的主数据结构和用于存储新条目的增量数据结构。所述方法包括以下步骤：接收101多个数据库查询；聚合103所接收的多个数据库查询以获得批量数据库查询；使用所述批量数据库查询执行105主数据结构的共享扫描，其中主数据结构中的数据库条目结合批量数据库查询中的每个数据库查询进行查询；在执行105共享扫描的步骤之后，合并107主数据结构与增量数据结构以随着所接收的新条目更新主数据结构。

图2所示为一种数据处理系统的图，包括：数据库201，数据库201包括用于存储数据库条目的主数据结构203和用于存储和/或接收新条目的增量数据结构205；通信接口207，用于接收多个数据库查询以及用于接收新条目；以及处理器209，其中所述处理器用于：聚合所接收的多个数据库查询以获得批量数据库查询；使用所述数据库查询执行主数据结构的共享扫描，其中主数据结构中的数据库条目结合批量数据库查询中的每个数据库查询进行查询；以及，在共享扫描的步骤之后，合并主数据结构203与增量数据结构205以随着新条目更新主数据结构203。

下文中将描述所述方法和系统的更多实施例和实施形式。

一些实施形式解决以下问题：

·处理点查询、更新和复杂分析查询的混合工作负载。

·实现高吞吐量并达到响应时间目标。

根据一实施形式，提供一种处理高吞吐量工作负载的技术，这些高吞吐量工作负载由以下三种操作组成：

·点查询：根据条目或记录的键访问条目或记录。

·点更新：根据条目或记录的键更新条目或记录。

·复杂查询：按照不同标准对大量条目或记录进行聚合。

目标是并发处理这些类型的操作，这样在单机进行范围在每秒10万个点查询和更新以及每秒100个复杂查询的处理时实现极高吞吐量。此外，系统能够保持不同级别的一致性，而且系统必须履行响应时间保证和其它服务水平协议(service-level agreement，SLA)。

根据一实施形式，将数据装入主内存中和/或将数据划分，使得在每个分区上单独进行查询和更新，在独立处理层处聚合结果，以及将每个分区装入单机的主内存中。

根据一实施形式，通过索引(例如，哈希表)执行点查询和更新，通过共享扫描执行复杂查询，通过预编制一个各种操作在其中执行的计划来避免同步成本。预编制的计划可视隔离水平而定并可调整到SLA和具体工作负载(每种操作的量)。例如，随着点查询和更新的负载不断增加，这些操作的执行接收更多资源。

图3a给出了根据一实施形式的系统部件的概述。左侧是缓冲区，缓冲区保存针对复杂查询而处理的结果。可通过数据使用共享扫描执行这些查询的谓词和简单聚合。在上部是新到达的复杂查询队列。在又一次共享扫描期间，例如，下一次共享扫描期间，可处理这些新到达的复杂查询队列。在底部是新到达的点查询和更新操作队列。可使用哈希表根据这些查询和更新的谓词中使用的键执行这些查询和更新。作为共享扫描的一部分，可以按照处理复杂查询的方式处理没有被索引的点查询和更新。

根据一实施形式，该方法能够预先安排复杂查询、点查询和更新。图3a所示为能够批量执行复杂查询、点查询和更新以满足服务水平协议(service-level agreement，SLA)的场景。

图3b给出了根据一实施形式的系统部件的概观。在顶部是缓冲区，缓冲区保存针对复杂查询而处理的结果。可通过数据使用共享扫描执行这些查询的谓词和简单聚合。在底部是新到达的点查询和更新操作队列。可使用哈希表根据这些查询和更新的谓词中使用的键执行这些查询和更新。作为共享扫描的一部分，可以按照处理复杂查询的方式处理没有被索引的点查询和更新。图3b描绘的方法还适用于单独扫描，且可选地进行使用。

根据一实施形式，该方法能够预先安排复杂查询、点查询和更新。图3b所示为以下场景：一旦查询到达就执行它们，但是批量执行点查询和更新以满足服务水平协议。图3b示出了在共享扫描期间，一个接着一个处理每个数据条目的查询。

操作安排还会影响所支持的隔离水平。如果同样批量处理查询，那么如【5】中所示，能够实现快照隔离。传统方案通过监控对数据的每个访问操作来同步各种操作，与此相比，我们系统的关键理念是以不相冲突的方式提前安排操作。此外，以与在传统数据库系统中相同的方式实施通过锁定的可串行性或乐观并发控制。

这种系统的一个具体创新在于，针对复杂连接查询，我们预计算维表和事实表之间连接的影响，在事实表上生成一组键以过滤出所有与复杂查询相关的元组。这种预计算在处理节点的隔离层进行，隔离层包含维表中的副本，这些维表被认为很少更新。这样，这种预计算不消耗共享扫描/哈希表中的资源，这是整个系统的瓶颈。已经在半连接减振器【7】的环境中探讨了类似的观点。

根据一些实施形式，提供了以下要点：

1.分别安排不同类别的操作并且批量执行以满足每类操作的具体响应时间、吞吐量和一致性/隔离要求。

2.使用共享扫描和索引的组合来执行每种操作中的批量操作。

3.设法交叉执行不同类别的操作中的批量操作。

根据一些实施形式，有可能为每类操作，即，点查询、点更新和分析查询，建立队列。随后，根据这类操作的响应时间目标安排整批操作的执行。例如，与分析查询一样对所有点查询执行两次，这些点查询排列在“点查询队列”中。这样，点查询的更严格响应时间目标得以实现。此外，可以使用最佳可能方法来执行每类操作，例如分析查询的共享扫描和点查询的哈希表，而且这种执行可交叉进行。也就是说，以共享方式一起执行点查询和点更新，从而使用同一哈希表并改进哈希表查找的缓存局部性。

根据一些实施形式，该技术可作为运动分析(Analytics in Motion，AIM)系统的一部分来实施。AIM是一种实时决策系统，其是电信运营商的CRM系统的一部分。子系统需要维持同时来自计费系统和CRM系统用户提交的若干不同查询的混合工作负载。子系统被划分为两部分。第一，流和事件处理系统(Stream and Event Processing System，SEP)，以适于快速评估业务规则的方式处理和存储事件；第二，实时分析系统(Real-time AnalyticsSystem，RTA)，评估更复杂的分析查询。AIM不遵循传统的数据仓库技术，但是能够使RTA直接访问SEP的存储，并因此使其能够实时地回复分析查询。在传统数据仓库技术中，RTA是通过连续ETL(Extract,Transform,Load，提取、变换、加载)操作由SEP导入的。

为了验证AIM系统的性能，可以使用两个基准：(a)SEP基准和(b)RTA基准。在AIM中同时运行这两个基准产生如本文档的问题陈述中所定义的混合工作负载。SEP基准和RTA基准之前都已被用来验证另一方法：“一种通过分离计算和状态存储结合实时分析进行可扩展流处理的方法(AMethod for Scalable Stream Processing Combined with Real-TimeAnalytics by Separating Computation and State Storage)”。

本文引用的以下参考文献以引入的方式并入本文本中：

1.Cristian Diaconu、Craig Freedman、Erik Ismert、Larson、PravinMittal、Ryan Stonecipher、Nitin Verma、Mike Zwilling：Hekaton：SQL服务器的内存优化的OLTP引擎。2013年的SIGMOD会议：1243至1254页。

2.Times-Ten团队：客户事务的内存数据管理，Times-Ten方法。1999年的SIGMOD会议：528至529页。

3.Juchang Lee、Michael Muehle、Norman May、Franz Faerber、Vishal Sikka、Hasso Plattner、Jens Krueger、Martin Grund：SAP HANA中的高性能事务处理。IEEE DataEng.Bull.36(2)：28至33页(2013年)。

4.Alfons Kemper、Thomas Neumann、Jan Finis、Florian Funke、Viktor Leis、Henrik Mühe、Tobias Mühlbauer、Wolf混合OLTP和OLAP主内存数据库系统HyPer中的处理。IEEE Data Eng.Bull。36(2)：(2013年)41至47页。

5.Philipp Unterbrunner、Georgios Giannikis、Gustavo Alonso、DietmarFauser、Donald Kossmann：不可预测工作负载的可预测性能。PVLDB 2(1)：706至717页(2009年)。

6.Phillip M.Fernandez、Donovan A.Schneider：数据仓库的细节(以及之间的一切)。1996年的SIGMOD会议：541页。

7.Konrad Stocker、Donald Kossmann、Reinhard Braumandl、Alfons Kemper：将半连接减振器集成到最新查询处理器中。2001年的ICDE：575至584页。

8.Peter A.Boncz、Martin L.Kersten和Stefan Manegold：打破MonetDBm中的内存墙。ACM通信51，12页(2008年12月)。

9.Mike Stonebraker、Daniel Abadi、Adam Batkin、Xuedong Chen、MitchCherniack、Miguel Ferreira、Edmond Lau、Amerson Lin、Sam Madden,Elizabeth O'Neil、Pat O'Neil、Alex Rasin、Nga Tran and Stan Zdonik：C-Store：面向列的DBMS。2005年的VLDB会议会刊，553至564页。

下文结合涉及事件处理的运动分析以及高频流的实时分析的实施形式来描述方法和系统的更多实施例和实施形式。

如今，许多企业收集大量需要聚合和分析的数据以获得对他们业务的实时洞察力。如果决策支持需要实时提供而且事件率巨大，那么传统数据仓库方法达到其上限，这要求一类新的集成方案。我们提出AIM，一种将流处理和决策支持集成在相同的分布式键值存储上的架构。我们研究不同的设计方案并基于这些研究的结果针对电信行业中的具体工作负载实施一种系统。所实施的系统将分析数据从30GB扩展到多达300GB，因此适应了高容量事件流，范围从每秒1万个事件到多达10万个事件，并且能够在响应时间小于100毫秒的情况下每秒回复多达100个实时分析查询。

电信行业中目前许多以数据为中心的流以高容量事件流(通常表示为详细条目或记录的变体)开始，这些事件流通过在被管网络中分散的探头产生。这些事件可以实时地处理以保存如通过无数指标表示的网络状态。尤其重要的是每个主实体计算的关键指标，主实体包括订户和小区等(例如，每个订户每天的总呼叫时长、每小区的掉话比)。近来，已经出现了新情况，在这些情况中需要通过网络状态计算聚合的查询，抽象为包含每主实体指示符的表，以及实时变化的分析维度。在其它情况中，需要通过指标表计算随即实时分析查询。

高容量更新(事件)以及分析查询的混合工作负载会给传统数据库实践带来巨大挑战。分离OLTP类事件处理系统和OLAP系统的传统做法可能不符合这类情况的实时本质，并且考虑起来成本太高且很复杂。

图4所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图。该系统形成如结合图2所描述的系统的可能实施形式。

该系统包括流处理器401、SQL查询处理器403、get/put接口405、扫描接口407以及分布式键值存储409。数据库201可包括分布式键值存储409。通信接口207可包括get/put接口405和扫描接口407。处理器209可包括流处理器401和SQL查询处理器403。

为了处理新的实时混合工作负载，这种方法采用一种我们称为运动分析(Analytics in Motion，AIM)的架构。根据运动分析(Analytics in Motion，AIM)架构的系统的实施形式在下文表示为AIM系统。AIM系统可集成如图4所示的数据流处理器401、分布式键值存储409以及SQL查询处理器403。

在该架构中，流处理部件处理更新和新事件。这样，数据在运行中被匿名化和聚合。SQL处理器403评估复杂决策支持查询。流处理器401从存储中读取并更新条目或记录，SQL查询处理器403在共享分布式键值存储409上执行批量查询。共享分布式键值存储409作为分布式键值存储来实施，这意味着所有数据只能(例如，在主存器中)存储一次。流处理器401和SQL查询处理器403也可以是分布式的，这意味着更新和事件处理和决策支持可独立扩展，这样，每种工作负载都能实现不同的吞吐量和响应时间保证。最后，这种架构的一个重要优点在于，流处理器401和SQL查询处理器403可以是完全无状态的，这样能简化容错的实现。

虽然图4的架构具有多个优点，但是其还带来了多个新的挑战。一个特别的挑战是实施能够维持流处理器401的读取/更新工作负载同时维持SQL查询处理器403的批量读取工作负载的存储管理器。另一挑战可以是在分布式键值存储409等存储部件中同步进行读取和更新，从而满足不同级别的一致性。另外，分离这些部件可增加延迟和通信成本。更多挑战特定于流处理器401和SQL查询处理器403。

该方法的目的是描述我们致力于解决所有这些挑战的方案。我们建立一个唯一的主内数据库，其能够准确处理上述类型的混合实时工作负载。该数据库可以包含本文提出的许多观点。另外，我们使用来自客户的抽象一种情况的实际工作负载评估系统。虽然对一种提供强大机制来处理运行中的数据的系统的需要在电信行业尤其明显，但是我们相信本文所描述的技术更普遍且应用于许多垂直行业。

在下文中，我们概述了AIM系统。我们以一个运行示例开始，然后结合该示例描述以下成分：分析矩阵、SEP系统和RTA子系统。最后，我们定义了AIM旨在实现的优化目标。该优化目标可基于具体吞吐量、延迟和新鲜度规范。

AIM架构足以处理很多应用，例如电信计费事件的处理、在线购物、数据中心管理或财务管理。在下文中，我们将注重于促进这项工作并来自其中一个客户的用例。虽然在前言已经设定了该用例的阶段，但是我们在下文描述更多详细内容。

在用例中处理的数据是计费信息并且无法与智能服务可能正在收集的那种智能数据相比。传统上，该计费数据存储在移动手机运营商的数据仓库中并用来实施营销活动，诸如提供折扣或新的资费套餐给当地客户。目标是使这种分析更具扩展性，这样客户可从这类营销活动中直接受益。

典型的营销活动和分析查询不依赖于(例如，由手机呼叫、消息或网络请求产生的)单一事件，而是依赖于每个主实体(即，每个订户或每个小区)的总结性统计数据。一个实体的所有统计数据都以实体条目或记录来保存，该实体条目或记录可以是巨大物化视图的一部分，我们称该巨大物化视图为分析矩阵。注重于订户和手机呼叫的分析矩阵的示例在下表中描绘。

分析矩阵可以很宽，对于普通移动运营商而言可包含约500个属性。这些属性可以是一组事件属性(例如，费用、时长、本地/长途呼叫、优选号码)、一组聚合函数(例如，计数、求和、平均、最小化、最大化)和一组聚合窗口(今日、本周、本月等)的笛卡尔乘积。将分析矩阵保存为物化视图意味着对较宽但大小几乎恒定的表进行更新。在一些国家，电信市场受到调节，禁止收集关于单一订户的统计数据。在这种情况下，AIM能够采用足以测量匿名化的用户组(例如，基于小区ID、合约类型、年龄等)。

分析矩阵的设计允许快速处理要求具体订户的统计数据的查询。然而，计算对若干订户的聚合的分析查询会引起全表扫描。如果我们提前知晓一组可能查询，那么我们可以为每个查询创建额外的物化视图，以便递增地预计算结果。这正是流系统和Spark等交互性OLTP/OLAP引擎进行查询处理的方式。另外，高阶视图可在低阶视图的上方构建，如DB-Toaster所示。另一方面，AIM注重于预先不知晓的随即查询。这可能要求快速扫描。

第一AIM子系统被称为流和事件处理(Stream&Event Processing，SEP)。其职责是接收事件、根据聚合逻辑更新分析矩阵并相对更新后实体条目或记录评价业务规则。算法1所示为用于更新分析矩阵的统计数据的伪码。我们将更新某个属性组attr group的函数表示为update_attrgroup。属性组通常很小并包含相互依存的属性，例如，作为相同度量标准的计数、求和以及平均。步骤3至6可通过原子方式发生，这意味着我们从分析矩阵查找条目或记录、更新其所有属性，然后将其回写。

Algorithm 1：Updating Statistics

图5所示为根据一实施形式的数据库更新的图。该图示出了实体条目或记录的示例性更新。为了使统计数据正确，可以期望与此同时没有改变实体ID的条目或记录。算法的示例执行在图5中示出。

SEP的第二重要功能可以是业务规则评估。这种评估可实时地发生，这意味着可相对于从新事件产生的更新后实体条目或记录评估每个规则。电信计费系统中的业务规则主要用于营销活动(例如，规则1)，但还可以触发用于潜在手机误用的警报(例如，规则2)，如下表所示。

一种用于规则评估的简单方法在算法2中示出。该方法可将(例如，如由事件处理功能产生的)最新实体条目或记录作为输入并可参照所有规则检查。算法2可假设规则符合析取范式(disjunctive normal form，DNF)，因此被编码为一个复合词列表，每个复合词可包含一个谓词列表。算法2的特征是提前中止和提前成功：(a)每当谓词评估为假时，整个复合词可评估为假，因此我们可以继续下一复合词(行7至9)，以及(b)每当复合词评估为真时，整个规则可以评估为真，因此我们可以继续评估规则集中的下一规则(行10至12)。注意的是，算法2可进一步优化。

Algorithm 2：Straight-Forward Rule Evaluation

另一AIM子系统被称为实时分析(Real-Time Analytical，RTA)查询处理。由该子系统处理的查询可用来回复商业智能问题(还称为决策支持)。查询中的大多数是随即的，这意味着它们可能是不可预测的，并且可能包含分析矩阵属性的任何子集。除了这些随即查询，还存在参数化的SQL类存储流程，但是它们可能只是工作负载的一小部分。一些示例性的RTA查询在下表中示出。它们通常包含分析矩阵中的许多实体条目或记录，这些实体条目或记录可以基于一些商业标准过滤和聚合。更重要的是，RTA查询还可触发与维度数据(还称为维表)的连接。这种连接查询的示例是下表中的第二查询。RTA查询可以是只读的，这意味着分析矩阵只能通过流过系统的事件进行修改。

在描述主AIM部件之后，我们能够规定一组可以确定如何实施AIM的服务水平协议(service-level agreement，SLA)。我们确定以下SLA：最大事件处理事件(t_SEP)：系统处理事件和评估用于更新实体条目或记录的整个规则所需的时间的上界；最小事件处理速率(f_SEP)：系统每小时在每实体处理事件的下界；最大RTA查询响应时间(t_RTA)：系统回复RTA查询所需时间的上界；最小RTA查询速率(f_RTA)：系统每秒回复的RTA查询的下界；以及新鲜度(t_fresh)：事件进入系统到受影响实体条目或记录对RTA查询可见的时间的上界。

通过定义所有这些SLA，AIM旨在实现的优化目标可阐述如下：考虑到要保存的一组统计数据、要评估的规则集以及预期的事件到达速率，通过满足给定SLA并最小化每个实体的计算资源数目的方式执行流和事件处理以及随即分析查询处理。这意味着，我们假设AIM实施方式可以保证某一服务质量而不是优化具体吞吐量或响应时间，但是在这些限制内，应当最小化所需的机器数目。

AIM系统划分为SEP和RTA子系统源于它们提供两种不同的工作负载。SEP可以处理(例如，由以高速率到来的事件引发的)大量更新，其在文献资料中还称为联机事务处理(On-line Transactional Processing，OLTP)。另一方面，RTA可具有读密集型(在这种情况下甚至是只读的)分析工作负载，还称为联机分析处理(On-line Analytical Processing，OLAP)。由Stonebraker的信条“一种标准并非处处适用(one size does not fit all)”引起的传统方案可以对两种不同的工作负载使用两种不同的数据结构(即，两个不同的数据库)，这被称为数据仓库。只要仓库中的数据在几分钟或小时就会过时，数据仓库方法就会表现良好。然而，我们想要通过AIM实现的是对“实时”数据，即，不超过一秒的数据，进行分析查询处理。在该架构中，SEP和RTA可共享数据结构(即，分析矩阵)，以便获得实时查询结果。正如所料，在单一系统中拟合一切是一种挑战，会涉及到许多要做出的精细设计方案和决策。

图6所示为根据一实施形式的数据库更新和查询的图。该图示出了更新与查询处理的分离。该图所示为主数据结构203和增量数据结构205。

尽管我们具有一个由SEP和RTA共享的数据库或存储，但我们仍然必须解决如何以不干扰长期运行分析查询的方式处理更新的挑战。提出了两个不同方案来解决该挑战，两个方案都在图6示出。写时拷贝，还称为延迟拷贝，可以是一种由大多数现代操作系统用来有效管理分叉系统调用之后的父进程和子进程的最初常见内存状态的机制。像HyPer等系统可使用该OS机制来管理其数据库的不同快照。当父进程对大多数目前版本的数据处理更新时，在子进程中对较旧快照进行分析查询处理。如果我们想要单一条目或记录查找总是返回(例如，如SEP子系统所希望的)最新版本，则我们只在父进程中执行它们。

差异更新是又一种机制。其理念是在一个数据结构(称为增量数据结构205)中累积所有传入更新以及在分离结构(称为主数据结构203)中处理分析查询。增量数据结构205中的更新可周期性地应用于主数据结构203，这称为合并。如果用于更新的响应时间很关键，则我们可以维护两种增量数据结构，一个用于新的更新，一个用于目前合并的更新，并且以原子方式在合并时间点切换它们。该方法还可保证分析查询的快照分离，因为它们在稍微过时但版本一致的数据上操作。

AIM系统可采用修改的差异更新技术而不是写时拷贝，这种做法的原理是SEP上的SLA可能很严格，以至于分叉可能阻止更新很长时间。一种验证我们的假设的方法是实验评估，这可能放在未来研究清单的首位。

如上所陈述，架构由数据库201，例如分布式键值存储409组成，这意味着该架构可以支持get/put功能，即，单一条目或记录查找和更新。除此之外，数据库201，例如分布式键值存储409，可支持快速数据扫描，以便获得RTA处理的合理吞吐量和响应时间，这会产生如何最佳利用空闲中央处理器(central processing unit，CPU)的问题。我们确定两个方案：(a)以多线程方式处理RTA查询，即，对每个传入查询采用单独的扫描线程，有可能使用线程池进行再循环，以及(b)对数据进行分区，从而为每个分区分配一个扫描线程。所有扫描线程以共享扫描方式并行批量处理传入查询。

一种替代固定线程分区分配的方法可以是在扫描开始的时候将数据分区为许多小块，然后将块连续分配给空闲线程，直到每个块都被处理。这可以是一种简单的负载均衡机制(例如，解决分区可能变得不均衡的问题)，这可能带来块管理的额外成本。

系统的层数越多，系统就越灵活，我们从这一观点出发。另一方面，具有较少的层数能够减少网络延迟并且使系统更快。关于如何物理上放置图4所示的三个架构部件有不同的选择。尽管逻辑上分离，但是将SEP、RTA和分布式键值存储409或存储分区放置在同一物理节点上也可以是一个选择，我们称之为完全集成方法。这种方法的优点是通过本地内存快速访问数据。然而，我们会失去数据库存储和处理之间明确分离的优点，也就是灵活性。完全分离方法(例如，三个分离层)在允许以细粒度方式提供资源这一意义上会更灵活(例如，如果我们需要快速数据库存储访问，那么我们只需添加节点到存储层，而不改变SEP和RTA处理层)。显而易见，存在大范围的混合模型，它们都可以位于完全集成和完全分离架构分层之间。AIM系统可按照这种混合方法，以便接近我们的优化目标。

虽然分析矩阵可分布在数据库201的不同存储节点上，但是仍然存在将剩余AIM数据结构存储和保存在哪里的问题。将SEP规则放置在发生规则评估的相同节点上很有意义，这意味着在若干地方复制规则集。更令人关注的问题是在哪放置维表，这与在哪里进行连接处理的问题紧密相关。在数据库存储层执行连接可能很快，因为更接近数据，而在分离处理层执行连接在整体设计方面会更灵活，而且在数据库201的存储节点变得过载时更可取。由于维表可以很小并且是静态的，所以它们甚至可以在数据库存储和处理层处复制。RTA节点上的智能查询引擎然后可为每个查询确定其应当有多少个处理直接发生在数据库存储中，有多少个发生在RTA节点处。可以进行关于如何在分布式键值存储409上执行连接的更详细研究。

基于具体用例描述，我们制定了进一步描述的基准。基准由300条规则、546个分析矩阵属性组成，产生大小为3KB的实体条目或记录以及七个RTA查询。在基准之后，我们实施了下表所示的用于SLA的AIM系统。

t<sub>SEP</sub>：10msecs	f<sub>SEP</sub>：3.6
		t<sub>RTA</sub>：100msecs	f<sub>RTA</sub>：100
t<sub>fresh</sub>：1sec

系统可很好扩展用于1千万到1亿个实体。显然地，每实体3.6个事件可转换为每秒1万个事件(对于1千万个实体而言)到最高每秒10万个事件(对于1亿个实体而言)，使得在分析矩阵中产生的更新量为每秒30MB到300MB等。

该系统的目标可以是支持“一体适用(one fits it all)”方案对于这种具体情况确实是有可能的这一说法。我们实施了所有事件处理机制、分布式内存版本的分析矩阵以及侦听事件和RTA查询并将结果传送给终端用户的网络接口。因此，AIM系统可用作独立应用，用户使用该应用可通过TCP接口或RDMA(例如，使用InfiniBand)通信。我们的今后工作不考虑的是以下挑战：如何使分析矩阵持久，即如何添加事务对数。我们的用例引起的另一简化是规则和维表不随时间发生太多变化的假设。

我们从关于AIM结构的一些基本情况开始：(a)(例如，由事件流产生的)OLTP工作负载可由经常称之为主键(例如，实体ID)的单一条目或记录更新组成，所以我们可能知道我们想要更新的条目或记录的准确位置，(b)分析矩阵可使用同一主键，因此能够很容易地以透明方式进行水平分区，(c)RTA查询可以是只读的，因此可以在分析矩阵的只读快照上执行，(d)规则和维表可以是静态的，并可以安全地复制。

图7所示为根据一实施形式的一种用于查询和更新数据库中条目的系统的图。该系统包括SEP节点701至705、存储节点707至711以及RTA节点713至717。该系统是如结合图2所描述的系统的可能实施方式。数据库201可包括存储节点707至711。处理器209可包括以分布式方式排列的SEP节点701至705、存储节点707至711以及RTA节点713至717。通信接口207未在图7中示出。

该图示出了AIM系统的3层架构。其可以被视为特殊的客户端-服务器架构，其中存储节点707至711等存储部件可以充当服务器，而RTA节点713至717和SEP节点701至705可充当客户端。我们决定使用专用存储层来存储数据结构。因此，专用存储层能够承载分析矩阵和维表。注意的是，分析矩阵可分布(即，根据实体ID水平分布)在所有存储节点707至711上，而维表可在每个节点处复制。分布分析矩阵是有利的，因为我们想通过在不同节点上并行扫描分析矩阵来加速RTA查询处理。然而，由于我们想减少服务器和客户端之间的通信成本，所以我们选择在每个存储节点707至711处复制维度数据，这样可以允许在本地执行连接。由于可以假设维表是静态的，所以这样做是有效的。

在图7的底部存在RTA节点713至717，它们可以是轻量级处理节点，这些轻量级节点可以进行查询、可以将查询重定向到所有存储节点707至711，之后在将最后结果传送给终端用户之前合并部分结果。由于无论如何较大部分的RTA查询处理都会发生在存储节点707至711上，所以我们使用比存储节点707至711少得多的RTA节点713至717。

在存储节点707至711上方存在SEP节点701至705。与轻量级RTA节点713至717相反，SEP节点可以是重量级处理节点，这些重量级节点可使用存储节点707至711仅进行查找和回写实体条目或记录。

每个SEP节点701至705可负责实体的子集，换言之，可基于创建该事件的实体将一个事件路由至对应的SEP节点701至705。每个SEP节点701至705可具有整个规则集的副本，并且会使用规则索引，以便使评估更快。

SEP节点701至705与存储节点707至711之间的通信可同时发生(例如，当我们正使用get/put接口405时)，而RTA节点713至717与存储节点707至711之间的通信可以是异步的(例如，每当它们可用时发送回复)。虽然我们喜欢使用InfiniBand技术来通信，但是我们还实施了TCP接口通信模块，以便使我们的系统在不支持InfiniBand的系统上工作。

尽管事实是AIM架构的逻辑设计是3层，但并不意味着物理设计也是3层。实际上，我们测试了SEP存储布局和交互的两种配置：(a)独立物理层以及通过InfiniBand进行的通信以及(b)放置于(例如，在不同内核上的)相同物理机以及通过公共内存结构进行的通信。虽然(a)在整个系统的灵活性方面非常有益，但是(b)能够有助于调整系统以获得最后一点性能，因为我们能够避免通过网络发送大的(例如，3KB)统计条目或记录。

回想算法1，我们了解到分析矩阵的每个属性可以具有其自身、定制的更新函数。这会使更新比使用一般更新函数更快。这种函数可包含大量开关语句，这些语句由于CPU中的分支误预测而放慢执行。为了使定制的更新函数的编程更容易、更灵活，可通过模块化的方式编写它们，从而可以共享相同特征(例如，窗口语义)。如上所述，每个属性可以是事件属性乘以聚合函数乘以时间窗的笛卡尔乘积的元素，时间窗本身是窗口类型和窗口间隔的组合。这意味着，我们能够从几个小的构建块的组合创建大量更新函数。

使这些构建块形成模板能够使编译器创建非常有效的更新代码。在系统启动时，我们从(例如，定义系统设置的)元数据库加载关于分析矩阵属性的信息并创建可用来更新统计数据的一个函数指针数组。更新因此很快速，因为(a)可以按照对应的函数指针更新每个属性，这样使分支预测变为可能，以及(b)编译器生成的合成更新函数可能不包含任何条件转移。

由于规则集可以固定并提前预知，所以考虑索引规则以加速索引评估是有意义的。因此我们基于法布尔等人的观点实施规则索引。然而，事实证明，我们以300条规则为标准，该索引可能不比仅处理规则快，该处理规则没有简单方式的索引但是具有如算法2所示的提前循环终止。一个微基准，在其中我们改变规则的数目(例如，每个规则由5个复合词和平均每个复合词5个谓词组成，从1到10变化)并发现对于1000及以上的规则集大小使用一个规则索引开始偿还(paying off)。我们的结论是，只要规则集相对较小，我们就能够降低复杂性并因此不使用任何索引。

图8所示为根据一实施形式的哈希表的图。该哈希表可包括ColumnMap。

如上所述，分析矩阵可在数据库201，例如，分布式内存键值存储409内实施。初步实验表明，对于实现SEP的SLA，Ramcloud可以与键值存储一样表现良好。Ramcloud不仅能提供快速条目或记录查找和写入，而且由于其按照对数结构设计，还能够支持持久性和容错。然而，由于对于任何行存储都是如此，我们对于RTA查询处理可能无法达到足够快的扫描速度，因此在开始实施RTA子系统时必须寻找替代方法。为了获得快速扫描，传统分析查询处理引擎可使用面向列的数据库或存储布局，这可能不是很适合高更新率。

克服该挑战的方案可以是使用跨分区属性(partition attributes across，PAX)方法，该方法能够有助于发现纯面向行与纯面向列的数据库或存储布局之间的甜区(sweetspot)。PAX的想法是将条目或记录划分为块，将这些块装入内存页，在页面存储组内将它们按列分组，例如，特定属性的值可以分组在一起。处理属性的一个小型子集的分析查询则可获益于数据局部性以及块的全部条目或记录同时出现在内存中的事实。我们因此设计ColumnMap，一种遵循这种设计的数据结构，不同点在于，优化是针对缓存大小而不是内存页大小，因为AIM系统中的所有数据结构都可以存储在数据库201或内存中。

ColumnMap的结构在图8中例示。我们将固定数目的条目或记录分组为称为桶的逻辑块。在示例性系统中，默认桶大小为3072。由于桶大小可以为与缓冲大小相关的调整参数，所以我们选择可以为2的最大幂的3072，使得桶(其大小是3072乘以3KB)可以装入我们硬件的10MB的L3缓存。

所有组合的桶可保存全部分析矩阵。在桶内，可以将数据组成列。每列能够保存特定订户属性的值(例如，本月费用)。该方法可以允许增加条目或记录间局部性，这有利于各个属性的扫描处理。除了桶之外，我们保留可以记录实体ID与条目或记录ID之间映射的小型哈希映射或哈希表。这种间接级别的原因可能是实体ID可为任意数字而条目ID或记录ID可为从0开始的连续数字这一事实。因为条目或记录可以具有恒定大小且每个桶可包括恒定数目的条目或记录，所以我们能够根据条目ID或记录ID计算特定值的地址。这可以加速单值的查找。

值得一提的是，我们还可使用ColumnMap作为纯行存储(例如，通过将桶大小设为1)或作为纯列存储(例如，桶大小＝数据库大小)。事实上，当条目或记录小得足以装入缓存线中时，ColumnMap在更新性能方面胜过列存储。如果它们不能(如在我们处理3KB条目或记录的用例中)，桶大小可能对RTA和SEP性能都没有发挥主要作用，我们还可以使用纯列存储。

我们喜欢ColumnMap胜过在系统中使用建立好的列存储有以下两个原因：(a)ColumnMap可具有可调参数桶大小，这可以使其在同一时间成为行存储、列存储和混合存储，因此增强灵活性，以及(b)我们无需通过SQL接口而直接访问原始数据。虽然存在一些可提的例外情况，像Supersonic，但多数可用列存储还没有公开它们的内部数据结构。

如上所述，我们能够确保由SEP产生的更新不干扰RTA查询，因为这些查询可返回一致结果，因此在分析矩阵的一致性快照上工作。为了解决这种挑战，我们实施了修改版本的差异更新。相比于原提议，我们可能不使用字典压缩，因为分析矩阵可能只包含固定大小的数值数据类型。因为我们在任何时候(例如，在合并阶段期间)都没有能力阻止SEP子系统，所以我们可能必须在合并之前分配新的增量数据结构205，这意味着我们在合并阶段期间有两个增量数据结构。可以如算法4和3所示相应地调整更新和查找。

Algorithm 3：Analytical Matrix Update

Algorithm 4：Analytical Matrix Lookup

这些算法可以测试可变的新增量数据结构是否存在，以便确定当前正在执行合并(即，存在新增量数据结构)或不在执行合并(即，不存在新增量数据结构)。由于算法可能是线程不安全的，所以我们通过一个专用SEP线程执行查找和更新。该决策可以允许以原子方式更新实体条目或记录，这可以是一个重要的功能规范。

由于可以针对单条目或记录操作优化增量数据结构205，所以我们使用密集的哈希映射或表实施增量数据结构。另外，主数据结构203以快速扫描为特征，并且可以被索引以进行单条目或记录操作。主键(例如，实体ID)上的索引还可以是合并步骤有效实现的规范，因为它意味着我们可以单次经过增量数据结构205而不是再次遍历整个主数据结构203。我们将主数据结构203作为ColumnMap来实施，如上所阐述，ColumnMap在本案情况下是最合适的。

还遗留我们应当何时、多久执行一个合并步骤的问题。为了防止增量数据结构205变得过大，尽可能经常合并是有好处的。此外，合并步骤可中断RTA查询处理，因此可能要仔细选择合并的时机。幸运的是，合并步骤可以很好地与下文所示的查询处理交叉在一起。

图9所示为根据一实施形式的数据库更新和查询的图。该图包括主数据结构203和增量数据结构205。该图示出了SEP线程和RTA线程的协作。

传统数据库系统一次只能处理一个查询。受SharedDB的启发，我们反而通过使用面向批量的处理技术尝试实现更高吞吐量。数据库201或存储服务器可保持由RTA客户端节点提交的查询的一个队列。一旦开始新扫描，队列中的查询可以在一次单一扫描阶段一起处理。这种共享扫描可以允许多个查询共享相同扫描。这种面向批量的处理技术可减少各个查询的过度等待时间并可以允许增加查询吞吐量。此外，面向批量的查询执行模型非常适合增量主数据结构或存储布局，因为可以将扫描和合并步骤交叉进行。因此RTA线程可以循环工作，具有如图9所示的以下两个步骤。

在扫描步骤中，如算法5所示扫描整个主数据结构203(例如，ColumnMap)。在该阶段期间，主数据结构203可以为只读，因此SEP线程(例如，执行查找)和RTA线程的并发访问可以是安全的。

Algorithm 5：Shared Scan Query Processing

在合并步骤中，RTA线程可扫描增量数据结构205并且将更新适当地应用于主数据结构203。增量数据结构205会变为只读，因为新的更新可被重定向到新分配的增量数据结构。SEP线程可能不读取RTA线性当前正在写入的项，只是因为如果一个项当前正在主数据结构203中更新，则意味着该项也可以存在于增量数据结构205中，这意味着SEP可以从增量数据结构而不从主数据结构203中获得该项，参见算法4。

图10所示为根据一实施形式的单指令流多数据流(single instructionmultiple data，SIMD)处理方案的图。单指令流多数据流(single instruction multipledata，SIMD)处理方案可由如结合图2所描述的系统采用。

许多处理器可以由单指令流多数据流(single-instruction multiple data，SIMD)设备，诸如矢量寄存器，以及专用指令组成以操作存储在这些寄存器中的数据。它们允许在多个数据点上并行执行一个指令。例如，流式SIMD扩展(steaming SIMD extension，SSE)可在128位或256位宽的寄存器上操作。这些寄存器的大小允许将多达4个浮点运算数级联到单个向量中并允许并行处理算数或逻辑运算。

SIMD指令允许一定程度上的并行操作，并且还会经常导致条件分支指令的消除，从而减少分支误预测。这会使SIMD指令对于高性能数据库非常有用，由于RAM容量增加，与受CPU限制相比，数据库更经常受内存限制。因此，我们利用SIMD指令在数据库201上建立一个快速扫描，例如，ColumnMap。这种扫描可包括如图10所图示的过滤(选择)和聚合(投影)。

利用SIMD指令过滤可以指首先将列加载到一个向量寄存器，将运算数加载到另一寄存器，然后执行SIMD对比指令(例如，SIMD_>)，这可以产生布尔位掩码，其说明是包括结果中的一个值(例如，值0xF……F)还是不包括一个值(例如，值0x0……0)。我们根据查询的WHERE子句通过SIMD_&或SIMD_-组合来自不同过滤器的位掩码。在聚合中，我们将数据向量与源自过滤的位掩码交叉，然后采用聚合运算符(SIMD_MIN、SIMD_MAX或SIMD_+)。

用例可能只涉及统计数据(例如，分析矩阵)和维度数据之间的主键/外键关系，这意味着连接基本上为维表中的查找。此外，我们观察到维表可以是静态且小型的，这允许进行特殊调整，即不规范化处理维度数据并将其与实体条目或记录仪器存储在分析矩阵中。这意味着我们在创建实体条目或记录时只执行一次连接，这样能够极大加速查询执行。一旦维度数据变大，变化更频繁或包括与分析矩阵的多到多关系，我们就可实施传统连接，例如，哈希连接或排序合并连接。

图11所示为根据一实施形式的一种用于查询和更新数据库条目的系统的图。该图包括SEP线程1101、分析矩阵的分区1103以及RTA线程1105。该图示出了分析矩阵的分区1103和s＝2、n＝4和k＝2的线程模型。分析矩阵和线程模型可以在如结合图2所描述的系统内实现。

如上所阐释，我们不仅可以在不同节点上分布分析矩阵，而且还可以将分析矩阵在如图11所示的节点内进行分区。存在两个可以确定资源提供的参数：SEP线程的数目s和RTA线程的数目n，数目n可以等于数据分区1103的数目。每个RTA线程可与一个数据分区有关，而每个SEP线程可在若干(多达k)分区1103上工作，在该系统中，我们使用策略首先选择可以实现SEP上的SLA的足够大的s，然后使用剩余内核进行RTA处理和通信(例如，2个线程进行与其它2层的通信)，这意味着n＝内核数目－s－2。注意的是，我们在本文可交换地使用术语内核和线程，因为我们拥有的线程与内核一样多，从而避免过度订阅的性能降低。

将查找或更新请求路由至正确分区可按如下方式操作：首先，使用全局哈希函数h将请求路由至具有ID h(key)的节点。接着，在该节点内采用节点特定哈希函数hi(key)来确定承载该键的分区的ID。最后，将请求路由至负责该数据分区的SEP线程。

数据分布会产生一致性问题。我们通过协调开始存储节点上的所有RTA线程1105的扫描步骤来实施节点内一致性。这也可以是有利的，因为如果所有线程在同一时间开始，那么它们可以在相同查询批次上操作。我们可能无法提供节点内一致性，因为事件可能没有全局顺序。分布式事务一致性可以是一项要研究的复杂任务。

下表示出了RTA查询1至7，其中α在[0；2]之间，β在[2；5]之间，γ在[2；10]之间，δ在[20；150]之间，t为SubscriptionType，c为类别，v为CellValue。

如图所示，AIM系统可处理具体用例，这会要求具体基准。因此，我们通过定义一个可以测试系统能力以处理用例的规范来开始我们的工作。基准由300条规则、546个统计数据(其是指大约3KB的实体条目或记录)和若干不同参数化RTA查询组成。虽然查询1至3可能只对统计数据进行操作，但查询4至7可包含与一个或若干维表的连接。出于空间原因，我们省略了关于维表的详细内容，并且只以文本形式描述了Q6和Q7，因为完整的SQL语句会包括嵌套的复杂子查询。基准参数为实体数目(即，统计数据量)、事件率、RTA客户端线程数目c和query-mix。虽然我们试图以固定速率发送事件，但是我们可以以闭环方式(在闭环中，一个线程只能在接收和处理所有来自前一查询的部分结果之后发送查询)运行RTA查询。

这意味我们能够通过增大c来增加系统上的RTA负载。由于用例指出系统能够回复随即查询，所以工作负载可能是不可预测的。为了展示这点，我们不允许对统计数据使用任何索引，除了主键。

在配有双接口4核Xeon E5-2609 CPU的服务器上进行实验，每个核以2.4GHz操作。每个服务器由32KB的L1缓存、256KB的L2缓存和10240KB的L3缓存以及4x32GB的DDR3-DIMM组成，产生总共128GB的RAM。我们使用运行内核3.4.4的标准Linux 4.6.3-1，以及GCC-4.7.2和通过InfiniBand的通信。如上所示，我们决定将SEP节点和存储节点分别托管在相同物理节点(例如，通过共享内存通信)和薄RTA处理节点上。我们使用一个专用机器来生成随机事件并测量事件处理的端到端吞吐量和响应时间。这种机器可配置为以(例如，如由基准规定的)某一速率发送事件。使用c个线程在单个RTA节点上直接执行随机RTA查询的创建以及吞吐量和响应时间的端到端测量，由于RTA处理活动没有完全利用该单个RTA节点，所以工作良好。

如上所述，AIM系统能够处理每实体每小时3.6个事件的事件率并从1千万扩展到1亿个实体。因此，我们首先执行多个实验来确定最优资源分配和为每秒1千万个实体和1亿个事件设置的参数，然后稳步增加实体数目到1亿个。所有实验使用所有七个查询的查询混合来进行，在相等概率下随机获得。我们报告RTA查询的平均端到端响应时间和总查询吞吐量。由于事件率可配置用于满足f_SEP，所以我们只报告偏离事件率的测量后SEP吞吐量。t_SEP总是满足，因此从结果中省略。我们使用以下默认值进行实验：1千万个实体、1万个事件每秒、8个RTA客户端线程(c＝8)、1个SEP服务器线程(s＝1)、5个RTA服务器线程n＝5(＝数据分区的数目)、1个AIM服务器。

图12所示为根据一实施形式的一种用于查询和更新数据库条目的系统的性能图。所述图示出了以毫秒为单位的RTA查询的平均响应时间，其中实体为1千万个，1万个时间每秒，默认配置包括1个服务器、n＝5以及c＝8。

图13所示为根据一实施形式的一种用于查询和更新数据库条目的系统的性能图。所述图示出了以查询每秒为单位的RTA查询的吞吐量，其中1千万个实体，1万个事件每秒，默认配置包括1个服务器、n＝5以及c＝8。

初步实验表明一个单SEP线程每秒可处理多达15000个事件，这足够用于服务1千万个实体并且是我们将SEP线程的数目固定为1的原因。图12a和13a所示为单个存储服务器上不同数目的存储分区(＝RTA服务器线程)和不同桶大小的响应时间和吞吐量。如假设的那样，我们在分配与内核一样多的线程时获得最佳性能。由于我们拥有一个SEP线程和两个通信线程，所以导致8核机器上有5个RTA服务器线程。此外，我们可以看出，通过4个和5个分区，所有SLA都得以满足(记住，我们在每次扫描之后合并，因此t_fresh与响应时间在同一数量级上，因此明显低于1秒)。对于n＝6，SEP吞吐量对于不同的桶大小而言从1万个事件每秒降到8千个事件每秒，这是线程在存储节点处抖动的直接结果。如我们所看到的，只要桶大小足够大，桶大小似乎不会对性能产生影响。注意的是，ColumMap优于纯列存储(其被称为所有)。

因为共享扫描的执行事件可以由工作负载中的最繁重查询的执行时间主导，所以独立了解每个查询的平均响应时间是有好处的，这在下表中示出。结果表明一种优化可能是根据所预计的响应时间在若干组中批量处理查询。下表示以毫秒为单位的查询响应时间，其中n＝5，3千个桶。

图14所示为根据一实施形式的一种用于查询和更新数据库条目的系统的性能图。所述图示出了RTA服务器变体以及负载。

由于RTA处理节点的线程可在闭环中工作，所以它们的数目还可是存储服务器处的查询批量大小的上界。如果我们想要测试系统的鲁棒性，我们因此能够通过如图12b和图13b所示的将c在2到128之间变化，仅增加RTA负载。我们看到，系统一旦达到饱和(例如，某处约54个线程)就可以很稳健，其保持恒定但不会下降，而响应时间呈线性增加，但不是呈指数增加，如我们将预计的那样。我们满足具有8个线程的RTA SLA(例如，t_RTA＜100毫秒，f_RTA＞100查询每秒)这一事实会建议将存储服务器处的查询批量大小限制约为8。

为了将AIM系统与高性能通用数据库进行比较，我们将稳健性实验中的存储部件替换为Postgres数据库。为了使这种比较尽可能地公平，我们使用RAM磁盘调整Postgres以在主内存中运行。然而，我们关闭f_sync和synchronous_commit并根据分析矩阵的大小增加wal_buffer。考虑到我们在RAM磁盘上操作，我们将seq_page_cost和random_page_cost降低到足够大的限制。尽管存在所有这些方法，Postgres可能不满足规定的SLA。我们测量最佳配置(c＝2)下拥有828个事件每秒的SEP吞吐量。

我们在c＝4的情况下获得最佳RTA性能。存在0.16个查询每秒的总吞吐量，查询响应时间的范围从1毫秒(Q6)至65.7毫秒(Q3)。Q6的较好结果可以通过以下事实来解释：我们在相关属性上使用索引，尽管基准禁止这样使用。Postgres的性能可通过每个传入事件可带来大量列更新(例如，超过500个属性)和SQL层开销这一事实来解释。甚至商业通用数据库产品也会面临两个挑战，因为它们通常不允许原始数据的直接修改。

先前实验示出了一个存储服务器足以容纳1千万个实体。然而，由于SLA可能改变，了解提供更多资源是否能解决挑战是很重要的。为了分析这点，我们将存储服务器的数目从1增加到10，如图12c和图13c分别所示。我们看到吞吐量和响应时间呈近线性增加。我们得出结论，横向扩展有可能带来令人满意的较小开销。

最新实验在关注可扩展性，或换言之，不仅增加服务器数目，而且还相应地增加负载(实体数目、事件率)的时候性能测量是如何改变的。对于所添加的每个服务器，我们还每秒添加1千万个实体和1万个事件。图14所示为合适的可扩展性。理想的是，吞吐量和响应事件将是水平线。如何它们不是的话，表明RTA处理节点处的开销增加了，部分结果必须在该RTA处理节点上合并。我们有两种选择来减少端到端响应时间，以便提高吞吐量并将其保持在所期望的每秒100个查询之上：(a)如图12c所表明的，通过添加另一存储节点减少存储层的服务时间，或(b)通过并行化加速RTA处理节点处的部分结果的聚合。每当RTA处理节点使用率不高时，选择(b)都是有利的，因为我们可以使用现有资源。

本领域有多种工作。至少有两个方面能区别AIM系统与所有这些其它系统：(a)流处理和随即分析查询处理的特殊工作负载混合，以及(b)AIM系统可能实现的具体延迟规范(SLA)。虽然AIM系统实施方式(例如，数据分区、共享扫描、差异化更新、SIMD处理)中使用的基本构建块可以使用，但是我们以我们如何组合它们以实现为AIM系统定义的具体规范的方式来提高。在下文中，我们讨论一些最相关的其它系统，但是我们知道这种枚举并不详尽也不完整。

一方面，存在传统的流式引擎，像Apache Storm、Esper和StreamInsight。这些系统擅长处理高事件率以及计算它们的统计数据。然而，AIM系统中保存的统计数据数量庞大(例如，每个实体存有500个统计数据)会对这些系统带来挑战。使用Store进行的初步实验表明与达到所期望的性能相距很远。另外，流式引擎可能要扩大，以便进行查询处理。

另一方面，存在快速分析处理引擎，像HANA、C-Store和MonetDB。这些系统能够通过按列组成数据加速查询执行，因此只检查条目或记录的有兴趣属性。此外，分析矩阵中的列数可能是一个难题，因为将会带来实体条目或记录的更新，例如，500次随机内存访问。

存在实施分析矩阵的替代方法，实施分析矩阵是使用现有键值存储，像BigTable、H-Base或Ramcloud。虽然这些系统可以应对SEP规范，但是如何在系统上方处理分析查询是一个未解决问题。它们通常支持基于键的访问，有时支持基于值的访问，但通常没有扫描。Ramcloud能够提供称为“枚举”的特征，但是对AIM系统工作负载进行的实验表明这比我们为分析矩阵实施的扫描慢了两个数量级。

最后，存在类似于AIM系统的OLTP/OLAP引擎。它们之中有SharedDB、HyPer、HYRISE和Spark Streaming。这些系统通常做出预先知道大多数分析查询的假设，并通过采用特殊的存储布局(HYRISE)或专用视图(Spark Streaming)来利用这一假设。随机查询被认为很少出现，因此不需要满足严格的延迟规范。针对AIM系统的情况是不同的，因为随即查询是标准而非例外。HyPer的写时拷贝方法如何解决AIM系统工作负载仍然是一个未解决问题。

我们已经描述了AIM系统，一种解决在流式且频繁实时更新和分析查询执行方面具有严格SLA的系统的架构。我们讨论这种架构的设计空间并实施AIM系统，一种针对具体工作负载的分布式和灵活实施方式，该实施方式建立具体原则，例如PAX范式、使用SIMD的有效分布式超标量查询执行，以及实时数据管理的差异更新的新变体。

更重要的是，我们制定了可以获得用例中具体工作负载的特征的详尽基准。该基准下AIM系统的实验评估表明我们确实可以使用最少资源来满足SLA(例如，对1千万个至1亿个实体，每秒处理1万个至10万个事件，导致30MB到300MB每秒的更新，同时每秒回复多达100个决策支持查询，响应时间是100毫秒)。这种最小资源分配以每1千万个实体一个存储服务器节点为特征。

存在未来我们要遵循的其它观点。例如，当我们使用OS写时拷贝机制管理的ColumnMap的若干快照替代增量-主数据结构存储时，研究AIM系统将很有趣。这将意味着在共享扫描进行x次迭代后分叉ColumnMap，其中x可以是针对执行速度实时调整的参数。

更重要的是，可应用对AIM系统的若干扩展：支持变长数据(例如，通过使用指向变长对象的固定大小的指针)、持续性(例如，通过将增量数据结构集成为异步写入磁盘的对数)、随即查询的SQL解析以及工作负载均衡。值得一提的是AIM系统支持热点实体，因为这意味着对应的实体条目或记录可以在增量数据结构中多次重写，因此在写入主数据结构之前以原子方式压缩。唯一可能产生的问题是某个SEP处理线程何时变为热点。为了解决这个难题，我们将在SEP线程之间添加端到端负载均衡。

以下参考文献以引入的方式进一步并入本文本中。

·Y.Ahmad等人，“DBToaster:Higher-order Delta Processing for Dynamic,Frequently Fresh Views”。PVLDB 5.10(2012年)，第968至979页。

·A.Ailamaki等人，“Weaving Relations for Cache Performance”。VLDB，2001年，第169至180页。

·F.等人“The SAP HANA Database-An Architecture Overview”。IEEEData Eng.Bull.35.1(2012年)。

·M.Aslett，Data Platforms Landscape Map.http://blogs.the451group.com/information_management/2014/03/18/updated-data-pl atforms-landscape-map-february-2014。2014年3月18日。

·P.A.Boncz等人“MonetDB/X100:Hyper-Pipelining Query Execution”。CIDR第5卷，2005年，第225至237页

·F.Chang等人，“Bigtable:A Distributed Storage System for StructuredData”。ACM计算机系统会刊，26.2(2008年6月)，4:1-4:26。

·F.Fabret等人，“Filtering Algorithms and Implementation for Very FastPublish/Subscribe”。2011年SIGMOD，第115至126页。

·G.Giannikis等人，“SharedDB:killing one thousand queries with onestone”。PVLDB 5.6(2012年2月)，第526至537页。

·Google,Sparsehash，https://code.google.com/p/sparsehash。

·Google，Supersonic Query Engine。https://code.google.com/p/supersonic。

·M.Grund等人，“HYRISE-A Main Memory Hybrid Storage Engine”。PVLDB 4.2(2010年)，第105至116。

·Hortonworks，Apache Storm-A system for processing streaming data inreal time。

·InfiniBand Trade Association,InfiniBand。http://www.infinibandta.org.

·D.R.Karger and M.Ruhl，“Simple Effcient Load Balancing Algorithmsfor Peer-to-peer Systems”，SPAA，2013年，第36至43页。

·S.J.Kazemitabar等人，“Geospatial stream query processing usingMicrosoft SQL Server StreamInsight”。PVLDB 3.1-2(2010年)，第1537至1540页。

·A.Kemper和T.Neumann，“HyPer:A hybrid OLTP&OLAP main memory databasesystem based on virtual memory snapshots”。ICDE.2011年，第195至206页。

·A.Khetrapal和V.Ganesh，“HBase and Hypertable for large scaledistributed storage systems”。计算机科学系，普渡大学(2006年)。

·R.Kimball，The Data Warehouse Toolkit:Practical Techniques forBuilding Dimensional Data Warehouses。John Wiley，1996年。

·J.Krueger等人，“Fast updates on read-optimized databases usingmulti-core CPUs”。VLDB 5.1(2011年)，第61至72页。

·S.Loesing等人，On the Design and Scalability of Distributed Shared-Memory Databases。Tech.rep.ETH Zurich，2013年。

·J.Ousterhout等人，“The case for RAMCloud”。ACM通信，54.7(2011年7月)，第121至130页。

·E.Snowden，I don't want to live in a society that does these sort ofthings.Youtube,http://www.youtube.com/watch？v＝5yB3n9fu-rM。2013年7月9日。

·M.Stonebraker等人，“C-Store:A Column-oriented DBMS”。VLDB，2015年，第553至564页。

·M.Stonebraker等人，“Object-relational DBMS-the next wave”。数据库软件，门罗公园，CA(1995年)。

·E.Tech.Event Series Intelligence:Esper&NEsper.http://esper.codehaus.org。

·TELCO-X Network Analytics Technical Questionnaire,internal documentrelating to customer TELCO-X.2012。

·C.Tinnefeld等人，“Elastic online analytical processing on RAMCloud”。EDBT，2013年，第454至464页.

·P.Unterbrunner等人，“Predictable Performance for UnpredictableWorkloads”。PVLDB 2.1(2009)年，第706至717页。

·T.Willhalm等人，“SIMD-scan:ultra fast in-memory table scan using on-chip vector processing units”。PVLDB 2.1(2009年)，第385至394页。

·M.Zaharia等人，“Spark:cluster computing with working sets”。关于云计算热门话题的第二届USENIX会议论文集，2010年，第10至17页。

·J.Zhou和K.A.Ross，“Implementing database operations using SIMDinstructions”。2012年，SIGMOD，第145至156页。

尽管已参考具体特征、实施形式和实施例描述了本发明，但是很明显在不脱离本发明的精神和范围的情况下，可在本文中进行各种修改和组合。说明书和附图仅被视为所附权利要求书所定义的本发明的说明，并且考虑落于本说明书的范围内的任何和所有修改、变体、组合或均等物。

Claims (17)

1.一种用于查询和更新数据库(201)条目的方法，所述数据库(201)包括用于存储数据库条目的主数据结构(203)和用于存储和/或接收新条目的增量数据结构(205)，其特征在于，所述方法包括以下步骤：

接收(101)多个数据库查询；

聚合(103)所述接收的多个数据库查询以获得批量数据库查询；

使用所述批量数据库查询执行(105)所述主数据结构(203)的共享扫描，其中所述主数据结构(203)中的所述数据库条目结合所述批量数据库查询中的每个数据库查询进行查询；

在所述执行(105)所述共享扫描的步骤之后，合并(107)所述主数据结构(203)与所述增量数据结构(205)以随着所述新条目更新所述主数据结构(203)。

2.根据权利要求1所述的方法，包括接收又一多个数据库查询，其特征在于，在所述合并(107)所述主数据结构(203)与所述增量数据结构(205)以更新所述主数据结构(203)的步骤之后执行以下步骤：

聚合所述接收的又一多个数据库查询以获得又一批量数据库查询；

使用所述又一批量数据库查询执行所述主数据结构(203)的又一共享扫描，其中所述主数据结构(203)中的所述数据库条目结合所述又一批量数据库查询中的每个查询进行查询；

在执行所述又一共享扫描之后，合并所述主数据结构(203)与所述增量数据结构(205)以随着所述增量数据结构(205)中存储的或由所述增量数据结构(205)接收的新条目更新所述主数据结构(203)。

3.根据权利要求1或2所述的方法，其特征在于，所述执行(105)所述共享扫描以及合并(107)所述主数据结构(203)与所述增量数据结构(205)的步骤在不同的时间点执行。

4.根据权利要求1或2所述的方法，其特征在于，所述执行(105)所述共享扫描以及合并(107)所述主数据结构(203)与所述增量数据结构(205)的步骤在预定时间点执行。

5.根据权利要求1或2所述的方法，其特征在于，包括建立不同类别的数据库查询的队列。

6.根据权利要求1或2所述的方法，其特征在于，包括建立点查询或分析查询的队列。

7.根据权利要求5所述的方法，其特征在于，包括根据每类数据库查询的响应时间要求调度所述批量数据库查询中的所述类别的数据库查询。

8.根据权利要求1，2或7所述的方法，其特征在于，包括：

接收多个新条目；

聚合接收的多个新条目以获得批量新条目；

在更新步骤中随着所述批量新条目更新所述增量数据结构(205)。

9.根据权利要求8所述的方法，其特征在于，所述共享扫描或所述主数据结构(203)与所述增量数据结构(205)的所述合并(107)或随着新条目更新所述增量数据结构(205)通过使用索引或至少一个哈希表来执行。

10.根据权利要求1，2，7或9所述的方法，其特征在于，包括：

接收数据库查询；

确定一类所述接收的数据库查询；以及

根据所述确定的类，将所述数据库查询包括在所述批量数据库查询中，或基于哈希表使用所述接收的数据库查询直接查询所述主数据结构(203)。

11.根据权利要求10所述的方法，其特征在于，执行所述批量数据库查询以及以交叉方式或以共享方式直接查询所述主数据结构(203)。

12.根据权利要求10所述的方法，其特征在于，包括执行所述批量数据库查询的快照隔离。

13.根据权利要求10所述的方法，其特征在于，包括接收新条目用于更新所述增量数据结构(205)。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行以实现权利要求1至13任意一项所述的方法。

15.一种数据处理系统，其特征在于，包括：

数据库(201)，所述数据库(201)包括用于存储数据库条目的主数据结构(203)和用于存储和/或接收新条目的增量数据结构(205)；

通信接口(207)，用于接收多个数据库查询以及用于接收新条目；以及

处理器(209)，其中所述处理器(209)用于：聚合所述接收的多个数据库查询以获得批量数据库查询；使用所述批量数据库查询执行所述主数据结构(203)的共享扫描，其中所述主数据结构(203)中的所述数据库条目结合所述批量数据库查询中的每个数据库查询进行查询；以及，在所述共享扫描的步骤之后，合并所述主数据结构(203)与所述增量数据结构(205)以随着所述新条目更新所述主数据结构(203)。

16.根据权利要求15所述的数据处理系统，其特征在于，所述处理器(209)用于在不同时间点或在预定时间点执行所述共享扫描以及合并所述主数据结构(203)与所述增量数据结构(205)。

17.根据权利要求15或16所述的数据处理系统，其特征在于，所述数据处理系统可编程地用于执行根据权利要求14所述的计算机程序。