CN110362566A - 分层htap数据库的混合数据布局中的数据布置 - Google Patents

分层htap数据库的混合数据布局中的数据布置 Download PDF

Info

Publication number
CN110362566A
CN110362566A CN201910232077.4A CN201910232077A CN110362566A CN 110362566 A CN110362566 A CN 110362566A CN 201910232077 A CN201910232077 A CN 201910232077A CN 110362566 A CN110362566 A CN 110362566A
Authority
CN
China
Prior art keywords
column
data
primary storage
storage medium
performance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910232077.4A
Other languages
English (en)
Other versions
CN110362566B (zh
Inventor
哈索·普拉特纳
马蒂亚斯·乌夫拉克
马丁·布瓦西耶
赖纳·施洛瑟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hasopratena Digital Engineering Research Co Ltd
Original Assignee
Hasopratena Digital Engineering Research Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hasopratena Digital Engineering Research Co Ltd filed Critical Hasopratena Digital Engineering Research Co Ltd
Publication of CN110362566A publication Critical patent/CN110362566A/zh
Application granted granted Critical
Publication of CN110362566B publication Critical patent/CN110362566B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • G06F16/212—Schema design and management with details for data modelling support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • G06F16/213—Schema design and management with details for schema evolution support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/217—Database tuning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G06F16/2386—Bulk updating operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种计算机实现的方法，用于将在数据库中存储的表的列分配到至少两个列集合：第一集合和第二集合中，使用面向列的数据结构将分配至第一集合的列的数据存储在主存储介质上，以及使用面向行的数据结构将分配至第二集合的列的数据存储在辅助存储介质上，其中，该方法包括基于性能成本模型自主地将表的列分配至第一集合和第二集合。

Description

分层HTAP数据库的混合数据布局中的数据布置
技术领域
本发明涉及用于将在数据库中存储的表的列分配到至少两个列集合：第一集合和第二集合中的方法，使用面向列的数据布局将分配至第一集合的列的数据存储在主存储介质上并且使用面向行的数据布局将分配至第二集合的列的数据存储在辅助存储介质上。本发明还涉及被配置成执行这样的方法的数据库系统。
背景技术
许多现代企业系统不再被分成传统的面向事务的系统和面向分析的数据仓库。期望现代混合工作负载(称为HTAP或OLxP)系统在单个系统上处理事务性OLTP工作负载以及分析性OLAP工作负载两者。哪种存储格式最适合混合工作负载还存在争论。虽然对于分析任务表现良好，列式表布局对于写入密集型OLTP工作负载尤其是插入和宽元组重构产生大的开销。面向行的表布局已经证明不足以用于未来企业系统的不断增加的分析工作负载。因此，商业数据库供应商将列式存储引擎添加到其行存储。
为了组合两者的各方面，在现有技术中，已经提出了混合系统，其在单个存储引擎中组合行面向和列面向两者并且根据工作负载调整表的布局。这些混合系统中的许多系统呈现出对纯粹的面向行或面向列的变式的改进。但是至少两个原因导致这些结果存在问题。首先，大多数混合研究原型使用相同的执行引擎来评估混合结构相对于同构布局的性能。因此，同构实现方式为混合数据布局付出了代价，该混合数据布局通常产生不利地影响数据库性能的间接和抽象。其次，对同构布局的公知优化(例如，用于顺序操作的SIMD)尚未被充分利用。因此，所提出的系统都没有证明由混合设计带来的优点值得所增加的复杂性。混合存储引擎的增加的复杂性在数据库的更高级功能中引入了新的复杂性，原因是查询优化以及查询执行两者必须处理附加变量和不确定性。因此，仍然不能确定所获得的灵活性是否值得例如在查询计划构建期间进一步阻碍最优决策的增加的复杂性。虽然通过查询编译可以部分地减轻混合抽象和间接的开销，但是为不同数据格式编译有效查询计划的过程非常复杂。查询优化器的影响通常是10倍的改进，而调优的运行时间系统可能带来10％的改进。
本发明的目的是提供混合数据库的改进的物理布局和改进的数据驱逐和加载(分层)。具体地，本发明的目的是在不影响HTAP工作负载模式的性能的情况下向辅助存储介质提供改进的数据驱逐。与这样的混合数据库相关联的益处包括减少主存储占用，这可以降低硬件成本、允许单个服务器上的更大系统、提高弹性、减少恢复时间以及允许执行更多存储器密集型算法。
发明内容
本发明的第一方面涉及根据权利要求1所述的计算机实现的方法。
这样的计算机实现的方法可以用于例如混合工作负载的混合主存储器优化数据库以便将不经常访问的数据驱逐到较便宜的存储介质。这允许调整整体存储布局以减轻对辅助存储的负面性能影响。关键技术问题之一是确定将哪些数据放在哪个存储介质上，这通过使用性能成本模型来解决，该性能成本模型优选地是工作负载驱动的并且优选地将重新分配成本考虑在内。
本发明的第二方面涉及根据权利要求13所述的数据库系统。
附图说明
在所附权利要求中特别地阐述了本发明的特征。然而，通过参照本发明的以下详细描述可以最好地理解本发明本身，本发明的以下详细描述结合附图描述了本发明的示例性实施方式和基本原理，在附图中：
图1示出了用于数据库表的示例性数据布局，该数据布局具有三个列组(CG)。前两组都是词典编码的存储器驻留列(MRC)。剩余属性被无任何压缩地存储在辅助存储列组(SSCG)中。
图2是示出生产SAP ERP系统的表BSEG的属性及其过滤频率的图。291个属性根本没有被过滤并且因此将被驱逐到辅助存储。前两组示出了固定属性(例如，OLTP的关键属性)，而剩余属性的分配将由列选择解决方案决定。
图3是示出用于BSEG表的最优整数和连续解的比较的图：相对性能和主存储中加载的数据的不同组合。
图4是示出示例1的整数和连续方法对试探法(H1)至(H3)的估计的运行时间比较的图。
图5是示出用于跟踪的企业系统的BSEG表的整数/连续方法对试探法(H1)至(H3)的估计的运行时间比较的图。
图6是示出用于改变主存储预算的列选择(整数、连续和连续填充)的图，w∈[0，1]。该图指示列是否在示例1的主存储(示出为蓝色，xi＝1，i＝1，...，50)中。
图7是示出用于合成数据集上的全宽元组重建的时延的图(均匀分布的访问)。
图8是表ORDERLINE和BSEG上的全宽元组重建的时延箱线图(均匀分布和zipfian分布的访问)。
图9是示出顺序访问模式的运行时间性能的图。
具体实施方式
结合附图，在下文中根据示例实施方式描述本发明的技术内容和详细描述，而不是用于限定本发明的执行范围。根据所附权利要求进行的任何等同变化和修改全部由本发明所要求保护的权利要求涵盖。
本发明涉及计算机实现的方法，用于将在数据库中存储的表的列分配到至少两个列集合：第一集合和第二集合中，使用面向列的数据结构将分配至第一集合的列的数据存储在主存储介质(也称为主存储)上以及使用面向行的数据结构将分配至第二集合的列的数据存储在辅助存储介质(也称为辅助存储)上，其中，该方法包括基于性能成本模型自主地将表的列分配至第一集合和第二集合。本发明还涉及被配置成执行所述方法的数据库系统。
优选地，基于性能成本模型，确定哪些列在被分配至第二集合(即，被添加到SSCG)时对性能具有最小的负面影响。优选地，通过计算需要被处理的所需数据来确定效用(即，预期性能)。初看起来，该列分配问题涉及二进制背包(Knapsack)问题：对于给定空间约束(即，主存储预算)使效用(即，期望性能)最大化。但是，背包方法不能用于解决当前的列分配问题，因为在主存储中具有列的效用通常取决于其他列决策(即，存在选择相互作用)。因此，该问题属于资源分配问题的类别，其通常必须使用合适的求解器来解决。解决本问题的替选及有利的方式是下面进一步描述的实施方式的主题。
优选地，为了保持复杂性可管理，仅使用两种数据结构：(i)单列组(第一集合)，其恰好存储一个属性并且驻留在主存储介质(例如DRAM)上，以及(ii)面向行的列组(第二集合)，其将相邻的属性存储在一起并且驻留在辅助存储介质上。图1中描述了示例数据布局。优选地，由顺序读取支配的属性被存储在面向列的数据结构(可以被称为主存储驻留列，PSRC，或者，当主存储介质是DRAM时，称为存储器驻留列，MRC)中。有利地，对PSRC执行所有或大多数顺序操作，例如过滤和连接。优选地，面向列的数据结构使用保序词典编码。优选地，可以采用对PSRC的优化技术，例如矢量化、SIMD以及利用后期实体化处理压缩数据。对于面向行的列组，要注意的是，用于辅助存储驻留列存储的最昂贵的操作之一可以是宽元组重建。对于具有100个属性的表，例如，来自磁盘驻留和词典编码的列存储的完整元组重建通常可能需要从磁盘读取至少800KB(即，以4KB读取一次来对值矢量和词典两者进行100次访问)。相比之下，面向行的列组(可以称为辅助存储列组，SSCG)对于以元组为中心的访问(例如，元组重建或探测)是优选的。
优选地，出于性能原因，SSCG以未压缩的方式存储。这是由于用于元组访问的改进的数据位置而导致的空间消耗(假设辅助存储层比主存储层更便宜)与性能之间的权衡。但是可以替选地采用逐页压缩。使用所提议的SSCG，全宽度元组重建仅需要对辅助存储进行单个4KB页面访问。
优选地，经由增量分区来处理元组插入、删除和更新，该增量分区优选地驻留在主存储介质上。因此，在SSCG中存储的属性类似于磁盘驻留行存储。这样，可以利用面向行的数据结构的两个主要优点：(1)由于元组的属性被连续存储在一个地方而相对容易驱逐；以及(2)对于元组重建的具有用于点访问的准确缓存位置的优点。相比之下，PSRC属性类似于内存数据库，例如SAP HANA或HyPer，其对列式词典编码的属性执行分析/顺序操作。
优选地，使用索引(如果存在的话)来执行针对表的查询。优选地，通过增加选择率性来对查询过滤器进行排序(对于具有n个不同值的属性，属性选择率可以针对等式谓词被定义为1/n)。随着SSCG布置属性的引入，仅有的变化是非索引列上的过滤器首先按定位(主存储驻留或非主存储驻留)排序并且然后按选择率排序。目标是经由对主存储驻留列的索引访问或扫描来确保快速查询过滤。目标是将在顺序操作中经常使用的这些列保持在主存储中。在现实生活场景中，许多属性结合高度限制性属性被过滤。优选地，只要剩余的合格元组的分数低于特定阈值(通常设置为表的元组计数的0.01％)，查询执行器就从扫描切换到探测。探测主存储驻留单元仍然比从辅助存储访问4KB页面更快，但是元组探测延迟越长，当前评估的元组是结果集合的部分的概率越高。这样，在过滤期间的捎带探测被应用以便在元组的若干投影属性是结果的部分的情况下加载主存储器中的剩余属性。
根据本发明的实施方式，方法还包括将完全未被过滤的所有列分配至第二集合的预处理步骤。
根据本发明的实施方式，在数据库的操作期间重复且自主地执行分配列的步骤。但是，如果数据库管理员具有附加性能要求，可以将属性手动固定到第一集合或第二集合。例如，包含关键属性的列可以被手动固定到第一集合以确保足够的事务性能或满足用于特别重要过程的服务等级协议(SLA)(参见图2)。
根据本发明的实施方式，性能成本模型将如下参数中的至少一个考虑在内：数据库在操作期间已经历的工作负载的执行时间；以及主存储介质上的总可用空间。优选地，将两个参数考虑在内。
优选地，将列分配至主存储介质使得(i)使整体性能最大化，即，使工作负载的执行时间最小化，以及(ii)使用的总主存储介质不超过给定预算。与工作负载相关的性能成本模型是有利的，因为在实际数据表中，属性中的仅一部分被访问以用于过滤(即，选择)。并且过滤后的列中的许多列(i)被非常少地过滤，或者(ii)通常与其他高度限制性的属性结合地过滤。利用知道属性选择率与布置之间的相互作用的执行模型，不存在于主存储中的这些列的负面影响可以忽略。因此，属性通常可以分成两个集合：(i)针对表搜索、聚合、连接以及有利于列式布局的其他顺序操作而访问的列；以及(ii)例如从未被访问或针对元组重建或探测被点访问的剩余列。
为了建立与工作负载相关的性能成本模型，数据库系统的工作负载优选地由N个列和Q个查询表征。根据优选的以带宽为中心的工作负载模型，每个查询j由在查询评估期间访问的列集合j＝1，...，Q表征。优选地，所有访问都被建模为具有特定选择率的扫描(例如，OLAP连接和聚合是大的顺序访问)。查询的访问成本优选地取决于发生的列是否在主存储中。为了指示列i是存储在主存储器中(1)或没有存储在主存储器中(0)，优选地使用二进制决策变量xi，xi∈{0，1}，i＝1，...，N。以字节为单位的ai列i的尺寸可以用ai表示。
优选地，性能成本模型取决于总扫描成本F。总扫描成本进而可以取决于列分配并且由所有查询j的扫描成本fj乘以其出现次数bj的总和来定义：
根据实施方式，性能成本模型将列相互作用考虑在内。有利地，与各种简单的试探法相比，这可以显著提高求解品质。对于行存储中基于元组的查询评估(参见Volcano模型)，竖直分区通常通过对过滤频率计数并且相应地确定分区的试探法来实现。这是面向行的数据库中基于元组的查询评估的可行方法，因为第一谓词的执行自动加载元组的剩余属性。然而，大多数HTAP数据库是列存储，列存储以完全不同的方式执行谓词。此处，谓词(通常)按其选择率(首先执行最严格的谓词)来排序，并且在每个运算符传递一系列合格位置处连续执行。由于连接谓词的乘法选择率，预期的访问次数随每个执行的谓词而减少。因此，减少了频繁访问主存储中的列的影响。尽管其他列不经常被过滤，但是将其存储在主存储中可以有利的。对于已编译的查询引擎，运算符以基于元组的方式被链接和处理并且仅在先前(连接)谓词评估为真的情况下才加载下一谓词属性。两种方式，利用每个连续的过滤器，访问后续属性中的一小部分。因此，对滤波器频率进行计数不是用于列式执行引擎中的竖直分区关系的合适模型。要解决的问题更类似于具有索引相互作用的索引选择的问题。
优选地，数据库系统按属性选择率的升序执行属性过滤器。因此，每个谓词的预期选择率取决于查询中的其他属性。根据优选的性能成本模型(本文中也称为“模型”)，假设首先扫描具有较低选择率的列。
优选地，该模型也将已经被扫描的列的选择率考虑在内。列i的选择率Si是具有相同属性的行的平均份额，i＝1，...，N。注意，为了简单起见，仅定义用于具有均匀值分布的等谓词的选择率。数据库系统优选地(如果可用的话，使用不同的计数和直方图)估计选择率，这些选择率在模型中直接实现。优选地，查询j的扫描成本fj由以下描述，j＝1，...，Q：
其中cmm＞0是主存储器的扫描成本参数；css＞0表示辅助存储的成本参数。优选地可以校准两个参数：它们描述了读取数据所花费的时间(例如，读取千兆字节数据的秒数)并且用于计算估计的运行时间。
通常，让cmm＜css。给定列选择存储主存储器驻留数据所需的主存储器中分配的空间量合计为：
对性能成本模型的求解优选地提供了一方面考虑到性能成本且另一方面考虑到主存储介质的消耗的帕累托最优求解。可以以各种方式来求解模型。例如，它可以使用如下所述的求解器来求解：
步骤1：初始优化问题：该问题是使总扫描成本最小化，使得使用的主存储不超过给定预算A，即，我们考虑目标：
由于我们避免了在扫描成本和使用的主存储的定义中的条件表达式，因此整数问题(2)至(3)是线性的，并且因此可以使用标准整数求解器来求解。
步骤2：变量的松弛：我们将问题(2)至(3)建模为连续线性问题，即，我们允许变量xi，i＝1，...，N采用0与1之间的连续值：
使用标准求解器可以解决具有(4)和(3)的松弛问题。但是，解不一定是整数类型。在步骤3中，我们使用(4)和(3)的重构来保证在连续框架中允许的整数解。
步骤3：尺寸约束的惩罚制定：我们省略了约束(3)并且将惩罚项包括在用于所使用的主存储空间的目标(4)中：
惩罚参数α被假定为非负。新问题(5)具有如下基本性质。
引理1.对于所有的α，连续线性问题式(5)的解被保证是整数。
证明.目标(5)的等量形成超平面。使线性目标(5)最小化与其中最佳超平面接触可行区域的点(用于)对应。因此，可行区域的角(N维立方体)始终是最优解的部分。由于所有角都具有整数坐标(约束矩阵的总幺模性)，因此保证了整数类型的最优解。
注意，(5)的最优(整数)解取决于惩罚参数α。α越高，由最优解所使用的主存储空间越低。虽然对于α＝0(没有惩罚)时，所有列都在主存储中，但是对于α→∞，根本没有选择任何列。因此，可以选择α使得相关联的列选择仅满足预算约束(3)。
发明人已将整数和连续解方法应用于生产SAP ERP系统的BSEG表的工作负载和数据(总共20,000个计划，60个用于BSEG)。
在不失去一般性的情况下，发明人使用A＝A(w)：＝w·∑i＝1，...，Nai，其中w，w∈[0，1]，是相对存储器预算。“相对性能”被定义为最小扫描成本(其中所有列驻留在主存储器上)除以(1)至(2)中定义的特定解的扫描成本
图3示出了针对不同存储器预算w的整数和连续模型的解。允许的主存储越多，相对性能越高。仅通过根据历史工作负载分配未被用于第二集合的列来实现超过78％的初始驱逐率。根据连续和整数解来分配剩余的22％。BSEG的工作负载很大程度上依赖于所谓BELNR的最大列之一。超过95％的驱逐率的性能的突然下降是由于BELNR不再适合存储器预算的事实造成。根据我们的模型，对于高达95％的驱逐率，顺序访问减缓了不到25％。注意，整数式(参见问题(2)至(3))允许识别性能和主存储预算的最优组合。这些组合不能被其他组合支配，并且因此形成“帕累托有效边界”(参见图3)。
使用不同的惩罚参数α，连续问题式(5)允许识别性能和所使用的也是有效的主存储预算的可行组合。
定理1.对于所有α＞0，连续问题(5)的解是有效边界的部分，其由对于不同的DRAM预算A的整数问题(2)至(3)的最优解表征。因此，它们是帕累托有效的。证明.对于任意但固定的惩罚α＞0，让成为连续问题(5)的最优解。因此，也是具有预算的服从于(3)的连续问题(4)的最优解，因为具有和的服从于(3)的(4)的更好的解意味着对于(5)不是最优的。此外，使成为具有相同预算的服从于(3)的整数问题(2)的最优解。由此得出因为问题(5)中的可行空间支配问题(2)中的可行空间，即，此外，引理1暗示是整数类型，并且因此是具有预算的问题(2)的可接受候选项。由此得出最后，是不可能的，因为暗示是与相比对(5)更好的解，这是矛盾的。因此，我们也有
有利地，根据本发明的分配列优于简单的试探法。我们考虑可重现的列选择问题的一般可扩展类。所考虑的试探式算法是贪婪的方法，这类似于竖直分区模型的现状。考虑三种试探法，其通过(i)选择频率、(ii)通过选择率以及通过对每个属性的选择率和尺寸加权来评估属性。属性评估的动机是LRU方法和构建驱逐顺序的所使用的度量。
示例1.我们考虑N个列、Q个查询和随机参数值。我们比较了连续模型(参见(5))的解的最优整数解(参见(2)至(3))以及如下三种基准试探法的分配：(H1)包括由出现次数gi测量的、主存储中的最常用的列(按降序排列)，其中(H2)包括主存储中的具有最小选择率si的列，i＝1，...，N(按升序排列)。(H3)包括主存储中的具有选择率与出现次数的最小比即si/gi，i＝1，...，N，(按升序排列)的列。如果列不再适合主存储预算，则检查更高顺序的列是否适合。在所有试探法中，不考虑根本不使用的列(gi＝0)。我们针对不同的主存储预算A(w)求解示例1。我们考虑N＝50个列和Q＝500个查询。我们应用整数和连续求解方法以及试探法(H1)至(H3)。图4示出了针对不同列选择策略的估计运行时间和相关联的主存储预算w的不同可接受组合。
整数问题的解形成有效边界。连续问题的解再次成为有效边界的一部分。我们观察到我们的两种方法都优于所有三种试探法(H1)至(H3)。根据主存储预算，性能最高提高至3倍。通常，试探法(H1)至(H3)是合理的试探式算法。在示例1中，一些列更通常地被包括在查询中。因此，平均而言，对应的gi值更高。此外，在我们的示例中，gi和选择率si略微负相关。这解释了为什么像(H1)和(H2)这样的纯试探法是次优化的。试探法(H3)实现更好的性能结果，原因是两种效果都被考虑在内。然而，这些结果仍远未达到最优，因为没有考虑更复杂的效果，例如选择交互作用。与实际工作负载一样，在我们的示例中，一些列通常同时出现在查询中。因此，建议仅选择其中一些至主存储中。发明人的基于模型的解产生了更好的结果，因为所有复杂的效果都被考虑在内。示例1可以用于研究针对各种工作负载特征的试探法的性能。对于特殊情况，基于规则的试探法可以良好地执行。然而，只要选择相互作用成为因素，仅先进的方法才能导致良好的结果。注意，在实际设置中，工作负载通常是复杂类型的。在该上下文中，图5示出了用于BSEG表的性能结果(参见第III-B节)。我们观察到，选择率与访问次数之间的相互作用甚至导致试探法的性能更差(多达10倍)。不可能存在适合所有场景的简单试探法。这是由于通过量bj、gi、si和ai的复杂相互作用表征的工作负载的不可预见的特征以及诸如选择相互作用或查询qi的结构的其他重要效果。因此，有效的分配策略必须(在合理的时间量内)找到同时考虑所有这些效果的复杂的定制解。注意，对连续模型的解是特定类型的，因为它们被确保在任何设置中都有效。
根据本发明的实施方式，性能成本模型还将用于重新分配列的成本考虑在内。这是有利的，因为实际设置的导入方面是重新分配成本。由于工作负载通常随时间而变化，因此必须定期重新计算当前数据布置。然而，数据分配的重新组织是昂贵且耗时的。面临的挑战是识别与其成本相比对性能产生显著影响的重新分配。
当前列分配yi∈{0，1}，i＝1，...，N和用于改变列的存储器定位(从辅助存储至主存储，或从主存储至辅助存储)的成本参数β。我们扩展模型(5)以使总扫描成本、使用的主存储空间和存储器改变最小化：
由于重新分配成本，问题的目标变得非线性。为了线性化(6)，我们引入在[0，1]上是连续的附加变量zi，i＝1，...，N。此外，我们添加两个线性约束族使得问题(6)可以等效地重写为：
服从于xi-yi≤zi，i＝1，...，N
yi-xi≤zi，i＝1，...，N
新约束保证：对于所有i，zi＝|xi-yi|。此外，由于约束矩阵的总幺模性仍然被满足，因此保证(7)和(6)的整数解。实际上，基于系统的要求来选择β。在大多数情况下，在夜晚时间期间执行物理数据维护。在该上下文中，应当每天使数字bj标准化，并且β＝1可以作为参考情况。我们可以获得预期的维护持续时间(通常受辅助存储带宽限制)并且相应地调整β使得我们仅启动将在允许的维护时间框架内完成的重新分配。
根据本发明的实施方式，分配列的步骤包括如下步骤：迭代地将列添加到第一集合，使得，在每次迭代中将如下的列添加到第一集合：
-该列在先前迭代中未被添加，以及，
-根据性能成本模型，如果该列被添加到第一集合，则该列提供主存储介质上的每占用空间的最大性能增益。
根据本发明的实施方式，分配列的步骤还包括如下步骤：如果如下的列由于所有添加的列所占用的总空间超过主存储介质上可用的总空间而不能被添加：
-该列在先前迭代中未被添加，以及
-根据性能成本模型，如果该列被添加到第一集合，则该列提供主存储介质上的每占用空间的最大性能增益；
则，将至少一个列添加到第一集合：
-所述至少一个列在先前迭代中未被添加，以及
-所述至少一个列适合主存储介质上的剩余空间。
先前两个实施方式带来的优点是，不需要应用计算上昂贵的求解器来获得对列分配问题的解。这可以鉴于图6来理解，图6示出通过使用求解器来求解性能成本模型而获得的最优分配。图6(a)示出了根据针对不同w值的整数解的列分配。图6(b)示出了根据连续解的列分配。根据整数问题的列分配是非常复杂且不规则的，然而根据连续分配的列分配具有规则的递归结构。
备注1.考虑问题(6)：如果列i，i＝1，...，N被分配至主存储用于预算A＝A(α)，A≥0的，则列i也被分配至主存储分配以用于所有较大预算因此，问题(6)的解具有递归结构并且列以固定顺序被分配至最优分配。
备注1中描述的列的顺序可以称为“性能顺序”，其允许根据列对减少运行时间的影响来对列的集合进行排序。注意，可以进一步改进连续解。图6(c)描绘了这样的情况，其中对于给定预算A(w)，优选地根据以上描述的性能顺序用至少一列填充用于根据连续模型的解的主存储介质上的剩余空间。该具有填充的递归分配策略非常类似于最优整数求解(参见图6(a))。
以下是在不应用计算上昂贵的求解器的情况下可以如何计算(6)的解的详细示例。关键的想法是明确地得到性能顺序oi。列是否应该在主存储介质中的决定归结为xi对(6)具有正面影响还是负面影响的问题。由于其结构，目标(6)可以被写成∑i＝1，....，Nci(xi)+C，其中C是常数。收集依赖于xi的项，我们得到ci，i＝1，...，N，合计为
ci(xi)：＝ai·((Si+α)·xi+β·|xi-yi|) (8)
其中，I＝1，...，N，
因此，列i的选择对(6)具有正面影响还是负面影响取决于其对(8)的影响。
定理2.(i)满足给定主存储预算A的问题(6)的帕累托最优解可以如下计算：按照顺序oi，i＝1，...，N在主存储中包括尽可能多的列，其中Si+β·(1-2yi)＜0，由如下限定
oi：＝|{k＝1，...，N：Sk-2·β·yk≤Si-2·β·yi}|
(ii)备注1中描述的结构通常成立。
(iii)在(i)中递归地选择列使得每个附加的主存储的附加运行时间改进被最大化。
(i)的证明：考虑(8)，我们区分如下四种情况，i＝1，...，N：
·如果yi＝0并且Si+α+β＜0则在xi下(8)减小.
·如果yi＝0并且Si+α+β≥0则在xi下(8)增大.
·如果yi＝1并且Si+α-β＜0则在xi下(8)减小.
·如果yi＝1并且Si+α-β≥0则在xi下(8)增大.
总结这四种情况，我们得到如果，i＝1，...，N，
Si+α+β·(1-2·yi)＜0 (9)
则xi下(8)减少并且是最优的，否则我们得到因此，如果α减小，则(9)的左手侧也减小，并且进而，一列i接着另一列被包括在主存储器中。将列包括在主存储中的顺序与性能顺序oi一致(参见备注1)。现在，可以通过比较每列i的临界α值来容易地确定oi，该临界α值使(9)的左手侧等于零。具有最小值Si-2·β·yi的列是被放入主存储中的第一列。最后，顺序oi允许计算对于给定的预算A是可接受的(6)的帕累托最优解。
(iii)的证明。假设列分配与(包括重新分配成本)的运行时间对应。在主存储中选择新列i(xi：＝1)使值F减小了ci(1)-ci(0)＝ai·(Si+β·(1-2yi))(参见(8))，而使用的主存储预算增加了ai。注意，定理2(i)中定义的策略结合了两个优点：分配必然是帕累托最优的并且可以像简单试探法(参见(H1)至(H3))一样快速地计算，因为不再需要惩罚值a。
备注2.定理2(i)的结果可以与填充试探法结合：将最重要的列包括在主存储中，参见Oi。如果列不再适合主存储预算A，则检查更高顺序的列是否适合，参见图6(c)。
定理2(iii)中描述的分配策略揭示了解决识别产生最大影响的关键列的挑战性问题的通用的求解原则。
备注3.我们提出如下递归试探法：随后选择列使得根据性能成本模型使每个“使用的附加主存储”的“附加性能”最大化。
备注3的试探法允许性能与主存储预算的近似的帕累托最优组合。该方法是有效的，因为有效边界自然地以凸起形状为特征，参见图4和图5，因为主存储的附加单元的值随着存储器预算而减小(边际效用递减)。该原理可以适用于计算用于具有高度复杂(例如，非线性)扫描成本函数的更一般的列分配问题的优化分配。此外，如果使用查询优化器的假设部件，也可以应用该方法，因为它类似地允许估计以及比较特定列选择的相对性能改进。
根据本发明的实施方式，数据库是组合的OLTP和OLAP数据库。
根据本发明的实施方式，主存储介质是DRAM介质。
根据本发明的实施方式，辅助存储介质不是DRAM介质。
根据本发明的实施方式，辅助存储介质是SSD、HDD或任何非易失性存储。
根据本发明的实施方式，表的列中的至少一个被手动固定到第一集合并且因此被排除在基于性能成本模型自主地将表的列分配至第一集合和第二集合的步骤之外。
根据本发明的实施方式，基于历史工作负载数据，特别是使用时间序列分析来确定数据库在操作期间经历的工作负载。根据该实施方式，基于历史工作负载数据即，针对数据库系统的不同查询的出现次数来确定工作负载。优选地，考虑仅具有特定时间时段的工作负载。甚至更优选地，使用时间序列分析。这是有利的，因为工作负载可能随时间而改变。时间序列分析甚至可以示出可以被考虑在内的周期性行为。
根据本发明的实施方式，分配至第一集合的列的数据沿着列被词典压缩。
根据本发明的实施方式，分配至第二集合的列的数据未被压缩。
根据本发明的实施方式，主存储驻留列保持词典编码而剩余属性被以面向行且延迟优化的格式存储在辅助存储上。优选地，分层表的每列被完全且单独地以没有任何复制或附加数据结构的单一格式存储。
根据本发明的实施方式，分配至第二集合的列的数据被逐页压缩。
根据本发明的实施方式，在数据库系统中提供允许扫描很少经过滤的属性的附加格式，例如用于辅助存储的磁盘优化列格式。替选地，数据库系统中不提供附加格式。后者在端至端的考虑中可以更优越，因为它更易于维护并且不增加诸如查询优化的更高级功能的复杂性。
特定示例实施方式
根据本发明的特定示例实施方式，数据库系统是Hyrise系统。Hyrise是用于HTAP工作负载的混合主存储器优化数据库。优选地，Hyrise中的每个表包括两个分区，写优化的增量分区(参见C-Store的可写存储)和读优化的主分区。使用仅插入方法，将数据修改写入定期合并到主分区中的增量分区。主分区中的属性通过比特打包的保序词典进行词典编码。增量分区中的属性使用带有附加B+-树的未排序词典以用于快速值检索。使用多版本并发控制实现Hyrise中的ACID合规。
Hyrise能够以自由的方式组合面向行和面向列的数据布局以及水平和竖直分区。虽然Hyrise的最初目标是在完全DRAM驻留的情况下提高缓存命中率，但是本发明的目的是减轻辅助存储的负面性能影响。优选地，使用包括可变长度的列组的简化的混合格式。
在下文中，描述了特定示例实施方式的性能。所有基准均在四插槽FujitsuPrimergy RX4770 M3上执行，其具有Intel Xeon E7-4850 v4 CPU(每插槽16个核，40M L3缓存，2.1GHz)、2TB的DRAM、运行具有内核4.2的64位Ubuntu 14.04 LTS。发明人评估了如下设备：CSSD：具有256GB存储容量的消费级固态硬盘(Samsung SSD 850Pro)、ESSD：具有1TB存储容量的企业级SANDISK Fusion ioMemory PX600 SSD、HDD：具有4TB存储容量和64MB缓存的SATA连接的Western Digital WD40EZRX HDD、3D XPoint：基于3D XPoint的IntelOptane P4800X。两种固态硬盘都是广泛用于现代数据中心的NAND设备，而ESSD是通过大型IO队列达到其最佳性能的带宽优化设备。3D XPoint设备是不使用NAND架构的第一代固态驱动器。该设备特别有趣，因为它的随机访问延迟比NAND设备低10倍，即使对于短IO队列也是如此。HDD设备用作参考设备。由于其随机访问性能较差，因此该设备不被包括在实体化测量中。
基准数据集：发明人评估了对三种不同数据集的性能：(i)SAP ERP数据集，其反映分析的生产SAP ERP系统的BSEG表的特征(不同的计数、数据类型等)。BSEG表是财务模块的中心表并且在SAP ERP系统中具有最高的分析负载(具有345个属性的20M个元组)。(ii)TPC-C数据由具有3 000(300M个元组)的比例因子的TPC-C基准的ORDERLINE表组成。(iii)合成数据集是具有10M个元组和200个属性的表，其填充有随机整数值。BSEG和ORDERLINE表两者属于每个系统的最大表并且因此对于我们关注冷数据驱逐是特别感兴趣的。ORDERLINE和BSEG具有非常不同的宽度(10个对345个属性)并且描绘在我们的实现方式中对元组重建的影响的两个极端。在讨论端至端性能之前，简要讨论与普通Hyrise相比较的修改部件。发明人的数据分配模型旨在将所有顺序访问的列保持在DRAM中。因此，除了非常紧凑的DRAM预算之外，分析性能保持不变。但是，可能对Hyrise的事务性能产生负面影响的若干个部件已经被修改。
事务处理：Hyrise使用MVCC来确保并发且事务地安全访问数据。将与MVCC有关的列保持不变并进行DRAM分配。因此，事务性能不受影响。
指标：为了确保点访问的高吞吐量，Hyrise有若干个索引结构，例如单列B+-树和多列复合键。优选地，指标不被驱逐并且被完全保持DRAM分配。
数据修改：修改的吞吐量和时延不受影响，因为通过使用仅插入方法，修改由保持完全DRAM驻留的增量分区(参见第II节)处理。然而，将增量分区与主分区合并的定期处理受到负面影响。但是由于合并处理是异步且无阻塞的，因此在合并阶段期间持续事务既不被阻止也不减缓。
发明人评估了本方法对TPC-C和CH-benCHmark的性能。由于未改变的事务分量，仅影响读取查询。因此，除了异步合并阶段之外，运行时性能在很大程度上取决于给定的存储器预算。对于TPC-C的最大表ORDERLINE，选择/聚合10列中的4列，从而留下要被驱逐到磁盘的至少6列。可能毫不奇怪给定TPC-C的复杂性，当前数据分配模型将ORDERLINE分成作为主存储驻留列(PSRC)的四个关键属性以及将剩余属性分至辅助存储列组(SSCG)中。表III示出了TPC-C的交付事务和CH-查询#19的相对性能影响。
虽然TPC-C的性能结果很有希望，但是注意TPC-C的工作负载和数据模型较简单并且没有性能关键路径访问分层数据。对于访问ORDERLINE以主要用于分组、过滤和连接(非分层)关键列的CH-benCHmark同样也是部分正确的。更有趣的是对非关键列进行过滤的CH查询#19。给定w＝0.2的DRAM预算，仅ORDERLINE的关键列保持DRAM驻留并且甚至分析访问的列也作为SSCG的部分被驱逐。对于查询#19，ol_i_id上的连接谓词和ol_w_id上的谓词不受影响，但是对分层列执行ol_quantity上的范围谓词。对于100的仓库计数，Hyrise探测具有0.05的选择率的ol_quantity。在表III所示的配置中，单独的探测减缓了40倍，这导致整体查询减缓6.7倍。如果我们允许w＝0.4的更大的DRAM预算，则列ol_delivery_d和ol_quantity变为将减缓降低到1.12的DRAM驻留，这可以归因于ol_amount(SSCG-布置)的窄实体化。本节的其余部分将研究在我们的原型实现方式中已经改变的三种访问模式：(i)对宽元组重建的随机访问，(ii)顺序扫描分层列，以及(iii)探测分层列。
发明人关于分层性能的主要焦点是宽元组重建的时延。特别是对于列存储，宽元组重建是昂贵的，因为每个属性实体化可能导致两个L3缓存未命中(访问值矢量和词典)。发明人通过使用均匀随机分布随机访问选择的元组来测量重建性能。发明人将页面高速缓存设置成被驱逐数据尺寸的2％并且禁用页面固定。访问的均匀分布反映了我们实现方式的最坏情况场景，其中在元组重建期间几乎没有缓存命中。发明人测量合成数据集上的全宽元组重建的平均时延以及第99百分位的时延。发明人将在SSCG中存储的属性的数目从20改变至200。针对每个基准，发明人执行10M元组重建。结果如图7所示。针对均匀分布的访问，发明人观察到时延优化的3D XPoint设备优于NAND设备。在比较第99百分位的时延时该趋势更加细微。最值得注意的是，当50％的属性被存储在SSCG中时，3D XPoint上的布置SSCG的元组胜过完全DRAM驻留的词典编码的元组。如图8所示，第二基准使用zipfian(比例＝1)和均匀分布的访问来评估BSEG和ORDERLINE表的元组重建。IMDB(PSRC)表示列式、词典编码且完全DRAM驻留的数据模式。BSEG表由SSCG中的20个PSRC属性和325个属性组成(ORDERLINE：4个PSRC和SSCG中的6个属性)。结果表明，运行时间由SSCG的宽度决定，其中越来越降低时延，布置SSCG的属性的份额越高。分层的未压缩列组(SSCG)能够弥补访问辅助存储的负面性能影响。它甚至可以胜过完全的DRAM驻留情况，因为非本地DRAM访问(由于词典编码，每个属性两次)对于宽表快速总计。针对诸如BSEG表的宽表，性能对于均匀访问提高到2倍以及对于zipfian访问提高到1.1倍。对于窄ORDERLINE表，均匀访问的性能降低70％。
为了评估对分析工作负载的影响，发明人测量了顺序扫描和探测的性能。扫描：我们的方法的重要假设是绝大多数顺序处理仍然在DRAM分配属性上(参见第III节用于列选择和固定)。如果工作负载众所周知并且没有显著改变，则预期顺序处理永远不访问辅助存储。由于未分层的列保持未修改，因此性能保持一样。尽管如此，未预期的工作负载模式或非常低的DRAM预算带来性能问题。它们可能仍然由于(i)特殊或周期性查询或(ii)改变尚未导致适应数据布置的工作负载模式而发生。图9(a)示出了具有变化线程计数和SSCG宽度的列扫描的性能。1/1的列组访问次数表示扫描SSCG中包含单个属性的一个属性。1/100表示扫描SSCG中100个中的一个属性。正如预期的那样，成本与SSCG的宽度成线性比例。原因是以每个单个4KB页面访问读取的有效数据。对于100个整数列，每个4KB页面包含10个要扫描的值，而10个属性的SSCG的每个页面包含100个要扫描的值。HDD对于纯顺序请求执行良好，但是由于多个线程并发请求而显著减缓，然而现代SSD需要用于完全性能的并发访问/更大的IO队列。探测：图9(b)示出了探测性能。由于我们的数据布置模型，希望在分层属性上不经常发生但比扫描更频繁的探测。同样，线程计数对NAND设备的性能也有显著影响，选择率也是如此。表IV列出了对具有完全DRAM驻留和词典编码的列式系统的之前讨论的测量(参见图9(a)和9(b))进行相对减缓比较。
如预期的那样，可以取决于访问的列的数目及其存储层来加快元组重建。顺序访问随着SSCG中存储的属性数目而线性减缓。由于非顺序访问模式，HDD执行探测明显比扫描更差。
对SAP ERP系统的评估表明，通常有5％与10％之间的属性被访问以进行顺序操作，然而只要超过50％的属性被存储在SSCG中(参见图2)发明人的具有SSCG布置的属性的原型就胜过完全DRAM驻留的对应物。SSCG可以补偿辅助存储访问的性能影响。分层SSCG因此值得在Hyrise中的添加的复杂性。只要工作负载已知并且不经常改变，就可以在减少存储器占用的同时提高性能。但是，在对SSCG布置的属性反复进行分析查询的情况下，从性能角度来看，仅可行的方法是将列作为PSRC加载回DRAM中。
有利地，本发明允许可扩展性。企业系统通常有数千个表。针对那些系统，期望数据库管理员手动为每个表设置存储器预算是不现实的。我们提供的解能够确定用于数千个属性的最优数据布置。发明人使用MOSEK求解器4测量具有变化数目的查询和属性的大型合成数据集的求解运行时间。表II对于不同数目的列N和查询Q比较了整数模型的计算时间和示例1的设置中的显式解。表II示出了即使对于大型系统也可以有效地计算优化的数据布置。对于最先进的整数求解器线性问题是可管理的。然而，当系统的尺寸很大时，运行时间可以变大。4MOSEK求解器：https：//www.mosek.com
已使用简单的单线程C++实现方式来本地计算显式解(参见定理2)。如期望的那样，显式解的计算速度快了几个数量级并且允许立即响应。因此，对于数据库管理员变得易于(i)动态更新优化的分配，以及(ii)决定与预期的附加性能相比是否值得允许略微更大的预算。
表I
访问生产SAP ERP系统的统计信息
表II
列选择的运行时间比较
表III
对TPC-C的交付事务和CH-BENCHMARK(3D XPOINT)的Q19的性能影响
图IV
分析访问模式的性能：比较3D XPOINT上的SSCG对DRAM驻留的MRC(32线程)。示出相对减缓(时延SSCG/时延MRC)
表V

Claims (13)

1.一种计算机实现的方法，用于将在数据库系统中存储的表的列分配到至少两个列集合：第一集合和第二集合中，
使用面向列的数据结构将分配至所述第一集合的列的数据存储在主存储介质上，以及
使用面向行的数据结构将分配至所述第二集合的列的数据存储在辅助存储介质上，
其特征在于，
所述方法包括如下步骤：
基于性能成本模型自主地将所述表的列分配至所述第一集合和所述第二集合。
2.根据权利要求1所述的方法，其中，在所述数据库的操作期间重复执行所述分配列的步骤。
3.根据前述权利要求之一所述的方法，其中，所述性能成本模型将如下参数中的至少一个考虑在内：
所述数据库在操作期间经历的工作负载的执行时间，所述执行时间优选地将连续的列式过滤考虑在内；以及
所述主存储介质上的总可用空间。
4.根据权利要求3所述的方法，其中，所述性能成本模型还将重新分配列的成本考虑在内。
5.根据前述权利要求之一所述的方法，其中，所述分配列的步骤包括如下步骤：
迭代地将列添加到所述第一集合，使得在每次迭代中将如下的列添加到所述第一集合：
-该列在先前的迭代中未被添加，以及，
-根据所述性能成本模型，如果该列被添加到所述第一集合，则该列提供所述主存储介质上的每占用空间的最大性能增益。
6.根据权利要求5所述的方法，其中，所述分配列的步骤还包括如下步骤：
如果如下的列由于所有添加的列所占用的总空间超过所述主存储介质上可用的总空间而不能被添加：
-该列在先前迭代中未被添加，以及
-根据所述性能成本模型，如果该列被添加到所述第一集合，该列提供所述主存储介质上的每占用空间的最大性能增益；
则，将如下的列添加到所述第一集合：
-该列在先前迭代中未被添加，以及
-该列适合所述主存储介质上的剩余空间。
7.根据前述权利要求之一所述的方法，
所述数据库是组合的OLTP和OLAP数据库，
所述主存储介质是DRAM介质，
所述辅助存储介质不是DRAM介质，并且/或者
所述辅助存储介质是SSD、HDD或任何非易失性存储器。
8.根据前述权利要求之一所述的方法，其中，所述表的列中的至少一个列被手动固定到所述第一集合并且因此被排除在基于性能成本模型自主地将所述表的列分配至所述第一集合和所述第二集合的步骤之外。
9.根据前述权利要求之一所述的方法，其中，基于历史工作负载数据，特别是使用时间序列分析来确定所述数据库在操作期间已经历的工作负载。
10.根据前述权利要求之一所述的方法，其中，分配至所述第一集合的列的数据沿着列被词典压缩。
11.根据前述权利要求之一所述的方法，其中，分配至所述第二集合的列的数据未被压缩。
12.根据前述权利要求之一所述的方法，其中，分配至所述第二集合的列的数据被逐页压缩。
13.一种被配置成执行根据前述权利要求之一所述的方法的数据库系统。
CN201910232077.4A 2018-03-26 2019-03-26 分层htap数据库的混合数据布局中的数据布置 Active CN110362566B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP18164052.5A EP3547166B1 (en) 2018-03-26 2018-03-26 Data placement in hybrid data layouts for tiered htap databases
EP18164052.5 2018-03-26

Publications (2)

Publication Number Publication Date
CN110362566A true CN110362566A (zh) 2019-10-22
CN110362566B CN110362566B (zh) 2024-03-12

Family

ID=61800420

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910232077.4A Active CN110362566B (zh) 2018-03-26 2019-03-26 分层htap数据库的混合数据布局中的数据布置

Country Status (3)

Country Link
US (1) US11256718B2 (zh)
EP (1) EP3547166B1 (zh)
CN (1) CN110362566B (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11068454B2 (en) 2019-09-23 2021-07-20 Singlestore, Inc. Method of performing transactional and analytical data processing using a data structure
US11567939B2 (en) 2019-12-26 2023-01-31 Snowflake Inc. Lazy reassembling of semi-structured data
US11308090B2 (en) 2019-12-26 2022-04-19 Snowflake Inc. Pruning index to support semi-structured data types
US11372860B2 (en) * 2019-12-26 2022-06-28 Snowflake Inc. Processing techniques for queries where predicate values are unknown until runtime
US10769150B1 (en) 2019-12-26 2020-09-08 Snowflake Inc. Pruning indexes to enhance database query processing
US11907250B2 (en) * 2022-07-22 2024-02-20 Oracle International Corporation Workload-aware data encoding
US11880369B1 (en) 2022-11-21 2024-01-23 Snowflake Inc. Pruning data based on state of top K operator

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140012881A1 (en) * 2012-07-09 2014-01-09 Sap Ag Storage Advisor for Hybrid-Store Databases
US20140214793A1 (en) * 2013-01-29 2014-07-31 Nec Laboratories America, Inc. Cost-Effective Data Layout Optimization Over Heterogeneous Storage Classes
US20140258343A1 (en) * 2011-09-22 2014-09-11 Retail Logistics Excellence - Relex Oy Mechanism for updates in a database engine

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8326669B2 (en) * 2007-04-19 2012-12-04 International Business Machines Corporation System and method for selecting and scheduling corrective actions for automated storage management
US9626421B2 (en) 2007-09-21 2017-04-18 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh ETL-less zero-redundancy system and method for reporting OLTP data
EP2251823A1 (en) 2009-05-11 2010-11-17 Hasso-Plattner-Institut für Softwaresystemtechnik GmbH Business object based navigation
US9542424B2 (en) 2009-06-30 2017-01-10 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh Lifecycle-based horizontal partitioning
EP2270691B1 (en) 2009-06-30 2019-01-16 Hasso-Plattner-Institut für Digital Engineering gGmbH Computer-implemented method for operating a database and corresponding computer system
US8601038B2 (en) 2010-10-08 2013-12-03 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh Available-to-promise on an in-memory column store
EP2472450A1 (en) 2010-12-28 2012-07-04 Hasso-Plattner-Institut für Softwaresystemtechnik GmbH A search method for a containment-aware discovery service
EP2472449A1 (en) 2010-12-28 2012-07-04 Hasso-Plattner-Institut für Softwaresystemtechnik GmbH A filter method for a containment-aware discovery service
EP2472448A1 (en) 2010-12-28 2012-07-04 Hasso-Plattner-Institut für Softwaresystemtechnik GmbH A communication protocol for a communication-aware discovery service
US9424282B2 (en) 2012-03-05 2016-08-23 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh Online reorganization of hybrid in-memory databases
US9015812B2 (en) 2012-05-22 2015-04-21 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh Transparent control of access invoking real-time analysis of the query history
EP2790113B1 (en) 2013-04-11 2017-01-04 Hasso-Plattner-Institut für Softwaresystemtechnik GmbH Aggregate query-caching in databases architectures with a differential buffer and a main store
US10089142B2 (en) 2013-08-21 2018-10-02 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh Dynamic task prioritization for in-memory databases
EP2869218A3 (en) 2013-10-31 2015-07-08 Hasso-Plattner-Institut für Softwaresystemtechnik GmbH Object awareness
US10235377B2 (en) * 2013-12-23 2019-03-19 Sap Se Adaptive dictionary compression/decompression for column-store databases
US10936595B2 (en) * 2014-04-03 2021-03-02 Sybase, Inc. Deferring and/or eliminating decompressing database data
US9846567B2 (en) * 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US10810198B2 (en) * 2017-09-26 2020-10-20 Oracle International Corporation Group determination based on multi-table dictionary codes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140258343A1 (en) * 2011-09-22 2014-09-11 Retail Logistics Excellence - Relex Oy Mechanism for updates in a database engine
US20140012881A1 (en) * 2012-07-09 2014-01-09 Sap Ag Storage Advisor for Hybrid-Store Databases
US20140214793A1 (en) * 2013-01-29 2014-07-31 Nec Laboratories America, Inc. Cost-Effective Data Layout Optimization Over Heterogeneous Storage Classes

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
于利胜;张延松;王珊;张倩;: "基于行存储模型的模拟列存储策略研究", 计算机研究与发展, no. 05, 15 May 2010 (2010-05-15), pages 144 - 151 *

Also Published As

Publication number Publication date
EP3547166A1 (en) 2019-10-02
US20190294615A1 (en) 2019-09-26
US11256718B2 (en) 2022-02-22
CN110362566B (zh) 2024-03-12
EP3547166B1 (en) 2020-12-02

Similar Documents

Publication Publication Date Title
CN110362566A (zh) 分层htap数据库的混合数据布局中的数据布置
CN107851123B (zh) 在存储器中虚拟列单元内具体化表达式以加速分析查询
US11238039B2 (en) Materializing internal computations in-memory to improve query performance
JP6639420B2 (ja) フラッシュ最適化データ・レイアウトのための方法、フラッシュ最適化記憶のための装置、およびコンピュータ・プログラム
Färber et al. The SAP HANA Database--An Architecture Overview.
US20090210445A1 (en) Method and system for optimizing data access in a database using multi-class objects
Boissier et al. Hybrid data layouts for tiered HTAP databases with pareto-optimal data placements
Amur et al. Memory-efficient groupby-aggregate using compressed buffer trees
Durner et al. Crystal: a unified cache storage system for analytical databases
Lu et al. TridentKV: A read-optimized LSM-tree based KV store via adaptive indexing and space-efficient partitioning
Zhang et al. CARMI: a cache-aware learned index with a cost-based construction algorithm
US8583687B1 (en) Systems and methods for indirect algebraic partitioning
That et al. TRIFL: A generic trajectory index for flash storage
Yin et al. PBFilter: A flash-based indexing scheme for embedded systems
Ha et al. Dynamic hot data identification using a stack distance approximation
Liu Efficient storage design and query scheduling for improving big data retrieval and analytics
Memik et al. Multicollective I/O: A technique for exploiting inter-file access patterns
Lim et al. Efficient Stack Distance Approximation Based on Workload Characteristics
Zhang et al. DeStager: feature guided in-situ data management in distributed deep memory hierarchies
Koo et al. FLIXR: Embedding index into flash translation layer in SSDs
Kim et al. Accelerating String-key Learned Index Structures via Memoization-based Incremental Training
Wang et al. HICAMP bitmap: space-efficient updatable bitmap index for in-memory databases
Li Optimizing memory management using timescale theories
Zhang A Memory Hierarchy-and Network Topology-Aware Framework for Runtime Data Sharing at Scale
Schwalb et al. Cache conscious column organization in in-memory column stores

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant