CN110622152B - 用于查询时间序列数据的可扩展数据库系统 - Google Patents
用于查询时间序列数据的可扩展数据库系统 Download PDFInfo
- Publication number
- CN110622152B CN110622152B CN201880014274.2A CN201880014274A CN110622152B CN 110622152 B CN110622152 B CN 110622152B CN 201880014274 A CN201880014274 A CN 201880014274A CN 110622152 B CN110622152 B CN 110622152B
- Authority
- CN
- China
- Prior art keywords
- block
- new
- blocks
- hyper
- database system
- 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.)
- Active
Links
Images
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/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24554—Unary operations; Data partitioning 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/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2474—Sequence data queries, e.g. querying versioned data
-
- 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/2228—Indexing structures
- G06F16/2246—Trees, e.g. B+trees
-
- 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/2228—Indexing structures
- G06F16/2264—Multidimensional index 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/2228—Indexing structures
- G06F16/2272—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/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/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2477—Temporal data queries
-
- 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
-
- 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/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/953—Querying, e.g. by the use of web search engines
- G06F16/9538—Presentation of query results
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Mathematical Physics (AREA)
- Computing Systems (AREA)
- Probability & Statistics with Applications (AREA)
- Fuzzy Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
数据库系统将数据存储为表示分区数据库表的超表。每个超表包括可以跨多个位置分布的数据块,每个位置至少包括存储设备。数据库系统提供允许对超表和标准表的无缝数据库查询的接口。当记录被添加到超表时,数据库系统动态创建块。如果通过添加新位置或移除现有位置来改变数据库系统的存储配置,则数据库系统限定新的分区策略。在存储配置改变之前被添加到超表的记录继续存储为根据先前的分区策略分布的块。
Description
相关申请的交叉引用
本申请要求于2017年2月27日提交的美国临时申请第62/464,289号的权益,其全部内容通过引用并入。
背景技术
本公开内容一般涉及在数据库系统中有效地存储和处理数据,并且特别涉及存储和处理在分区数据库系统中的时间序列数据。
在以下若干环境中生成和处理时间序列数据:监视和开发者操作(DevOps)、传感器数据和物联网(IoT)、计算机和硬件监视、健身和健康监视、环境和农业数据、制造和工业控制系统数据、财务数据、物流数据、应用使用数据等。通常,该数据的量很大,例如,单个数据源可以生成高速率的数据,或者许多不同的源可以贡献数据。此外,该数据本质上是复杂的,例如,源可以提供与单个时间相关联的多个测量和标签。由于数据被不断收集,该存储数据的量通常随着时间的推移而增加。分析系统通常查询该数据以分析与数据相关联的实体的过去、现在和未来的行为。可以出于各种原因执行该分析,包括检查历史趋势、监视当前性能、识别当前问题的根本原因以及预期未来问题以例如用于预测性维护。因此,操作者不倾向于删除该潜在有价值的数据。
常规系统不能支持跨越工业的这些应用中的许多应用的典型的高写入速率。例如,在包括工业、农业、消费者、城市或设施的物联网(IoT)设置中,高写入速率是由耦接有每个设备的适度至高写入速率的大量设备引起。在物流设置中,计划数据和实际数据两者包括可以与每个被跟踪对象相关联的时间序列。监视应用(例如在开发和操作中)可以每系统部件跟踪许多度量。许多形式的金融应用(例如基于股票或期权市场行情数据的金融应用)也依赖于时间序列数据。全部这些应用需要可以扩展到高摄取速率的数据库。
此外,除了简单地跨特定时间段获取或聚合单个度量之外,这些应用经常以复杂和任意的方式查询其数据。这样的查询模式可以涉及丰富的谓词(例如,WHERE子句中的复杂连接)、聚合、统计函数、窗口化操作、针对关系数据的连接(JION)、子查询、公共表表达式(CTE)等。然而,这些查询需要有效执行。
因此,存储时间序列数据需要有规模且有效的复杂查询。传统技术不能在单个系统中实现这两种特性。用户通常在“NoSQL”数据库的水平扩展性与关系数据库管理系统(RDBMS)的查询能力之间进行权衡。时间序列数据的现有解决方案要求用户在可扩展性或丰富查询支持之间进行选择。
支持诸如SQL(结构化查询语言)的数据库查询语言的传统关系数据库系统难以处理高摄取速率:它们对大型表的写入性能较差,并且由于数据量随时间线性增长,该问题随着时间的推移变得更恶劣。此外,任何数据删除都需要昂贵的“清理(vacuuming)”操作以对与这样的表相关联的磁盘存储进行碎片整理。此外,仍然缺乏用于跨许多服务器向外扩展RDBMS的开箱即用(out-of-the-box)开源解决方案。
现有的NoSQL数据库通常是键值或面向列的数据库。然而,这些数据库通常缺少丰富查询语言或二级索引支持,并且在复杂查询上遭受高时延。此外,这些数据库通常缺乏在多个表之间连接数据的能力,并且缺乏更广泛使用的传统RDBMS系统的可靠性、工具(tooling)和生态系统。
分布式块或文件系统避免了预定义数据模型或模式的需要,并且通过添加更多服务器来容易地扩展。然而,它们为其在查询时间使用简单存储模型付出代价,缺少快速和资源有效查询所需的高度结构化索引。
也不能支持现有的、广泛使用的查询语言例如SQL而是创建新的查询语言的常规技术,既需要开发者和分析人员进行新培训又需要新的客户接口或连接器以与其他系统集成。
发明内容
上述和其他问题通过用于动态地创建用于存储正被添加到表示分区数据库表的超表(hypertable)的记录的块的计算机实现的方法、计算机系统和计算机可读存储介质来解决。该方法的实施方式包括通过数据库系统接收插入请求并且处理插入请求。插入请求识别超表和用于插入超表中的一个或更多个输入记录。每个记录具有包括维度属性集的多个属性,维度属性集包含时间属性。基于维度属性将超表分区为多个块。使用每个维度属性的值集指定块。对于块中存储的每个记录,每个维度属性的值映射到来自该维度属性的值集中的值。确定输入记录应被存储在新块还是现有块中。针对正在创建的每个新块,确定对应于每个维度属性的值集并且创建用于存储输入记录的新块。通过将输入记录存储在新块中来更新超表。响应于识别超表的随后查询来处理所更新的超表中存储的数据。
计算机可读存储介质的实施方式存储用于执行用于动态地创建用于存储正被添加到超表的记录的块的上述方法的步骤的指令。计算机系统的实施方式包括一个或更多个计算机处理器并且计算机可读存储介质存储用于执行用于动态地创建用于存储正被添加到超表的记录的块的上述方法的步骤的指令。
鉴于数据库系统的存储重新配置,计算机实现的方法的实施方式动态地修改存储超表的数据库系统的分区策略。数据库系统接收用于在超表中插入一个或更多个记录的第一插入请求。每个记录具有包括维度属性集的多个属性,维度属性包括时间属性。沿着维度属性集将超表分区成块,该块跨第一多个位置分布。第一插入请求中指定的记录被存储在根据第一分区策略创建的块中。第一分区策略指定要创建的第一多个块的尺寸以及从第一多个块中的每一个到来自第一多个位置中的位置的映射。将每个记录插入基于记录的维度属性值确定的块中。
接收向数据库系统添加一个或更多个新位置的指示,使得数据库系统具有第二多个位置。在接收到添加一个或更多个新位置的指示之后创建第二多个块。根据第二分区策略创建第二多个块。第二分区策略指定要创建的第二多个块的尺寸以及从第二多个块中的每一个到来自第二多个位置中的位置的映射。即使在接收到添加一个或更多个新位置的指示之后也继续根据第一分区策略存储第一多个块。在接收到添加一个或更多个新位置的指示之后接收第二插入请求。第二插入请求中指定的记录被存储在基于每个记录的维度属性的值确定的块中。因此,记录可以被存储在根据第一分区策略存储的块中或存储在根据第二分区策略存储的块中。
计算机可读存储介质的实施方式存储用于执行用于动态地修改用于存储超表的数据库系统的分区策略的上述方法的步骤的指令。计算机系统的实施方式包括一个或更多个计算机处理器和计算机可读存储介质,该计算机可读存储介质存储用于执行用于动态地修改存储超表的数据库系统的分区策略的上述方法的步骤的指令。
本发明内容和以下具体实施方式中描述的特征和优点并不是包括一切的。考虑到附图、说明书及其权利要求,许多附加特征和优点对于本领域普通技术人员将是明显的。
附图说明
可以通过结合附图考虑以下详细描述来容易地理解实施方式的教导。
图1是根据实施方式的其中数据库系统操作的系统环境的框图。
图2示出了根据实施方式的对数据库表的数据分区。
图3示出了根据实施方式的包括多个数据库节点的数据库系统中的查询的处理。
图4A示出了根据实施方式的查询处理器的系统架构。
图4B示出了根据实施方式的块管理模块的系统架构。
图5示出了根据实施方式的将记录插入跨多个数据库系统节点存储的超表中的过程。
图6是根据实施方式的执行用于处理在超表中存储的记录的查询的过程的流程图。
图7(A至C)示出了根据本发明的实施方式的用于适于向数据库系统添加位置的数据库表的数据分区。
图8示出了示出根据实施方式的响应于向数据库系统添加新位置而修改数据库系统的数据分区策略的过程的流程图。
图9示出了根据实施方式的基于记录的时间属性选择用于创建块的分区策略。
图10示出了根据实施方式的基于记录的时间属性选择用于创建块的分区策略的过程的流程图。
图11示出了根据实施方式的基于数据库系统接收记录的时间选择用于创建块的分区策略。
图12示出了根据实施方式的可以用于实现数据库系统节点的计算机的架构。
具体实施方式
本发明的实施方式包括数据库系统,该数据库系统支持诸如SQL的标准查询语言并且暴露基于用于跨服务器和/或存储设备对基础数据进行分区的超表的接口。数据库系统使得用户能够就像数据被存储在常规的数据库表中一样与数据交互,从而对用户隐藏了任何数据分区和查询优化的复杂性。数据库系统的实施方式使得诸如SQL的查询语言对于时间序列数据是可扩展的。数据库系统结合了RDBMS和NoSQL数据库的最佳特征:集群向上扩展和向外扩展架构以及对复杂查询的丰富支持。向上扩展对应于在较大的单独服务器上运行,例如,具有大量CPU或核的机器,或具有更大RAM和磁盘容量的服务器。向上扩展还包括通过添加附加的存储设备来增加现有数据库系统的存储容量。向外扩展包括通过添加附加服务器来增加数据库系统的存储容量,例如通过在多个服务器上对数据集进行分片(sharding)以及支持跨多个服务器的并行和/或并发请求。
系统环境
图1A是根据实施方式的其中数据库系统操作的系统环境的框图。系统环境包括数据库系统110、一个或更多个客户端设备120和网络115。
数据库系统110包括查询处理器130、元数据存储装置140和数据存储装置145。如图2所示,例如,数据库系统110可以包括其他部件。数据库系统110接收数据库查询,例如使用SQL指定的查询并且处理数据库查询。数据库系统110可以支持标准SQL特征以及新的用户定义的函数、SQL扩展或甚至非SQL查询语言,例如声明性编程语言、REST接口(例如,通过HTTP)或其他。
数据存储装置145将数据存储为可以被存储为数据行的元组(也称为记录),其中每行包括属性集。这些属性通常具有与它们相关联的名称(例如,“时间”、“设备_id”、“位置”、“温度”、“错误_代码”)和类型(例如,字符串、整数、浮点数、布尔值、数组、json、jsonb(二进制json)、blob、地理空间等),但是这并非在所有情况下都是必要的。本文中也可以使用术语“字段”、“列”或“键”来引用属性。
数据存储装置145可以将记录存储在标准数据库表中,该标准数据库表使用关系数据库系统使用的常规技术将数据存储在一个或更多个文件中。数据存储装置145还可以将数据存储在被称为超表的分区数据库表中。超表是提供由虚拟视图表示的单个连续表的接口使得请求方可以通过数据库查询语言例如SQL查询它的分区数据库表。可以使用具有属性(或字段或列)名称和类型的标准模式来限定超表,其中,至少时间属性指定时间值。超表被沿着维度属性集进行分区,该维度属性集包括时间属性和零个或更多个其他维度属性(有时被称为超表的“空间”属性)。对超表进行分区的这些维度属性也称为“分区(partitioning)键”、“分区(partition)键”或“分区字段”。可以使用用于创建数据库表的标准SQL命令创建超表。此外,可以使用数据库查询例如SQL查询来进行对超表的查询。
数据库系统将超表分割成块(chunk)。每个块存储超表的记录的子集。在本文中块也可以称为数据块或分区。数据库系统110可以跨一个或更多个位置的集合分布超表的块。位置可以表示用于存储数据的存储介质或者包括用于存储数据的存储介质的系统,例如服务器。存储介质可以是存储设备,例如磁盘。数据库系统110可以将数据存储在附接至同一服务器的多个存储设备上或存储在多个服务器上,每个服务器附接有用于存储块的一个或更多个存储设备。存储设备可以附接至例如基于云的系统中的远程服务器,以及被提供对用于存储块的远程存储设备的访问的数据库系统的服务器。
数据库系统可以存储多个超表,每个超表具有不同的模式。同一超表内的块通常具有相同的模式,但是也可以具有不同的模式。数据库系统还可以包括标准数据库表,即在同一数据库中存储的传统非分区表。单个查询中对包括多个表的这些表中的任意表执行操作。例如,这可以涉及在超表与标准非分区表之间、或在两个超表之间或其任何更复杂的组合来连接(JOIN)数据的选择(SELECT)。或者,其可以涉及作为单个事务将数据插入超表和标准非分区表中、或者插在两个超表之间或更复杂的组合。
在一些实施方式中,数据库系统110包括通过网络连接的一个或更多个数据库系统节点(也称为数据库服务器或仅服务器)。每个节点可以包括与图1相同或相似的部件,例如查询处理器130、元数据存储装置140和数据存储装置145。在图2中描述了数据库系统节点的细节。元数据存储装置140存储描述数据存储装置145中存储的数据的元数据,包括各种超表和标准非分区表的描述。该描述包括每个表的各种属性、超表的各种块的描述等。如本文进一步描述,查询处理器130接收查询并且对其进行处理。
数据库系统110可以连接至向数据库系统110发出数据库查询的请求者。请求方可以是数据库查询的任何源,例如客户端设备120、网络服务器、应用服务器、用户工作站或代表在另一起源(例如,充当队列、缓冲区或路由器例如用于插入(INSERT)的中间服务器或者中间件层,或代表另一系统或用户的应用)上发送查询的服务器或机器。
来自请求者的该连接通常通过网络115发生,但是它也可以在执行数据库系统的同一服务器上。例如,网络115使得能够实现客户端设备120或任何其他请求方与数据库系统110之间的通信。在一个实施方式中,网络使用标准通信技术和/或协议。通过网络交换的数据可以使用包括以下的技术和/或格式表示:开放数据库连接(ODBC)格式、Java数据库连接(JDBC)格式、PostgreSQL外部数据封装器(FDW)格式、PostgreSQL dblink格式、外部数据表示(XDR)格式、Google协议缓冲区(protobuf)格式、Apache Avro格式、超文本标记语言(HTML)、可扩展标记语言(XML)、Javascript对象表示法(JSON)等。
客户端设备120可以是个人计算机(PC)、台式计算机、膝上型计算机、笔记本、执行操作系统的平板PC。在另一实施方式中,客户端设备120可以是具有计算机功能的任何设备,例如个人数字助理(PDA)、移动电话、智能手机、可穿戴设备等。客户端设备也可以是包括在后台环境中、企业数据中心内或虚拟化云数据中心内运行的服务器或工作站。客户端设备执行用于与数据库系统110交互的客户端应用,例如,浏览器125、数据库壳、web服务应用(例如,.NET、Djagno、Ruby-on-Rails、Hibernate)、消息代理(例如Apache Kafka或RabbitMQ)、可视化应用等。
图1和其他附图使用相同的附图标记来标识相同的元件。附图标记后面的字母例如“120A”指示该文本特指具有该特定附图标记的元件。文本中没有后续字母的附图标记例如“120”是指附图中带有该附图标记的任何或全部元件(例如文本中的“120”指的是附图中的附图标记“120A”和/或“120N”)。
图2示出了根据实施方式的将数据分区为超表的块。这些块中的每一个对应于根据涉及记录的属性中的一个或更多个的一些分区功能组织的整个数据集的一部分。用于将超表分区为块的记录的属性被称为维度属性。因此,块对应于超表的“n维”分割(对于n≥1)。
数据库系统110可以将块实现为文件。在一个实施方式中,使用标准数据库表来实现每个块,该标准数据库表被自动布置在数据库节点之一的位置(例如,存储设备)之一上(或在多个位置或节点之间复制),然而该细节可以对用户不可观察。在其他实施方式中,通过数据库管理员或用户给出的命令或策略来指定块在位置和/或数据库节点上的布置。
维度属性之一是存储时间相关值的时间属性。时间属性可以是可以可比较(即,具有>和≥运算符)的任何数据,使得可以根据该比较函数对数据进行排序。此外,新记录通常与较高时间属性相关联,使得该值通常对于新记录渐增。注意,该值可以在数据记录中被指定,并且不需要(并且通常不)对应于何时将数据插入数据库中。以下值可以用作时间属性:日期时间戳(包括带有时区信息或不带时区信息)、UNIX时间戳(以秒、微秒、纳秒等为单位)、序列号等。在实施方式中,超表也沿着表示数据库表中描述的对象或实体的不同标识符(例如,标识设备的设备id、标识服务器的服务器id、金融证券的股票代码等)的维度属性被分割。
块与对应于每个维度属性的值集相关联。例如,超表可以具有两个维度属性d1和d2。对于给定的块C1,维度属性d1与值集SI相关联,并且维度属性d2与值集S2相关联。因此,在块C1中存储的每个记录具有映射到对应于维度属性的值集中的值的维度属性值。例如,假设超表包括属性时间、设备和温度。还假设时间是维度属性并且块与时间范围[0:00:00至11:59:59.999]相关联。如果输入记录具有值{时间:“1:00:00”,设备:“A”,温度:65},则块可以存储输入记录,因为时间维度的值“1:00:00”落在与块相关的范围即[0:00:00至11:59:59.999]内。
对应于维度属性的值集可以表示值的范围,但不限于范围。例如,该值集可以表示不连续的多个范围。替选地,可以通过枚举一个或更多个值来指定值集。例如,维度属性cl可以表示颜色(例如,“红色”、“蓝色”、“绿色”、“黄色”),并且块可以存储具有来自集合{“红色”、“蓝色”}的维度属性cl的值的记录并且另一块可以存储具有来自集合{“绿色”、“黄色”}的维度属性cl的值的记录。
如果给定值与该值集中的值相同,则维度属性的给定值可以映射到对应于该维度的值集中的值。替选地,如果通过对给定值v1应用变换(例如,函数)来获得值v2,则维度属性的给定值v1可以映射到对应于该维度的值集中的值v2。例如,数据库系统110可以使用散列分区策略,其中对应于维度的值集被指定为通过将散列函数应用于维度属性值而获得的值的范围/集合。因此,如果维度属性值被表示为vx,并且H表示散列函数,则块Cx可以与H(vx)的值的范围R=[x1,x2](或集合)相关联。因此,如果H(v1)位于范围[x1,x2]中,则块可以存储具有维度属性值v1的记录。
在实施方式中,值集可以对应于多个维度属性。例如,在以上示例中指定的散列函数可以接收两个或更多个输入,每个输入对应于不同的维度属性,即H(v1、v2、……)。因此,可以将块的维度定义为包括超表的多个维度属性的复合属性。
图2示出了沿着两个维度属性——时间属性和被称为空间属性的另一维度属性——分割成多个块210的超表160。在该示例中,每个块与包括开始时间和结束时间的时间范围相关联,并且空间范围包括连续范围的字母字符。例如,块210a存储具有在范围[0,6]内的时间属性的值和在范围[A,I]内的空间属性的值的记录集。类似地,块210b存储具有在范围[0,6]内的时间属性的值和在范围[J,R]内的空间属性的值的记录集等。
可以对超表进行不同类型的查询,包括仅从超表读取的那些查询(例如,数据库选择(SELECT)语句(statement)),以及修改超表的那些查询(例如,数据库插入(INSERT)、更新(UPDATE)、更新插入(UPSERT)和删除(DELETE)语句)。通常将写入发送到由最新时间间隔(但不需要是最新时间间隔)组成的块,而查询可以跨多个维度属性例如时间和空间两者进行切割。
虽然在本文中将超表和块称为表,但是该术语并不意味着进行限制,并且块可以指代若干存储表示,包括传统的关系数据库表、虚拟数据库视图、物化数据库视图、结构化标记语言(例如,XML)集、序列化结构化数据集(例如,JSON、Google协议缓冲区,ApacheAvro、Apache Parquet)或平面文件(例如,具有逗号或制表符分隔值)。
分布式执行查询
图3示出了根据实施方式的包括多个数据库节点的数据库系统中的查询的处理。数据库系统节点310a接收数据库查询并且可以向被存储在协调器数据库系统节点上或其他数据库系统节点上的块(可以实现为数据的物理表)发送一个或更多个查询。如果数据库系统节点确定不需要块以满足查询,则数据库系统节点不向该块发出查询。该确定使用关于块的附加元数据,所述附加元数据可以被保持与每个块的数据分开或与每个块的数据一起。每个数据库系统节点还可以保持附加的元数据以使其能够有效地确定块的时间间隔和分区字段的键空间。数据库系统可以将元数据保持与块分开或与块一起。
如图3所示,数据库系统节点310a接收第一数据库查询320。数据库系统节点310a确定处理接收的数据库查询所需的数据在一个或更多个数据库系统节点310a、310b和310c上。数据库系统节点310a还将用于处理第一查询的查询325a和325b分别发送到数据库系统节点310b和310c。全部三个数据库系统节点310a、310b和310c使用在其相应节点上存储的一个或更多个数据块来处理它们相应的查询。在图3所示的示例中,如果数据库系统节点310a确定处理第一查询所需的数据仅被存储在数据库系统节点310a和310b上而不被存储在310c上,则数据库系统节点310a将用于处理的查询发送至310b而不发送至310c。在系统的其他实施方式中,发送至其他节点310b和310c的查询325a和325b与第一查询320相同,并且发送至其他节点的查询或请求可以采用与第一查询不同的查询语言、格式或通信协议。在系统的一些实施方式中,查询325a和325b可以彼此相同,而在其他实施方式中它们是不同的。此外,在其他实施方式中,节点310a本身不存储块,而是仅处理查询320并且向其他数据库节点发出对应的查询325。
接收数据库查询的数据库系统节点310a可以确定对超表的查询不涉及特定块的数据——例如,因为查询指定不同于与块相关联的时间段的时间段,或者如果查询指定与不同块相关联的维度属性(例如,IP地址、设备ID或某个位置名称)。在这种情况下,第一数据库系统节点不向该特定块(其可以位于第一数据库节点自身或不同节点上)发出查询。通过第一数据库系统节点和任何其他数据库系统节点两者的该确定可以由每个数据库系统节点上存在的处理查询的查询处理器130执行。
任何数据库系统节点可以从请求者接收查询并且在该数据库系统节点上运行的查询处理器130确定如何跨一个或更多个节点的整个集群上计划和执行查询。该数据库系统节点向系统中的零个或更多个其他节点发送查询(“子查询”)。随后,从第一数据库系统节点接收子查询的数据库系统节点包括确定如何在本地计划和执行查询的查询处理器130。
在实施方式中,该过程被扩展至附加级别的子查询和涉及的计划器。在实施方式中,数据库系统以递归方式执行该分区。例如,在节点之一上存储的块本身可以在时间上和/或通过附加分区键(与较高级别的分区键相同或不同)被进一步分区,该块本身可以被分布在节点中间(例如,在不同的磁盘上)或甚至被分布到其他节点。在这样的情况下,块可以充当另外的超表。
在一些实施方式中,数据库系统仅使用第一数据库系统节点上的查询处理器130来执行查询处理。因此,整个查询计划由第一节点生成并且被发送至被确定成存储由查询处理的块的节点。接收查询计划(或其一部分)的其余节点仅执行所接收的查询计划而不必生成查询计划的一部分。在其他实施方式中,数据库系统跨节点实现较不均匀的功能,使得一个或更多个节点的第一集合接收查询并且针对存储块的一个或更多个节点的第二全异集合计划和执行查询。
系统架构
图4A示出了根据实施方式的查询处理器的系统架构。查询处理器130包括下述部件,所述部件包括连接器410、查询解析器415、查询计划器425、查询优化器430、执行引擎435和查询计划存储装置455。查询处理器130接收按照某种查询语言例如SQL的查询,该查询指定将对其应用查询(即,读取或写入数据)的表或数据集。查询或数据库查询可以表示从数据库读取数据(例如,SQL中的选择语句)或修改数据(例如,SQL中的插入、更新和删除语句)的请求。
查询解析器接收该请求并且将其转换为更易于处理的查询表示。例如,查询解析器415可以生成表示查询的提供对查询中指定的信息的访问的数据结构。查询优化器430执行查询的转换,例如通过重写查询的部分以改进查询的执行。查询计划器采用通常本质上是声明性的查询的该机器可读表示,并且生成指定应当如何针对存储的数据执行查询的计划,该存储的数据可以被存储在存储器(例如,RAM、PCM)和/或在某种类型的非易失性存储介质(例如,闪存SSD、HDD)上。查询处理器130将所生成的计划存储在查询计划存储装置455中。执行引擎435针对存储的数据执行查询,并且将结果返回给请求者。连接器410使得查询处理器130能够连接至远程系统,例如以访问在远程系统中存储的数据。
图4B示出了根据实施方式的块管理模块的系统架构。块管理模块170还包括块选择模块445和块创建模块450。块选择模块445实现确定用于存储给定记录的块的块选择功能。块选择模块445确定现有块是否可以用于存储记录。如果块选择模块445确定现有块中没有一个可以用于存储记录,则块选择模块445确定需要创建新块并且调用用于创建块的块创建模块450。如果块选择模块445确定需要创建新块,则块选择模块445确定描述新块的各种参数。例如,块创建模块450确定对应于记录的限定块边界的不同维度属性的值集。因此,在块中存储的记录具有维度属性值,使得每个维度属性具有映射到对应于块的维度的值集中的值的值。例如,如果块具有基于时间和设备id的两个维度属性,则在块中存储的每个记录具有落在块的时间范围内的时间属性以及来自与该块相关联的设备id的集合中的设备id。块创建模块450确定用于创建块的位置并且在该位置上创建块。
数据库系统110在元数据存储装置140中存储描述块的元数据155。块的元数据包括将块与超表相关联的信息。描述块的其他类型的元数据包括块的名称、维度属性的各种值集(例如,时间属性的时间范围等)、描述块的约束和索引的信息等。数据库系统110可以存储与块相关联的其他元数据,例如访问统计和数据分布统计以帮助查询计划。
超表可以与某些策略配置例如索引、约束、存储参数(例如,填充因子设置、并行工作器(worker)设置、自动清理设置等)、外键关系等相关联。在实施方式中,超表中的每个块实现包含块的超表的策略配置。因此,当创建块时,块创建模块450还可以创建诸如块的索引的结构并且更新元数据以指定约束、外键关系以及块的任何其他策略配置。为块定义的约束的示例包括唯一(UNIQUE)、非空(NOT NULL)、检查约束(CHECK CONSTRAINT)(即,范围之间的时间戳)、外键(FOREIGN KEY)和排除(EXCLUSION)约束。一旦创建块,则块管理模块170继续管理块,例如通过周期性地对旧块重新建立索引、随时间推移将旧块移动至较慢的存储设备、通过动态检查添加次要约束等。
在实施方式中,块管理模块170监视最近创建的块的尺寸。最近创建的块(或最近的块)指的是在当前时间的阈值时间间隔内创建的块。阈值时间间隔的尺寸可以是可配置的。尺寸表示被存储在块中的数据量,例如块的字节大小、块的行数等。块管理模块170基于最近创建的块的尺寸来调整正在创建的新块的维度属性的值集。因此,如果块管理模块170确定一个或更多个最近创建的块存储超过特定高阈值的数据,则块管理模块170调整一个或更多个维度的值集,使得它们具有比最近创建的块的对应值集更少的元素。例如,如果块管理模块170确定最近创建的块具有针对时间属性的12小时的范围,则块管理模块170可以将正被创建的新块的时间属性的范围减小为10小时。替选地,如果块管理模块170确定一个或更多个最近创建的块存储在特定低阈值以下的数据,则块管理模块170调整一个或更多个维度的值集,使得它们具有比在低尺寸阈值以下的最近创建的块的对应值集更多的元素。例如,如果块管理模块170确定最近创建的块具有针对时间属性的12小时的范围并且存储非常少的记录,则块管理模块170可以将正被创建的新块的时间属性的范围增加为15小时。
在实施方式中,块管理模块170监视最近创建的块的一个或更多个性能度量。块管理模块170基于最近创建的块的性能度量来调整正在创建的新块的维度属性的值集。例如,块管理模块170可以监视插入率和查询执行时间。例如,如果块管理模块170确定对于块的当前尺寸记录的插入率已显著下降(例如,因为数据库系统已经开始交换到磁盘),则块管理模块170确定正在创建的新块的维度属性的值集使得新块更小。
在实施方式中,块管理模块170保持描述由每个不同查询处理的块的统计,例如由每个查询处理的块的数目。块管理模块170使用该统计信息来确定正在创建的新块的维度属性的值集以便提高性能。在实施方式中,块管理模块170监视在查询中指定的维度属性边界。如果块管理模块170确定通常接收的查询具有某种边界模式,例如时间对齐的模式(例如,典型查询请求午夜与午夜之间的一天的数据),则块管理模块170对齐新创建的块以匹配这些边界。作为另一示例,如果当前块具有一小时时间属性范围并且块管理模块170确定查询通常以全天的大小的间隔访问数据,则块管理模块170增加块尺寸以达到与访问模式更加对齐的但是仍然保持高插入率的尺寸。例如,例如,如果与24小时范围相比12小时给出更高的插入率,块管理模块170可以将时间属性范围增加为12小时。
在实施方式中,块管理模块170基于在由数据库系统接收的查询中指定的维度属性的范围确定正在创建的块的维度属性的值集。例如,如果块管理模块170正在创建具有从下午11点至下午11点的时间属性范围的块,并且块管理模块170确定所接收的查询正在访问在从午夜至午夜的数据,则块管理模块170移动正在创建的块的时间范围以匹配查询的时间范围。这样通过避免不必要地扫描两个块而不是一个块的需要来提高查询的性能。
在实施方式中,块管理模块170基于每个位置的存储介质的性质来跨多个位置分布块。块管理模块170识别用于存储新块的存储介质并且访问存储介质的属性,例如描述在存储介质上存储的数据的访问速率的性质。块管理模块170基于与位置对应的存储介质的性质来确定从多个块中正分配给该位置的块的数目。例如,块管理模块170访问描述存储介质访问随机数据的速率的度量。某些存储介质(例如,固态驱动器(SSD)和随机存取存储器(RAM))可以比旋转硬盘驱动器(HDD)更好地处理随机读取。因此,块管理模块170将来自多个块中的较多块分配给具有拥有随机存取的较快访问时间的存储介质的位置。
在实施方式中,块创建模块450创建新块,以及“关闭”(“close”)现有块——当现有块接近或超过某个阈值尺寸(例如,在磁盘上或内存中以字节为单位、以其行数为单位等)时。每个块由开始时间和结束时间表示(限定其间隔)。然而,使用纯粹基于尺寸的方法,数据库系统不会先验地知道新创建的块的结束时间。因此,当首次创建块时,块的结束时间未设置;具有大于(或等于)开始时间的时间的任何行被与块相关联。然而,当块的尺寸接近或超过某个阈值时,查询计划器425通过指定块的结束时间来关闭块,并且块创建模块450创建新块。该新块从旧块结束的时间处开始。使用该方法,块具有块的不确定的结束时间,直到块被关闭。类似的逻辑应用于不确定的开始时间。初始块也可以具有不确定的开始和结束时间两者。数据库系统的实施方式异步地或在后台执行该确定和块创建,而另一实施方式在将来自所接收的批(batch)的行(的集合)插入块中的过程期间执行这些动作。在插入时间处创建新块可以以多种方式发生:在插入行之前(查询计划器425判定现有块已经太满,并且创建用以插入的新块);将行插入块中之后;或者在插入行的中间(例如,查询计划器425判定块仅具有用于行的子集的空间,因此该子集被插入当前块中并且该集合的其余部分被插入新创建的块中)。
在其他实施方式中,数据库系统在创建块时将块限定为具有特定时间间隔(即,开始时间和结束时间两者)。然后系统在需要时创建新块,例如当要将新数据插入尚不存在的时间间隔时。在一个实施方式中,数据库系统也甚至为该方法采用最大尺寸,使得,例如如果在第一块上接近或超过尺寸则使用与第一块相同的时间间隔创建第二块,并且查询计划器425将新数据仅写入块中之一。一旦创建了第二块,数据库系统就可以将数据从第一块重新平衡至第二块。在另一实施方式中,不是使第一块和第二块的时间间隔交叠,而是在创建第二块时修改第一块的结束时间使得它们保持不相交并且可以严格地对它们的时间间隔进行排序。在另一实施方式中,数据库系统异步地执行这样的改变使得作为系统的“后台”任务将过大的块分割成第一块和第二块。此外,在另一实施方式中,当插入发生在足够接近块的时间范围的结束的时间值时,而不是仅当记录的维度属性(例如,时间)落在任何现有块的维度之外时,创建该第二块。通常,数据库系统的块管理的许多变体可以在插入时间处同步执行或者作为后台任务异步执行。下面进一步描述基于尺寸和基于间隔的组块(chunking)。
在实施方式中,块创建模块450执行冲突检测以确保新块具有与现有块不相交的维度属性集。例如,假设块创建模块正在创建具有跨越24小时的时间范围的块。如果先前块存储具有直到1月1日的午夜(不包括)的时间属性值的数据,则块创建模块450接下来创建具有从1月2日的午夜(包括)到下一午夜(不包括)的时间属性值的块。作为另一示例,如果块创建模块450正在创建时间属性为18小时间隔的块,如果先前创建的块覆盖从午夜至凌晨3点的时间间隔,则块创建模块450接下来创建跨越时间属性的从凌晨3点到晚上9点的时间间隔的新的18小时块。块创建模块450可以创建具有相同时间范围但具有其他维度属性的不同值集的多个块。
块创建模块450可以基于各种标准来调整块边界,其中一些标准可能是冲突的。例如,考虑数据库系统具有在凌晨3点结束的时间间隔的一个块以及从中午到下一午夜的另一块。数据库系统接下来可以接收插入时间属性值为凌晨4点的记录的请求。即使块创建模块450可以正在创建具有跨越12小时的时间范围的块,在该情况下,块创建模块450可以创建跨越从凌晨3点到中午的仅9小时时间间隔的新块以便强制不相交。在一些实施方式中,块管理模块170在块被创建之后确定块的范围(或块的值集)可能与创建的其他块交叠。在这些实施方式中,块管理模块170修改块的现有范围以确保范围与其他块不相交。
在一些实施方式中,跨不同分区,数据库系统可以对齐块开始时间和结束时间或者独立地保持它们。换句话说,系统可以同时创建和/或关闭超表的所有块,或者不同分区可以被彼此不同地管理。在其他实施方式中,可能存在特殊的溢出块,其中暂时或永久地布置不能放置在一些现有块中的数据。
这些图(例如,图1至图4)中所示的系统架构意在是说明性的;其他实施方式可以包括附加或更少的部件,这些部件中的一些可能并不总是存在(例如,查询解析器或缓存),或者这些部件可以以各种方式组合或划分(例如,查询计划器、查询优化器和执行引擎)。应理解,这样的表示或划分不会改变数据库系统的整体结构和功能。例如,可以理解,本文中描述的方法可以在包括执行查询计划和执行两者的一个部件的系统中实现,或者在包括用于计划的单独部件——其然后将计划传递至用于执行的执行器引擎——的系统中实现。
将数据插入超表
图5示出了根据实施方式的将记录插入跨多个数据库系统节点存储的超表中的过程。数据库系统110接收510插入查询(其也被称为插入请求)。插入查询识别数据库表,例如超表、块或标准非分区数据库表并且指定要插入数据库表中的一个或更多个记录。数据库系统110可以将记录存储为包括多个块的超表,每个块被存储在不同的位置。
在接收510到插入查询后,查询解析器415解析插入查询。查询计划器425处理该查询,并且确定该查询是否指定超表、块或标准非分区数据库表。如果插入查询指定标准数据库表或块,则查询计划器425结合执行引擎435在指定块或标准数据库表上执行插入并且返回结果。
如果查询指定了超表,则查询处理器130对插入请求中指定的每个记录执行以下步骤。查询处理器130识别输入记录中的维度属性的值。查询处理器130确定输入记录是应被存储在现有块中还是被存储在需要创建的新块中。在实施方式中,查询处理器130确定输入记录的一个或更多个维度值是否映射到来自存储超表的数据的现有块的维度属性值集合中的值;进行该确定以判定是否可以将记录存储在现有块中。
在实施方式中,查询处理器130提供520维度属性作为块选择模块445的选择函数的输入,该选择函数确定记录是否应被存储在现有块中或者是否需要创建用于存储记录的新块。如果选择函数找到与记录匹配的现有块,则选择函数输出识别现有块的信息。如果选择函数确定现有块中没有一个可以用于存储记录,则选择函数输出指示需要创建新块的值(例如,负数)。块创建模块450基于选择函数的输出确定540记录是否与现有块匹配。如果块创建模块450确定540记录与现有块匹配,则块选择模块445还识别现有块的位置,例如现有块是本地的(即,在当前数据库系统节点上)还是远程的(即,在另外的数据库系统节点上)。该位置可以显式或隐式指定位置,包括指定本地数据库表的名称、远程数据库表的名称、名称或网络地址或远程服务器等。因此,查询处理器130将记录插入550现有块中。
如果块创建模块450基于选择函数的输出确定540需要创建新块以用于存储记录,则块创建模块450确定560包括对应于新块的不同维度属性的值集的新块的配置。块创建模块450还可以识别用于创建新块的位置(包括识别特定存储设备或者替代地识别特定数据库系统节点,其中所识别的节点进而识别附接至其的特定存储设备)。块创建模块450基于新块的配置和所识别的位置来创建新块。查询处理器130将记录插入580被创建的新块中。
块选择模块445可以基于各种标准确定不能将记录插入现有块中。如果记录的维度属性与任何现有块的配置不匹配,则不能将记录插入任何现有块中。在一些实施方式中,即使记录的维度属性与现有块的配置相匹配,块选择模块445也可能基于某些策略考虑确定不能将记录插入块中。例如,块选择模块445可能确定现有块正在存储多于阈值量的数据,并且不应当向块添加新记录。因此,块选择模块445确定不能将记录添加到现有块并且数据库系统不能将记录插入任何现有块中。
为了在本地创建块或将记录插入本地存储的块中,即在执行上述步骤的当前数据库系统节点上,数据库系统可以执行函数调用。为了远程创建块或将记录插入远程存储的块中,即在与当前数据库系统节点不同的数据库系统节点上,数据库系统可以执行远程调用,例如远程过程调用(RPC)或远程SQL查询执行。针对创建块或将记录插入块中而执行的指令还可以取决于块的位置,例如用于存储块的存储介质的类型。
尽管图5依据选择函数描述了步骤,但是其他实施方式可以使用不同的函数来计算不同的值,例如用于确定记录是否应被存储在现有块中的第一函数和用于在第一函数确定记录不能被存储在任何现有块中的情况下描述新块的第二函数。
如果多个块驻留在同一位置上,则不是针对每个插入查询使用单独的消息,而是查询处理器130可以在单个消息中发送多个查询,或者其还可以在单个消息中发送要在单个查询中插入的多个记录。如果插入查询中涉及的块驻留在多个节点上,则在一些实施方式中数据库系统节点联系查询或事务协调器以获得附加信息,该附加信息在随后作为插入过程的一部分与其他数据库节点通信时被使用和/或发送。
在一些实施方式中,查询处理器130以各种方式处理错误或缺乏及时响应。如果在多个节点之间复制块,或者记录至块(record-to-chunk)确定过程导致多于一个块,则查询处理器130向这些块中的一个或更多个发出插入请求,进一步讨论。最后,查询计划器425从插入查询中收集任何结果或状态信息,并且将一些结果或状态信息返回给请求者。
在一些实施方式中,数据库系统110执行若干步骤以确定记录所属的块,其中许多步骤涉及使用元数据。首先,查询计划器425确定在记录指定的时间(即,记录的时间属性的值)处属于超表的一个或更多个分区的集合。如果该分区是静态的,则查询计划器425使用关于超表本身的元数据来确定该分区。
如果该分区随时间改变,则查询计划器425使用记录的时间属性来确定分区的集合。在一个实施方式中,该确定涉及首先使用行的时间属性值来确定特定时期(epoch)(时间间隔),然后使用该时期来确定分区的集合。如下所述,该分区可以在系统重新配置(或弹性)的背景下改变。其次,查询计划器425使用记录的维度属性的值来确定记录所属的分区(从一个或更多个分区的该集合中)。针对用于超表中的分区的维度属性中的每一个,该步骤可以涉及将一些函数应用于其值以生成第二值。为此目的可以采用各种函数,包括散列函数(例如,Murmur散列、Pearson散列、SHA、MD5、位置敏感散列)、恒等函数(即,简单地返回输入)、一些基于范围的数据结构中的查找或对输入的一些其他加前缀或计算。第三,使用该第二值(函数的输出),查询计划器425确定第二值属于哪个分区。例如,该步骤可能涉及范围查找(例如,找到分区[x,y]使得第二值在x与y之间,包括和/或排除端点),分区上的最长前缀匹配(当分区由一些二进制字符串表示时,确定具有最大数目的与第二值的最高有效位相同的最高有效位的分区),取第二值对节点数目的“求余”(“mod”)来确定匹配分区数目,或者使用一致性散列以及其他匹配算法。如果使用多于一个键对超表进行分区,则可以将函数应用于多于一个输入(或者可以将函数分别应用于多个输入),从而导致将被用于确定记录所属的分区的一个或更多个第二值(输出)。最后,将针对每个维度的每个分区与块的集合相关联(即,存储该分区的那些块的时间范围可能不同);查询计划器425然后基于记录的时间属性确定来自该集合中的块。
其他实施方式以替选方式实现确定记录所属的块的步骤。例如,数据库系统跳过首先基于记录的时期确定记录的块的过程,并且替代地首先确定与记录的时间相关联的块的集合。查询计划器425计算关于记录的分区键的函数以确定第二值,并且将该第二值与和每个块相关联的分区信息进行比较以便选择一个。这些过程可以经由各种数据结构实现,包括散列表、链表、范围树(range tree)、数组、树、特里结构(trie)等。
存在多种其他优化方式来实现下述过程,查询计划器425通过所述过程将批的数据插入块中而不改变其基本功能。例如,不是对每个记录执行全部这些步骤,查询计划器425可以缓存其在其每个记录分析期间确定的信息,例如在给定时间或时间段内的超表的块。
其他实施方式以不同方式执行用于处理批的步骤。例如,在确定第一记录的块之后,查询计划器425扫描批的其余部分,找到与同一块相关联的所有其他记录(如果存在的话)。查询计划器425然后将这些记录插入所选的块中,并且从批中删除它们。查询计划器425然后重复该过程:选择(现在较小的)批中的记录,扫描批的其余部分以找到具有相似块关联的记录,将一个或更多个记录的该集合发送到第二块,并且然后重复该过程直到批为空。
上面的插入过程将记录描述为与单个块相关联。替选地,记录可以映射到多个块。例如,如本文所述,组块过程可以在特定间隔期间创建多于一个块(例如,如果插入的数据的尺寸超过某个阈值),在这种情况下,选择函数例如随机地、循环地或基于它们的尺寸选择一个块。作为另一示例,数据库选择将记录插入多个块以为了可靠性或高可用性来复制数据。这样的复制可以作为上述相同步骤的一部分由查询计划器425执行,或者查询计划器425首先将记录中的每一个插入主块中,并且然后数据库系统110将插入的记录复制到块的副本(replica)。
在实施方式中,数据库系统110复制块使得同一超表的不同块可以通过不同数目的副本来存储。此外,数据库系统可以基于块的年龄来确定块的副本的数目。例如,与较老的块相比,最近的块可以复制更多次数。此外,可以不复制具有大于阈值年龄的较老的块。数据库系统110可以基于块的时间属性的值来确定块的年龄。例如,如果时间范围[t1,t2]比时间范围[t3,t4]更老,例如,t2<t3,则可以确定存储具有在范围[t1,t2]内的时间属性的记录的块比存储具有在范围[t3,t4]内的时间属性的记录的块更老。替选地,可以基于块的创建时间来确定块的年龄。例如,一周前创建的块具有大于今天创建的块的年龄值。
在实施方式中,数据库系统将不同的块复制到具有不同特性的位置。数据库系统基于块的配置选择具有特定特性的位置。例如,数据库系统将被定期访问(已进行插入或选择)的最近的块存储和/或复制在快速存储介质(例如,SSD)上,而数据库系统在较慢的存储介质(例如,HDD)上存储和/或复制老块。
在实施方式中,数据库系统重用应用于数据库的基础表的复制技术,即整个数据库和冷/热备份的物理复制,单独表的逻辑复制以及备份。数据库系统还将数据库的预写日志(WAL)用于一致检查指示(checkpointing)。换句话说,即使在超表上定义了复制或备份策略(或发出命令),系统也可以通过对超表的组成块进行复制或检查指示来执行这些动作。在另一实施方式中,直接由数据库系统通过将写入复制至多个块副本(例如,通过两阶段提交协议)而不是通过使用数据库的基础的基于日志的技术来实现复制和高可用性。
在实施方式中,数据库系统使得能够基于块边界定义不同的策略,例如针对最近的块较高复制级别,或者较老的块上较低复制级别,以便节省磁盘空间。
在实施方式中,数据库系统还在块变老时在位置之间移动块(例如,从存储在较快SSD上至存储在较慢HDD,或者从较快或较大的服务器至较慢或较小的服务器)。数据库系统将每个超表与阈值年龄值相关联。数据库系统还将位置与类型相关联。例如,不同类型的位置可以具有不同的访问时间、不同的存储容量、不同的成本等。如果数据库系统识别具有大于超表的阈值年龄值的年龄值的超表的块,则数据库系统将所识别的块从具有特定类型的位置移动到具有不同类型的另一位置。因此,数据库系统可以将同一超表的不同块存储在不同类型的位置。此外,由于接收到较新的块并且现有块变得较老,数据库系统随着时间的推移自动地改变超表的块至位置的映射。在另一实施方式中,该移动仅在命令(例如,来自外部过程或数据库用户)请求时发生,该命令指定与超表相关联的年龄和在其间移动任何所选块的位置。
处理读取数据的查询
图6是根据实施方式的执行用于处理在超表中存储的记录的查询的过程的流程图。数据库系统接收610用于读取数据的查询(例如,通过SQL中的选择(SELECT)语句)。在接收到查询后,查询解析器415解析查询(可选地使用解析的查询的缓存)。查询计划器425处理查询并且确定查询中指定的任何表是否对应于超表、块或标准非分区数据库表。数据库系统在这些不同的场景中执行下面的步骤,每个步骤导致一些结果被返回给请求者(或者如果出现任何问题,则返回某种形式的错误)。
对于在第一查询中指定的每个超表,查询计划器结合执行引擎435执行以下步骤。首先,查询计划器425分析查询以确定620可以为查询的答案贡献结果的块的集合。该分析通常涉及数据库系统110保持的关于块的元数据以及查询的谓词(predicate)指定的约束。例如,这些约束可以基于特定字段的值(例如,所选行必须具有等于100或450的设备标识符),或者这些约束可以包括某种类型的时间范围(例如,所选行必须指定其时间值是在过去的一小时内,或2016年7月与2016年8月之间)。除了别的以外,存储的关于每个块的元数据可以指定时间范围和与特定块相关联的任何其他分区键。例如,块可能正在存储用于0与200之间的设备标识符的最后一天数据。这些示例仅是说明性的并且本文描述了系统可以采用的各种技术。查询计划器425使用元数据来确定合适的块,例如设备标识符100将与存储0与200之间的设备标识符的块相关联。
针对确定的每个块重复以下步骤630、640、650和660。查询计划器425使用元数据来确定存储这些块的位置——例如,诸如本地或网络附接磁盘的存储设备,或其他数据库系统节点。这些块可以被存储在查询计划器435的本地或远程的位置上。查询计划器425确定640块是否被存储在本地或被存储在远程服务器上。如果查询计划器425确定块被存储在本地位置,则查询计划器425查询本地块(例如,经由直接函数调用),否则查询计划器425向存储块的远程位置发送660查询(例如,通过例如经由外部数据封装器发出SQL查询,通过发送远程过程调用(RPC)等)。此外,查询计划器425可以根据存储它们的位置的性质(例如,磁盘或节点的类型)来改变查询执行或计划。当多个块共享同一位置时,查询计划器425可以生成针对位置的块的集合的单个查询或者生成每个块单独的查询,并且这些单独的查询可以在单个消息中被发送到该位置或者作为每个查询的单独的消息被发送。
查询计划器425向这些位置发出查询并等待其结果。如果某些位置在一段时间后没有响应或返回错误,则查询计划器425可以采取若干不同的选项,包括重试对相同位置的查询、重试对复制块的不同位置的查询、无限期等待、将部分结果返回给客户端或返回错误。查询计划器425接收670或收集这些查询的结果并且合并该结果。取决于查询、结果、元数据和附加信息,查询计划器425可选地可以确定其需要查询附加的块来解析第一查询(例如,当从最近的时间间隔向较老的间隔的“时间上回顾”以便找到与特定谓词匹配的一些值。
取决于查询,查询计划器425可以执行680结果的后处理。这样的后处理包括对返回的结果进行并集、对结果执行如求和(SUM)或计数(COUNT)的聚合、按特定字段对合并结果进行排序、采用使系统仅返回一些数量的结果的限制(LIMIT)等。其还可以涉及在合并块的结果时的更复杂的操作,例如,当跨来自每个块的部分结果计算前k个计算结果时。最后,系统返回该第一查询的结果。查询的结果可以包括一个或更多个元组或如果查询的处理导致错误则可以包括错误代码。
在一些实施方式中,跨多个数据库节点的查询还可以涉及使用查询或事务协调器,使得联系协调以获得附加信息,该附加信息在随后作为查询过程的一部分与其他数据库节点通信时被使用和/或发送。
节点还可以接收对一个或更多个块的查询,例如因为该节点是通过对超表的第一查询的处理而生成的查询的接收者。针对查询中指定的每个块,查询计划器425执行以下步骤。查询计划器425计划并且执行本地块上的查询。这使用包括选择和优化索引的使用、执行堆扫描等的查询计划技术。查询计划器425接收查询的结果。第三,取决于查询,查询计划器425还可以对结果进行后处理(如上所述,例如,对数据进行排序、执行聚合、采用限制等)。然后查询计划器425返回查询的结果。
数据库系统节点可以接收对传统数据库表的查询,这涉及以标准方式处理查询:在指定表上计划和执行查询、接收结果、可选地对结果进行后处理以及返回结果。
查询还可以指定多个表或表之间的连接(join)。数据库系统的处理取决于所指定的表的类型(例如,超表、块、标准非分区表)并且与上述步骤有关,但是个别步骤可以不同或者可以基于实际查询需要附加步骤。
基于超表处理查询的替选实施方式
理想地,数据库用户应当能够与时间序列数据交互,就像它在简单的连续数据库表中一样。然而,由于上面讨论的原因,使用单个表不能扩展。然而,要求用户手动对其数据进行分区显示了许多复杂性,例如,迫使用户不断指定要查询哪个分区、如何计算它们之间的连接(JOIN)或者如何在工作负荷变化时正确调整这些表的尺寸。
为了在仍然扩展和支持有效查询的同时避免该管理复杂性,数据库系统将自动数据分区和查询优化隐藏在其超表抽象背后。使用简单的SQL命令执行创建超表及其对应的模式,并且使用标准SQL命令就像该超表是单个表一样访问该超表。此外,就像普通的数据库表一样,可以通过标准SQL命令更改该模式;对用户透明地,数据库系统自动修改构成超表的全部基础块的模式。
在实施方式中,数据库系统通过挂钩诸如PostgreSQL的关系数据库的查询计划器来提供该功能,使得数据库系统接收本机SQL解析树。数据库系统使用该树来确定要访问哪个服务器和超表块(本机数据库表)、如何执行分布式和并行优化等。
这些相同优化中的许多甚至适用于单节点部署,其中自动将超表分割为块,并且相关的查询优化仍然提供了许多性能益处。如果块跨节点的各个位置(例如,跨多个本地或网络附接磁盘)分布,则尤其如此。在实施方式中,块在数据库节点上的布置由数据库管理员或用户给出的命令或策略指定。
在实施方式中,数据库系统仅在单个维度——按时间——而不是两个或更多个维度(例如,时间和空间维度)对其超表进行分区。例如,基于单个时间维度的分区可以用于在单个节点而不是节点集群上部署数据库系统。
另外,可以递归地定义超表。具体地,可以进一步对超表的块(通过相同或不同的分区键,并且利用相同或不同的时间间隔)进行分区并且因此该块表现得像另一超表。
通过运行时间动态地创建块并且对块调整尺寸以优化集群环境和单节点环境两者中的性能。沿着(除了时间之外的)附加维度属性对超表进行分区使插入平行于最近的时间间隔。类似地,查询模式通常跨时间或空间切片(slice),因此还通过本文公开的块布置导致性能改进。
这些块的布置也可以基于部署、工作负荷或查询需求而变化。例如,块可以随机地或有目的地跨位置展开以提供负荷平衡。替选地,属于分区字段的键空间的相同区域(例如,值或散列值的范围,或键的连续值的集合)但是通过时间间隔变化的块,可以被并置在同一服务器上。这避免了在针对空间中的单个对象(例如,特定设备)执行查询时查询接触全部服务器,这可以帮助减少较高查询负荷下的尾时延并且实现有效的连接。
数据库系统确定在创建块时块应当被布置的位置;该确定基于各种一个或更多个度量,包括随机或通过循环分布策略执行、基于服务器负荷(例如,请求速率、CPU利用率等)、基于现有使用(例如,以字节数或行数为单位的现有块的尺寸)、基于容量(例如,总存储器或存储装置容量、空闲内存、可用存储、磁盘数目等)、基于配置的策略或由管理员指定的等。数据库系统或管理员还可以选择在服务器之间重新定位(移动)或复制块。
即使在单节点设置中,针对读取查询和写入查询两者,组块仍然将性能提高超过单数据库表的普通使用(vanilla use)。正确尺寸的块确保表的索引(例如,B-树)中的大部分或全部可以在插入期间驻留在存储器中,以避免在修改这些索引中的任意位置时发生颠簸(thrashing)。此外,通过避免过大的块,数据库系统避免了在移除数据时的昂贵的“清理”操作,因为系统可以通过简单地丢弃块(内部表和/或文件)而不是删除单独的行来执行这样的操作。例如,该移除可以是数据删除的结果(例如,基于自动数据保留策略和过程),或者可以是失败或中断的大批插入的结果(非提交的行需要随后被移除)。同时,避免过小的块可以通过不需要从磁盘读取附加表和索引,或者不需要在大量块上执行查询计划来提高查询性能。
数据库系统考虑用于确定块尺寸的若干因素。首先,数据库系统保持指定附加分区字段将特定时间间隔分割成的分区的数目的元数据。例如,各自具有2个磁盘的10个机器可能使用20个分区(或每个服务器和/或磁盘多个分区)。这意味着特定字段的键空间(例如,设备ID、IP地址或位置名称)被划分为20个范围或集合。然后,数据库系统通过执行查找或比较过程来确定特定值与哪个范围(或分区)相关联。在一个实施方式中,字段是字符串或二进制值,并且数据库系统通过字段的值的前缀来分割键空间,然后基于共享最长公共前缀的分区将值映射到这些分区之一。替选地,数据库系统使用某些形式的散列使得散列输出的空间再次被划分为特定数目的范围或集合(例如,连续范围、通过分割整个散列输出空间限定的集合、通过取散列输出空间对节点数目的“求余(mod)”限定的集合、通过一致性散列限定的集合等)。数据库系统将散列函数应用于输入值以产生输出值;数据库系统确定包括输出值的范围或集合,该范围或集合然后对应于输入值所属的分区。数据库系统可以在这样的情况下使用各种函数,包括散列函数(例如,Murmur散列、Pearson散列、SHA、MD5、位置敏感散列)、恒等函数(即,简单地返回输入)或者对输入的一些其他加前缀或计算。
其次,一旦确定了基于分区键的分区的数目——并且实际上,该数目可以由于弹性而随时间改变,下面讨论——然后块的持续时间也确定其尺寸。针对恒定输入速率和一些给定数目的分区,具有以小时计的时间间隔的块通常远小于具有以天计的间隔的块。
在一个实施方式中,数据库系统使时间间隔静态或手动可配置。如果系统的数据量相对稳定(并且已知),则这样的方法是合适的,并且这为数据库管理员或用户提供了对数据库系统的操作的控制。但是,这样的固定时间间隔在数据量变化时可能效果不好——例如,适合于从100个设备提取数据的服务的时间间隔在系统扩展到100,000个设备时是不合适的——或者需要注意管理员或用户随时间变化改变间隔尺寸(以应用于未来的间隔或将现有间隔分割成多个块)。
在一个实施方式中,数据库系统基于块尺寸而不是基于固定时间间隔动态地确定块的时间间隔。具体地,在插入时间期间,数据库系统确定块是否正在接近或已超过某个阈值尺寸,此时数据库系统“关闭”当前块并且创建新块(例如,通过使用当前时间作为当前块的结束时间并且作为新块的开始时间)。
该阈值尺寸在软件配置中被给定为默认值,该默认值可以由数据库系统管理员配置,并且该尺寸可以在运行时间期间由管理员或数据库系统的逻辑来改变(使得同一数据库系统中的块可以具有不同的阈值尺寸)。在实施方式中,数据库系统根据系统的资源例如基于服务器的存储器容量选择尺寸,这还可以考虑表模式以确定将需要的索引的量及其尺寸要求。该调整考虑了模式随时间的实现的或潜在的变化。例如,如果将索引添加到许多字段(列)中,则存储这些字段所需的内存量发生变化,这导致数据库系统使用较小的块;如果许多字段未被索引,则数据库系统可以与没有任何未编制索引的字段的模式不同地考虑这些字段(因为稍后可以将索引添加到这些字段以实现更有效的查询)。替选地,认识到数据库最终将表存储在基础文件系统中的具有最大尺寸(例如,1GB)的文件中,系统确保块尺寸小于该最大尺寸。在实施方式中,作为块尺寸上的读/写性能的测量或估计结果来选择尺寸。
在一些实施方式中,即使当前块尺寸小于某个阈值(即,当前块尺寸“接近”阈值,并且尚未超过或等于阈值),数据库系统也创建新块,以针对数据库系统必须回填到较老的块中的不合时间顺序的数据的可能性留下一些“自由空间”。当写入较老或“封闭”的块时,数据库系统的不同实施方式允许块变得任意答、仅为新写入的过多数据创建新的交叠块、或者将现有块分割成两个以及其他方法。如果创建了交叠块,则数据库系统遵循其用于写入和读取重叠块的策略。
在另一实施方式中,数据库系统基于历史间隔及其尺寸动态地确定块的时间间隔。在该情况下,创建具有结束时间的新块,但是该结束时间由数据库系统基于具有特定间隔持续时间的较早块的结果尺寸自动设置。例如,如果数据库系统(或用户或管理员)希望尺寸接近1Gb的块,并且先前的12小时块导致尺寸为1.5GB的块,则数据库可能创建尺寸为6小时的后续块。数据库系统可以在其操作期间继续调整块的间隔,例如,以考虑每个间隔的变化数据量、以考虑不同的目标尺寸等。
在一些实施方式中,数据库基于时间间隔和阈值尺寸的混合来确定块。例如,数据库系统(或管理员)指定块具有预定时间间隔——使得如上所述,在创建时间处指定块的开始时间和结束时间——还指定如果针对该间隔的插入率超过某个量则块也具有最大尺寸。该方法避免了在每个间隔的系统负荷随时间变化的场景下纯粹基于固定时间间隔的组块问题。如果块的尺寸在当前时间间隔的中间期间接近或超过其最大允许阈值,则数据库系统创建与相同间隔重叠的新块,或者数据库系统切换到使用不同的时间间隔。对于前者,两个块表示相同的间隔,因此插入可以选择写入其中之一(而读取查询是它们两者)。对于后者,数据库系统可以将块的时间间隔更改为较小的时间间隔,并且创建新的非交叠块以在时间上使其成功。如早前所述,这样的块管理可以同步或异步地来执行,例如,后台任务将过大的块分割成两个块。
这样组块还可以将预定时间间隔限制为规则边界(例如,1小时、6小时、12小时、24小时、7天、14天),而不是任意的边界(例如,11分钟、57分钟)。该实施方式使得块间隔与下述时间段很好地对齐,在所述时间段上可以查询数据或可以例如根据诸如“删除超过12小时时长的数据”的数据保留策略进行删除。这样,数据库系统通过一旦其记录全部至少12小时时长则删除整个块而不是部分删除块内的个别行来实现这样的策略:丢弃整个块(数据库表)比删除表中等效数目的行更有效。
数据库系统以边界组合良好的方式选择这些边界,例如,边界是彼此的倍数或者以某些其他方式对齐。各种间隔尺寸之间的切换通过数据库运行时间(例如,响应于改变数据速率)或通过用户或管理员进行的配置被自动执行。类似地,管理员可以通过配置命令发信号通知数据库系统创建新块或块间隔,而不是总是基于自动策略关闭块和创建新块。
在一个实施方式中,数据库系统还将块的配置的这样的适应性应用于用于限定块的范围的非时间维度属性。例如,如果还在表示设备id的字段上执行超表的分区,则数据库系统可以将在该字段上限定的分区(值集)的数目从10增加到20。可以由数据库系统或通过用户或管理员进行的配置自动执行的这样的改变可以用于提高超表性能。例如,如果查询典型地指定根据其选择(SELECT)数据的单个设备id,则如果包含指定设备的块包括关于较少其他设备的信息——这可以通过增加设备id字段上的分区数目来实现——则可以改进查询的时延。
在另一实施方式中,数据库系统可以跨不同分区采用不同的时间间隔。例如,如果还对表示客户id的字段上执行超表的分区(例如,每个不同的客户id是单独的分区的情况),则数据库系统可以针对不同客户id独立地保持不同时间间隔(当在时间属性上进行分区时)。如果不同客户具有非常不同的插入和选择查询模式以及不同的数据保留需求,则这样的方法可以是有益的。
通常,假设存在多个不同目标和方法之间的工程权衡,数据库系统采用了各种方法以用于块管理。这些目标包括优化尺寸、对齐用于在保留数据完整性的同时丢弃块的时间间隔、使由于易变性导致的锁定或其他性能损失最小化、避免任意尺寸的间隔、创建最有利于约束排除的块边界、增加系统并行性、提高查询性能以及简化代码、操作和管理复杂性等。数据库系统的不同部署可以根据其设置和需要选择使用不同的方法。
鉴于系统重新配置调整分区策略
在数据库系统100中存储的数据量随时间增加。例如,大量的时间序列数据可以由数据库系统110接收并且被存储在数据库表中。数据库系统110经常重新配置系统以增加存储容量,例如通过添加存储设备。常规系统通过移动数据来适应系统配置的变化。例如,系统可以因添加新服务器而被重新配置,并且可以将一些数据块从现有服务器移动到新服务器以便确保新服务器为系统带来额外容量。因此,移动了大量数据,从而使系统重新配置成为昂贵且耗时的过程。参与服务器的该新配置也被称为表示服务器的集合及服务器的配置例如服务器的容量或磁盘数目的“视图”。系统适应计算资源的变化以便能够有效地使用全部可用资源的能力被称为弹性。
数据库系统110的实施方式在不执行这样的数据移动的情况下适应系统的重新配置。具体地,数据库系统110通过在数据库系统被重新配置以增加存储容量时创建块的新集合并且进行分区来提供弹性。数据库系统可以为在系统被重新配置之后创建的块的新集合使用不同的分区策略。例如,如果先前的分区策略针对10个服务器创建了20个分区,则新的分区策略可能创建30个分区以考虑被添加到数据库系统的5个新服务器。在另一示例中,先前的分区策略可以创建20个分区以在4个服务器中的每一个上布置5个分区,但是当添加附加的1个服务器时,新的分区策略然后可以在5个服务器中的每一个上布置4个分区。在一些实施方式中,数据库系统分布所创建的多个块使得与现有服务器相比为新服务器分配更多来自多个块中的块。这允许更好地跨服务器平衡负荷。在另一实施方式中,与分配给现有服务器的块相比,新服务器被分配更大的块。更大的块具有使得其能够比更小的块存储更多的数据的配置。仍然可以将数据读取或写入先前创建的块或新创建的块。由于对时间序列数据集的写入通常针对最新的时间间隔进行,并且许多查询工作负荷也处理最近数据,因此即使不移动现有数据,仍然保持跨服务器的新集合的负荷平衡。
图7(A至B)示出了根据本发明实施方式的用于适应于向数据库系统添加位置的数据库表的数据分区。
如图7(A)所示,数据库系统110可以具有多个存储位置710a、710b、710c和710d。图7示出了具有包括时间属性和空间属性(回顾使用术语“空间”分区来表示在非时间属性上的任何分区)的属性的数据库表的数据分布。响应于在数据库表中插入记录的请求,数据库系统110根据将块210分配给位置710的分区策略来分布数据库表的数据。在图7(A)所示的示例配置中,数据库系统110创建包括210a、210b、210c和210d的多个块,并且向每个位置分配一个块。块被沿着时间属性和空间属性跨数据库系统110的位置进行分布。因此,每个块与时间范围和空间范围相关联并且存储具有位于块的时间范围和空间范围内的时间属性和空间属性的记录。在图7所示的示例配置中,块210a、210b、210c和210d中的每一个与相同的时间属性范围相关联,即[0,6],但是具有不同的空间属性范围。例如,块210a具有空间范围[A,F],块210b具有空间范围[G,L],块210c具有空间范围[M,S]并且块210d具有空间范围[T,Z]。
图7(B)示出了在经过一段时间使得数据库系统已接收到插入具有晚于6的时间属性的记录的请求之后数据库表的块的分区。例如,响应于接收到插入具有时间属性为7的记录的请求,数据库系统创建新的多个块210e、210f、210g和210h。根据与上述相同的分区策略新的多个块被跨位置进行分布。根据该分区策略,来自新的多个块的每个块与新的时间范围[7,15]相关联。在该图示中,在相同位置中存储的块具有相同的空间范围。例如,分配给位置710a的块210a和210e两者具有空间范围[A,F],分配给位置710b的块210b和210f两者具有空间范围[G,L]等。数据库系统还可以将具有不同时间间隔但相同空间范围的块分配给不同位置。
图7(C)示出了在将新位置710e添加到数据库系统110之后数据库表的块的分区。因此,数据库系统110具有包括位置710a、710b、710c、710d和710e的多个位置。尽管图7示出了将单个位置添加到数据库系统,但是可以添加多于一个位置以增加数据库系统110的存储容量。响应于添加新位置,数据库系统110使用新的分区策略来跨位置分布记录。因此,响应于接收随后插入请求,例如,具有未映射到任何现有块的维度属性的值,数据库系统110创建包括210i、210j、210k、210l、210m和210n的多个块。块210i、210j、210k、210l被映射到位置710a、710b、710c、710d,并且块210m和210n两者被映射到新位置710e。在其他实施方式中,数据库系统可以将更多或更少的块分配给添加的新位置。因此,根据新的分区策略来分布接收到的随后记录。在图7所示的实施方式中,数据库系统110不移动被存储在添加新位置之前创建的块中的任何数据。然而,根据跨所有可用位置平衡数据存储的新的分区策略来分布响应于新位置的添加而创建的块。在图7(C)所示的示例中,由于与先前已存储数据的现有位置相比,新位置的存储和计算资源可能未充分利用,因此将更多块分配给新位置。然而,随着时间的推移,由于附加数据被存储在新位置上,新位置与现有位置之间的利用率差距减小,而不必将任何数据从现有位置移动到新位置。
如图7(C)所示,新分区策略在添加新位置之后创建具有更多块的多个块。因此,与添加新位置之前使用的分区策略的空间范围相比,新分区策略中每个空间范围更小。
在另一实施方式中,数据库系统不是通过如图7(C)所示向这些位置分配更多数目的块,而是通过分配具有带有更大的值集的维度范围的块来将较大部分的新数据分配给新位置。例如,数据库系统可以创建分配给位置710e的具有空间范围[Q,Z]的单个块而不是具有空间范围[Q,U]的块210m和具有空间范围[V,Z]的块210n。
在一些实施方式中,当数据库系统110检测到新位置正被添加到数据库系统时,数据库系统110基于新的存储配置动态地改变分区。在其他实施方式中,分区策略由用户例如,数据库系统管理员来配置。
分区策略确定如何创建新块并且将其分配给用于存储它们的位置。例如,如果正在实施分区策略并且需要创建新块(例如,以插入不能插入现有块中的记录),则可以根据分区策略创建和分布多个块。分区策略可以指定新块的创建的各个方面,包括正在创建的块的数目、正在创建的各个块的配置(该配置包括每个块的不同维度属性的值集),以及块至位置的映射。
分区策略可以将指定块创建/分布的各个方面的信息存储为元数据,例如,可以使用显式地存储正在创建的每个块的位置的映射表来存储从块至位置的映射。替选地,分区策略可以使用指令指定块创建/分布的各个方面,例如,分区策略可以使用函数(或指令集)来指定从块至位置的映射,函数在给定块配置和潜在的其他系统信息作为输入的情况下确定块的位置。不同的分区策略可以指定不同的映射函数(或指令集)。替选地,不同的分区策略可以使用相同的映射函数(或指令集),但是将不同的参数值作为输入传递。这样的映射函数(或指令集)可以包括随机选择、循环选择、基于散列的选择、基于正被存储的块的数目、尺寸或年龄的选择、基于何时将位置添加到数据库系统的年龄的选择、基于服务器资源的负荷均衡策略(包括插入率或查询率、CPU容量、CPU利用率、内存容量、可用内存等)、基于磁盘资源的负荷平衡策略(包括总磁盘容量、未使用的磁盘空间磁盘、磁盘IOPS容量、磁盘IOPS使用等),以及其他标准或算法方法以及它们的一些组合。分区策略可以使用上述技术的组合。
在实施方式中,分区策略指定正被创建的多个块的尺寸。多个块的尺寸可以表示正被创建的多个块中的块的数目。替选地,多个块的尺寸可以表示正被创建的多个块中的块的聚合尺寸,其中每个块的尺寸表示可以潜在被存储在块中的数据量的测量。基于包括块中存储的记录的不同维度属性的值集的块的配置来确定块的尺寸。例如,数据库系统可以通过分别为维度属性指定更大/更小的范围(或值集)来创建更大或更小的块。
在一些实施方式中,数据库系统110在某些场景下移动现有数据。例如,数据库系统可以实施将块与特定时间间隔对准的策略。因此,在基于新位置被添加的时间的时间处创建新块可能导致违反这样的策略。例如,数据库系统可以实施块具有12小时时间范围的标准。然而,如果向数据库系统添加新位置发生在12小时的时间间隔内的3小时处,则数据库系统将无法针对另外9小时并入新位置,或者必须保持具有3小时间隔的一些块。因此,在某些场景下,例如,如果当前正被填充的每个块中存储的数据量低于阈值量,则数据库系统移动或重新分配现有块而不是响应于添加新位置而创建新块。因此,数据库系统跨分布在新的多个位置上的块的新集合移动当前正被用记录填充的块的集合的数据并且继续向块的新集合添加记录。
在另一实施方式中,数据库系统延迟基于添加的新位置实施新分区策略,直到时间与块对齐很好地匹配。在以计划方式移除服务器、添加新服务器两者时或者甚至在服务器崩溃时可以使用该延迟动作(如果系统已为了高可用性而在多个服务器之间复制块)。例如,如果系统已经具有延伸直到午夜的时间范围的块,并且重新配置时间是晚上11点,则数据库系统可以在1小时内不基于新的分区策略创建块(例如,直到插入具有在午夜之后的时间属性的记录),但是重新配置将在创建块的新集合时生效。在这样的场景下,不重新配置现有块并且仅在新的服务器集合上分配新块。然而,在添加新位置之前和添加新位置之后,块的时间范围是相同的。
图8示出了示出根据实施方式的响应于向数据库系统添加新位置而修改数据库系统的数据分区策略的过程的流程图。数据库系统110包括被称为第一多个位置的多个位置。数据库系统110接收810在超表中插入记录的请求。数据库系统根据第一分区策略P1来分布块。因此,数据库系统110创建820多个块并且跨第一多个位置来分布该多个快。例如,如果数据库系统具有5个位置,则数据库系统110可以创建20个块并且在每个位置上存储4个块。数据库系统110基于记录的至少包括时间属性的维度属性来分布块。分区策略指定块/创建和分布的各个方面,包括:可以创建的块的数目、块的配置以及块至位置的映射。数据库系统可以多次重复步骤810和820,例如,直到数据库系统110被重新配置成改变位置的数目。
数据库系统110接收添加一个或更多个新位置的指示。例如,新位置可以是由系统管理员添加到数据库系统的现有服务器的存储设备。替选地,新位置可以是包括一个或更多个存储设备的被添加到数据库系统以用于存储和处理数据的新服务器。作为另一示例,位置可以是允许数据库系统110在其上存储数据的远程系统的存储设备,例如,基于云的存储设备。数据库系统接收的添加一个或更多个新位置的指示可以识别被添加到数据库系统的特定存储设备或者可以识别被添加到数据库系统的服务器。
在实施方式中,数据库系统110通过执行对通过一个或更多个数据库系统节点310可以到达的所有外围设备和服务器的检查来接收添加位置的指示。在其他实施方式中,数据库系统110通过由数据库用户或管理员执行的命令、通过从新位置接收消息来接收指示。将位置添加到数据库系统使得数据库系统110具有大于第一多个位置中的位置的数目的第二多个位置。添加一个或更多个位置的指示与重新配置时间相关联,例如,接收到指示的时间或完成一个或更多个新位置的添加的时间。
在接收到添加一个或更多个新位置的指示之后,数据库系统接收插入请求。例如,如果接收的插入请求中的记录不能被插入现有块中,则数据库系统110创建840第二多个块。数据库系统110基于第二分区策略P2创建第二多个块并且将它们分配给位置。例如,如图7(C)所示,第二分区策略P2将第二多个块映射到第二多个位置。块可以跨第二多个位置均匀地分布。替选地,被分配给新位置的块的数目或分区范围可以大于被分配给现有位置的块的数目或分区范围。例如,与现有位置相比,可以将更多来自第二多个块的块分配给新位置。替选地,与现有位置相比,可以将被配置成存储更多数据的块分配给新位置。可以通过针对块C1指定与块C2的相同维度属性的值集相比具有更多的元素的维度属性的值集来将块C1配置成与块C2相比存储更多的数据。例如,可以将块C1的时间属性指定为与块C2的时间属性相比具有更大的时间范围。
数据库系统110随后接收850在数据库表中插入数据的请求。数据库系统110基于记录的维度属性将接收到的记录存储860到块中。如本文结合图9至图12进一步描述的,可以将记录插入基于第一分区策略或第二分区策略创建的块中。数据库系统110识别与向数据库系统添加新位置相关联的重新配置时间T。
在实施方式中,数据库系统基于记录的时间属性将记录插入块中。因此,即使定义了新的分区策略,数据库系统也可以接收插入请求并且基于先前的分区策略创建块。例如,数据库系统可能例如由于网络或其他资源引起的延迟而非常晚地接收一些记录(即,这些记录被接收的时间可以显著地在记录的时间属性的值之后)。数据库系统可以基于老的分区策略来创建块以用于存储这些记录。因此,数据库系统可以同时实施多个分区策略——取决于接收并需要插入超表中的记录的数据。
图9示出了根据实施方式的基于记录的时间属性来选择用于创建块的分区策略。因此,不依赖插入请求被接收的时间,如果接收到具有在重新配置时间T之前的时间属性值的记录的插入请求,则创建的用于存储记录的任何新块均基于第一分区策略来创建。图9示出了时间线900和沿时间线的各种事件。例如,数据库系统最初具有三个位置(磁盘)910a、910b和910c,并且根据分区策略P1创建块。在重新配置时间T处,将新位置910d添加到数据库系统110。然而,如果在重新配置时间T之后接收到的插入请求具有在重新配置时间T之前的时间属性值,则数据库系统根据第一分区策略P1创建用于存储记录的块(如果现有块中没有一个可以存储记录)。此外,如果在重新配置时间T之后接收到的插入请求具有在重新配置时间T之后的时间属性值,则数据库系统根据第二分区策略P2创建用于存储记录的块(如果现有块中没有一个可以存储记录)。因此,根据第一分区策略P1创建块的时间间隔T1可以延伸到重新配置时间T之后。时间间隔T2指示根据第二分区策略P2创建块的时间。
图10示出了根据实施方式的用于基于记录的时间属性选择用于创建块的分区策略的过程的流程图。如果数据库系统针对正被插入的记录确定不能将记录存储在任何现有块中并且需要创建新块,则数据库系统调用图10所示的过程。数据库系统110确定1010接收的用于插入数据库表的记录的时间属性的值。数据库系统110将记录的时间属性的值与重新配置时间T进行比较1020。如果数据库系统110确定记录的时间属性小于重新配置时间T,则数据库系统110基于第一分区策略P1来创建块1030。如果数据库系统110确定记录的时间属性大于(或等于)重新配置时间T,则数据库系统110基于第二分区策略P2创建1040块。该记录被存储1050在创建的块中。
图11示出了根据实施方式的基于数据库系统接收记录的时间来选择用于创建块的分区策略。图11示出了时间线1100和沿时间线的各种事件。例如,数据库系统最初具有三个位置(磁盘)1110a、1110b和1110c,并且根据分区策略P1创建块。在重新配置时间T处,将新位置1110d添加到数据库系统110。数据库系统基于插入请求的到达时间选择用于创建块的分区策略(假设没有现有块可以用于存储接收的用于插入超表中的记录)。因此,在重新配置时间T之后(即,在时间间隔T2期间),根据第二分区策略P2创建块,而在重新配置时间T之前(即,在时间间隔T1期间),根据第一分区策略P1创建块。因此,所选的用于创建块的分区策略是不依赖正被插入的记录的时间属性的值来选择。例如,如果由于任何原因,具有与在重新配置时间T之前发生的时间对应的时间属性值的记录晚到达,即在重新配置时间T之后到达,则数据库系统根据第二分区策略P2创建用于存储记录的块。因此,具有小于重新配置时间T的时间属性值的记录可以被存储在根据分区策略P1或P2创建的块中。
在一些实施方式中,即使插入请求在重新配置时间T之后到达,但只要该记录的时间属性对应于块的时间范围,数据库系统继续将记录插入在重新配置时间T之前创建的块中。在其他实施方式中,数据库系统修改根据第一分区策略P1创建的现有块以便减少时间范围(如果需要)以与插入块中的最新记录对应。例如,如果插入请求的到达时间是早上5:30并且块的当前时间范围是直到中午,则数据库系统识别该块中具有其时间属性的最高值的记录。假设该块中具有最高时间值的记录具有时间上午5:45,则数据库系统将块的时间范围的结束修改为大于或等于早上5:45的时间,例如,早上6点。随后,如果数据库系统在大于早上6点的时间处接收到记录,则数据库系统根据从早上6点开始的新分区策略P2创建新块。
在一些实施方式中,作为系统的重新配置的结果,数据库系统可能创建重叠的块。数据库系统实施以下策略:在系统的重新配置之后,数据库系统不将记录插入基于第一分区策略P1创建的块中。因此,在系统的重新配置之后,即使存在映射到记录的维度属性的基于策略P1创建的现有块,数据库系统也基于分区策略P2创建用于存储记录的新块。因此,具有特定维度属性的记录可能潜在地存储在基于第一分区策略P1创建的块C1中或者存储在基于第二分区策略P2创建的块C2中。因此,块C1和C2重叠使得记录可以映射到块C1和C2两者,如果数据库系统随后接收处理特定记录R的查询,则数据库系统110确定记录R是存储在基于第一分区策略P1还是第二分区策略P2创建的块中。因此,数据库系统110可能必须检查两个可能的块以确定记录R被存储的位置。
在一些实施方式中,数据库系统110创建在用于对记录进行分区的时间范围方面与旧块交叠的新块。因此,即使在响应于添加新位置而创建块的新集合之后,数据库系统也可以将记录插入在添加位置之前创建的老块中。虽然这可以涉及老块(来自老视图)继续看到新插入的一些部分——但是这可以基于用于交叠块的插入策略来减轻,例如,一个这样的策略优选将新记录插入尺寸较小的块中——该交叠将不会继续到未来的间隔。例如,继续上面的示例,当数据库系统在现有块的间隔中的9小时创建新块时,其将新块的开始时间和结束时间设置为与现有块相同(即,9小时前和3小时后)。但是,因为数据库系统可以采用写入尺寸较小的块的策略,例如,即使两个集合具有交叠的时间段,也将对新块而不是现有块进行插入。
在使用确定何时关闭块的纯粹基于尺寸的方法的数据库系统的实施方式中,不会出现这些时间间隔问题,并且数据库系统然后简单地关闭现有块(即使现有块在系统重新配置的时间处的尺寸可能小于标准阈值尺寸)并且使用新的分区策略创建新块。
因为新视图可以保持不同的分区集,因此数据库系统可以保持将这些重新配置中的每一个关联到“时期”(“epoch”)的附加元数据。具体地,每个时期可以与包括时间段、分区集和系统视图的各种信息相关联。然后,如上所述,为了确定在特定时间处超表的分区,数据库系统可能需要首先确定与该时间相关联的时期,然后确定与该时期相关联的分区。该过程在数据库系统采用的插入方法的上下文中在上面进行了描述。
用于数据库系统的计算机的架构
图12是示出根据一个实施方式的用作图1所示的实体中的一个或更多个的计算机1200的示例的高级框图。示出了耦接至存储器控制器中心1220的至少一个处理器1202,该存储器控制器中心1220还耦接至输入/输出(I/O)控制器中心1222。存储器1206和图形适配器1212耦接至存储器控制器中心1222,并且显示器设备1218耦接至图形适配器1212。存储设备1208、键盘1210、定点设备1214和网络适配器1216耦接至I/O控制器中心。存储设备可以表示网络附接磁盘、本地和远程RAID或SAN(存储区域网络)。存储设备1208、键盘1210、定点设备1214和网络适配器1216耦接至I/O控制器中心1222。计算机1200的其他实施方式具有不同的架构。例如,在一些实施方式中,存储器直接耦接至处理器,并且在其他实施方式中存在耦接至不同部件的多个不同级别的存储器。一些实施方式还包括彼此耦接或经由存储器控制器中心耦接的多个处理器。
存储设备1208包括一个或更多个非暂态计算机可读存储介质,例如一个或更多个硬盘驱动器、光盘只读存储器(CD-ROM)、DVD或一个或更多个固态存储器设备。存储器保存处理器1202使用的指令和数据。定点设备1214与键盘结合使用以将数据输入计算机1200中。图形适配器1212在显示设备1218上显示图像和其他信息。在一些实施方式中,显示设备包括用于接收用户输入和选择的触摸屏功能。一个或更多个网络适配器1216将计算机1200耦接至网络。计算机的一些实施方式具有与图12所示的部件不同的和/或其他部件。例如,数据库系统可以包括缺少显示设备、键盘、定点设备和其他部件的一个或更多个服务器,而充当请求者的客户端设备可以是服务器、工作站、笔记本或桌上型计算机、平板计算机、嵌入式设备或手持设备或移动电话,或其他类型的计算设备。数据库系统的请求者也可以是数据库系统在其上运行的同一计算机上的另一过程或程序。
计算机1200适于执行用于提供本文中所描述的功能的计算机程序模块。如本文中所使用的,术语“模块”是指用于提供指定功能的计算机程序和/或其他逻辑。因此,模块可以以硬件、固件和/或软件来实现。在一个实施方式中,由可执行的计算机程序指令形成的程序模块被存储在存储设备上、被加载到存储器中以及由处理器执行。
其他考虑因素
在时间序列工作负荷中,通常针对最近的时间间隔进行写入,而不是跨许多老的时间间隔进行分布。这使得数据库系统110能够有效地将批插入写入少量表,而不是跨一个巨型表执行许多小的写入。此外,数据库系统的集群架构还利用至最近时间间隔的时间序列工作负荷,以便跨许多服务器和/或磁盘并行化写入以进一步支持高数据摄取速率。当在包括内存存储、硬盘驱动器(HDD)或固态驱动器(SSD)的各种存储技术上采用时,这些方法提高性能。
因为块尺寸被调整为适合服务器,并且因此数据库系统不构建大规模单个表,所以数据库系统避免或减少将其索引交换到针对最近时间间隔(其中通常发生大多数写入)的磁盘。这是因为数据库系统保持每个块的本地索引而发生;当将新记录插入块时,只需要更新块的(较小的)索引,而不是更新跨所有超表的数据构建的巨大索引。因此,对于与定期访问的最近时间间隔相关联的块,特别是如果有目的地调整块的尺寸,则可以将块的索引保持在存储器中。然而,数据库系统仍然可以有效地支持不同类型列上的许多不同类型的索引(例如,基于每个节点的数据库引擎例如PostgreSQL所支持的),所述不同类型的列包括B树、B+树、GIN、GiST、SP-GiST、BRIN、散列、LSM树、分形树和其他类型的索引。
数据库系统将其超表抽象的透明分区与许多查询优化相结合。这些优化包括用于以下操作的优化:使必须被接触以满足查询的块的数目和集合最小化、减少从接触块的查询传回的记录的量、指定是否从块传回原始记录或聚合结果等。
对时间序列数据的常见查询包括:(i)针对给定对象(例如,设备id)跨时间进行切片、针对给定时间间隔跨许多对象进行切片,或(iii)查询跨全部对象(的子集)或一些其他不同对象标签的最新报告的数据记录。虽然用户执行这些查询就好像与单个超表交互一样,但是数据库系统利用内部管理的元数据来仅查询或许可能满足查询谓词(predicate)的那些块。通过按照其查询计划积极地删减要接触的许多块和服务器——或在执行期间,当系统可以具有附加信息时——数据库系统改善查询时迟和吞吐量两者。
类似地,针对如唯一设备、用户或位置的项目,数据库系统可以接收如“选择针对每个设备的最后K个读数”的查询。虽然该查询可以在SQL中使用“选择不同”(“SELECTDISTINCT”)查询(用于查找每个不同项的第一或最后单值)或者通过窗口函数(用于查找K个这样的值)来自然地表达,但是这样的查询可以变成许多关系数据库中的全表扫描。事实上,该全表扫描可以继续回到时间的开始以捕获“针对每个设备”,或者以某种任意指定的时间范围牺牲完整性或者涉及大的WHERE子句或针对一些感兴趣的设备连接(这可以以手动或自动方式保持)。
在一些实施方式中,数据库系统保持关于超表的字段的附加元数据,以便优化这样的查询。例如,数据库系统记录关于数据库中该字段的每个独特(不同)值的信息(例如,其所属的时间间隔、最新行或块)。数据库系统使用该元数据以及它的其他优化,使得针对不同项目的这样的查询避免接触不必要的块,并且对每个单独块执行高效索引查询。保持这样的元数据的决定可能由于各种原因而手动或经由自动化手段作出,所述各种原因包括基于字段的类型、字段的不同项目的基数、查询和工作负荷模式等。
数据库系统可以执行有益于单节点部署和群集部署两者的其他查询优化。当连接来自多个表(本地地或跨网络,例如,经由外部数据封装器)的数据时,传统数据库可以首先选择与查询谓词匹配的所有数据,可选地对数据进行排序(ORDER),然后执行所请求的限制(LIMIT)。替代地,数据库系统110首先对每个块执行查询和后处理(例如,排序和限制),并且然后仅合并来自每个块的作为结果的集合(之后其执行最终排序和限制)。
数据库系统110将限制下推(pushdown)用于非聚合查询,以使跨网络复制数据或从表中读取不必要的数据最少化。数据库系统还将针对许多常用函数(例如,求和(SUM)、平均(AVG)、最小(MIN)、最大(MAX)、计数(COUNT))的聚合下推到块所在的服务器。主要地,集群部署的优点,这种分布式查询优化通过在块的服务器上原位执行大型汇总或分组依据(GROUP_BY)来极大地使网络传输最小化,使得仅需要在查询要结束时连接计算结果而不是来自每个块的原始数据。具体地,数据库系统中的每个节点执行其自己的部分聚合,并且然后仅将该结果返回给请求节点。
例如,如果对数据库系统的查询请求某个MAX(最大),则处理该超表查询的第一节点向其他节点发送MAX查询;每个接收节点在将结果发送回第一节点之前在其自己的本地块上执行MAX。该第一节点计算这些局部最大值的MAX,并且返回该结果。类似地,如果超表查询请求AVG(平均),则第一节点向其他服务器发送请求行的一些集合的和与计数的查询。这些节点可以将其和与计数返回给第一节点,然后第一节点根据这些值计算总平均(通过将和之和除以计数之和)。
数据库系统计算超表与标准关系表之间的连接。这些标准表可以被直接存储在数据库系统中,或者从外部数据库访问,例如经由外部数据封装器。
数据库系统110执行两个超表之间的连接,包括在很多方面涉及分布式优化,例如分布式连接。这样的优化包括使用基于散列的分区的优化,以及通过根据正在执行的连接仅将数据从一个超表的块发送至具有其他超表的块的服务器、可选地利用与块相关联的元数据来小心地使数据复制最少化的优化。这样的优化还包括以类似键或键范围通常并置在同一服务器上的方式将定期将被连接的超表的块放置在服务器上,以使在连接期间通过网络发送数据最少化。
数据库系统使得能够基于时间容易地限定数据保留策略。例如,管理员或用户可以使用显式命令或配置系统来清理/擦除超过X周时长的数据。系统的组块也有助于使这样的保留策略更有效率,因为数据库系统然后仅丢弃已过期的整个块(内部数据表)而不是需要删除个别行并积极地作为结果得到的表,尽管数据库系统确实支持这样的基于行的删除。
为了高效,数据库系统延缓实施这样的数据保留策略。也就是说,取决于策略或配置,可以不立即删除超过到期时间的个别记录。相反,当块中的全部数据过期时,则丢弃整个块。替选地,数据库系统在执行数据删除或遵守数据保留策略时使用丢弃块和删除个别行的混合。
已经出于说明的目的呈现了本发明的实施方式的前述描述;前述描述并非旨在穷举或将本发明限制为所公开的精确形式。鉴于以上公开内容,相关领域的技术人员可以理解许多修改和变型是可能的。
本说明书的一些部分从对信息的操作的算法和符号表示方面描述本发明的实施方式。数据处理领域的技术人员通常使用这些算法描述和表示来将其工作的实质有效地传达给本领域的其他技术人员。这些操作虽然在功能上、计算上或逻辑上进行描述,但应理解为由计算机程序或等效电路、微代码等实现。此外,将这些操作布置称为模块也被证明有时是方便的,且不失一般性。所描述的操作及其相关联的模块可以以软件、固件、硬件或其任何组合来实施。
可以利用一个或更多个硬件或软件模块单独地或与其他设备结合来执行或实现在本文中描述的任何步骤、操作或过程。在一个实施方式中,软件模块利用包括计算机可读介质的计算机程序产品实现,该计算机可读介质包含计算机程序代码,该计算机程序代码可以由计算机处理器执行以执行所述步骤、操作或过程中的任何或全部。
本发明的实施方式还可以涉及用于执行本文中的操作的装置。该装置可以为所需目的而专门构造和/或该装置可以包括由存储在计算机中的计算机程序选择性地激活或重新配置的通用计算设备。这样的计算机程序可以被存储在有形计算机可读存储介质或适于存储电子指令并耦接至计算机系统总线的任何类型的介质中。此外,说明书中提到的任何计算系统可以包括单个处理器或者可以是采用多处理器设计的架构以提高计算能力。
最后,说明书中使用的语言主要是出于易读和指导目的而选择的,并且语言可以不被选择来描绘或限制本发明的主题。因此,本发明的范围旨在不受该详细描述的限制,而是受基于其的申请上发布的任何权利要求的限制。因此,本发明的实施方式的公开内容旨在是说明性的而不是对本发明的范围的限制。
Claims (27)
1.一种计算机实现的方法,包括:
通过数据库系统接收插入请求,所述插入请求识别超表和用于插入所述超表中的一个或更多个输入记录,每个记录具有包括维度属性集的多个属性,所述维度属性集包括时间属性,其中,所述超表表示沿所述维度属性集被分区成多个块的数据库表,每个块与对应于每个维度属性的值集相关联,使得对于所述块中存储的每个记录,以及对于所述记录的每个维度属性,所述记录的维度属性的值映射到来自由所述块指定的所述维度属性的值集中的值;
对于所述一个或更多个输入记录中的每一个,确定所述输入记录是否应被存储在要创建的新块中,所述确定基于所述输入记录的维度属性的值,其中,确定所述输入记录应被存储在新块中是响应于确定所述输入记录的维度属性与任何现有块的配置都不匹配;
响应于确定输入记录应被存储在要创建的新块中,确定对应于要创建的新块的每个维度属性的值集;
动态创建用于存储所述输入记录的新块,所述新块与所确定的对应于每个维度属性的值集相关联;
通过将所述输入记录存储在所述新块中来更新所述超表;
在创建所述新块之后,接收识别所述超表和一个或更多个新输入记录的新插入请求;
对于所述一个或更多个新输入记录中的每一个,如果所述新输入记录的维度属性与现有块的配置匹配,则将所述新输入记录存储在所述现有块中,或者如果所述新输入记录的维度属性与所述新块的配置匹配,则将所述新输入记录存储在所述新块中;以及
响应于识别所述超表的一个或更多个随后查询而处理所更新的超表中存储的数据。
2.根据权利要求1所述的计算机实现的方法,其中,所述数据库系统在一个或更多个服务器的集合上存储数据,其中,所述多个块跨一个或更多个位置分布,其中,每个位置对应于以下之一:
添加到来自由所述数据库系统使用的服务器的所述集合中的服务器的存储设备;
属于新服务器的存储设备,其中,所述新服务器被添加到由所述数据库系统使用的服务器的所述集合;或者
远程服务器的网络附接存储设备,其能够被来自由所述数据库系统使用的服务器的所述集合中的服务器访问。
3.根据权利要求1所述的计算机实现的方法,其中,确定对应于所述新块的每个维度属性的值集包括:
确定一个或更多个最近创建的块的尺寸;
基于所述最近创建的块的尺寸预测所述新块的尺寸;以及
基于一个或更多个因素确定对应于所述新块的维度属性的值集,所述因素包括所预测的所述新块的尺寸。
4.根据权利要求1所述的计算机实现的方法,其中,确定对应于所述新块的每个维度属性的值集包括:
确定一个或更多个最近创建的块的尺寸超过阈值;并且
其中,响应于确定所述最近创建的块的尺寸超过所述阈值,将对应于维度属性的值集确定为与对应于所述最近创建的块的维度属性的值集相比具有较少的元素。
5.根据权利要求1所述的计算机实现的方法,其中,确定对应于所述新块的每个维度属性的值集包括:
监视一个或更多个现有块的性能;以及
基于所监视的性能确定对应于所述新块的维度属性的值集。
6.根据权利要求1所述的计算机实现的方法,其中,确定对应于所述新块的每个维度属性的值集包括:
识别用于存储所述新块的存储介质;
访问所述存储介质的性质,所述性质描述所述存储介质上存储的数据的访问速率;以及
基于所述存储介质的所述性质确定对应于所述新块的维度属性的值集。
7.根据权利要求1所述的计算机实现的方法,其中,所述维度属性集包括所述记录的第二属性,其中,所述记录的所述第二属性描述与所述记录相关联的实体的标识符。
8.根据权利要求1所述的计算机实现的方法,其中,所述超表与一个或更多个索引相关联,所述方法还包括:为所述新块创建所述一个或更多个索引。
9.根据权利要求1所述的计算机实现的方法,其中,响应于识别所述超表的一个或更多个随后数据库查询而处理所更新的超表中存储的数据包括:
接收用于处理所述超表中存储的数据的数据库查询;
识别所述超表的多个块,所述多个块中的每一个存储可能通过所述数据库查询处理的数据;
识别存储所述多个块的一个或更多个位置,所述一个或更多个位置中的每一个包括存储所述超表的一个或更多个块的存储设备;
针对所述一个或更多个位置中的每一个,基于所述位置中存储的数据确定所述数据库查询的部分结果;
聚合与所述一个或更多个位置中的每一个对应的部分结果以确定所述数据库查询的执行结果;以及
发送所述数据库查询的执行结果。
10.根据权利要求1所述的计算机实现的方法,还包括跨多个位置复制所述超表的块,其中,复制所述块包括将记录插入每个块的两个或更多个副本中,其中,每个副本被存储在与所述多个位置不同的位置处。
11.根据权利要求10所述的计算机实现的方法,其中,复制所述块还包括:
基于所述块的年龄确定所述块的副本的数目,其中,如果第一块的年龄值小于第二块的年龄值,则与针对所述第二块相比,针对所述第一块保持更多数目的副本。
12.根据权利要求10所述的计算机实现的方法,其中,复制所述超表的块还包括:
基于所述块的年龄确定用于存储每个块的副本的存储设备的类型。
13.根据权利要求1所述的计算机实现的方法,其中,每个位置与类型相关联并且所述超表与阈值年龄值相关联,所述方法还包括:
识别具有大于所述超表的所述阈值年龄值的年龄值的所述超表的块;以及
将所识别的块从具有第一类型的第一位置移动到具有第二类型的第二位置。
14.一种存储指令的非暂态计算机可读存储介质,所述指令用于以下操作:
通过数据库系统接收插入请求,所述插入请求识别超表和用于插入所述超表中的一个或更多个输入记录,每个记录具有包括维度属性集的多个属性,所述维度属性集包括时间属性,其中,所述超表表示沿所述维度属性集被分区成多个块的数据库表,每个块与对应于每个维度属性的值集相关联,使得对于所述块中存储的每个记录,以及对于所述记录的每个维度属性,所述记录的维度属性的值映射到来自由所述块指定的所述维度属性的值集中的值;
对于所述一个或更多个输入记录中的每一个,确定所述输入记录是否应被存储在要创建的新块中,所述确定基于所述输入记录的维度属性的值,其中,确定所述输入记录应被存储在新块中是响应于确定所述输入记录的维度属性与任何现有块的配置都不匹配;
响应于确定输入记录应被存储在要创建的新块中,确定对应于要创建的新块的每个维度属性的值集;
动态创建用于存储所述输入记录的新块,所述新块与所确定的对应于每个维度属性的值集相关联;
通过将所述输入记录存储在所述新块中来更新所述超表;
在创建所述新块之后,接收识别所述超表和一个或更多个新输入记录的新插入请求;
对于所述一个或更多个新输入记录中的每一个,如果所述新输入记录的维度属性与现有块的配置匹配,则将所述新输入记录存储在所述现有块中,或者如果所述新输入记录的维度属性与所述新块的配置匹配,则将所述新输入记录存储在所述新块中;以及
响应于识别所述超表的一个或更多个随后查询而处理所更新的超表中存储的数据。
15.根据权利要求14所述的非暂态计算机可读存储介质,其中,所述数据库系统在一个或更多个服务器的集合上存储数据,其中,所述多个块跨一个或更多个位置分布,并且其中,每个位置对应于以下之一:
添加到来自由所述数据库系统使用的服务器的所述集合中的服务器的存储设备;
属于新服务器的存储设备,其中,所述新服务器被添加到由所述数据库系统使用的服务器的所述集合;或者
远程服务器的网络附接存储设备,其能够被来自由所述数据库系统使用的服务器的所述集合中的服务器访问。
16.根据权利要求14所述的非暂态计算机可读存储介质,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
确定一个或更多个最近创建的块的尺寸;
基于所述最近创建的块的尺寸预测所述新块的尺寸;以及
基于一个或更多个因素确定对应于所述新块的维度属性的值集,所述因素包括所预测的所述新块的尺寸。
17.根据权利要求14所述的非暂态计算机可读存储介质,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
确定一个或更多个最近创建的块的尺寸超过阈值;以及
其中,响应于确定所述最近创建的块的尺寸超过所述阈值,将对应于维度属性的值集确定为与对应于所述最近创建的块的维度属性的值集相比具有较少的元素。
18.根据权利要求14所述的非暂态计算机可读存储介质,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
监视一个或更多个现有块的性能;以及
基于所监视的性能确定对应于所述新块的维度属性的值集。
19.根据权利要求14所述的非暂态计算机可读存储介质,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
识别用于存储所述新块的存储介质;
访问所述存储介质的性质,所述性质描述所述存储介质上存储的数据的访问速率;以及
基于所述存储介质的所述性质确定对应于所述新块的维度属性的值集。
20.根据权利要求14所述的非暂态计算机可读存储介质,其中,用于响应于识别所述超表的一个或更多个随后数据库查询而处理所更新的超表中存储的数据的指令包括用于以下操作的指令:
接收用于处理所述超表中存储的数据的数据库查询;
识别所述超表的多个块,所述多个块中的每一个存储可能通过所述数据库查询处理的数据;
识别存储所述多个块的一个或更多个位置,所述一个或更多个位置中的每一个包括存储所述超表的一个或更多个块的存储设备;
针对所述一个或更多个位置中的每一个,基于所述位置中存储的数据确定所述数据库查询的部分结果;
聚合与所述一个或更多个位置中的每一个对应的部分结果以确定所述数据库查询的执行结果;以及
发送所述数据库查询的执行结果。
21.一种计算机系统,包括:
一个或更多个处理器;以及
非暂态计算机可读存储介质,其存储用于由所述一个或更多个处理器执行的指令,所述指令用于以下操作:
通过数据库系统接收插入请求,所述插入请求识别超表和用于插入所述超表中的一个或更多个输入记录,每个记录具有包括维度属性集的多个属性,所述维度属性集包括时间属性,其中,所述超表表示沿所述维度属性集被分区成多个块的数据库表,每个块与对应于每个维度属性的值集相关联,使得对于所述块中存储的每个记录,以及对于所述记录的每个维度属性,所述记录的维度属性的值映射到来自由所述块指定的所述维度属性的值集中的值;
对于所述一个或更多个输入记录中的每一个,确定所述输入记录是否应被存储在要创建的新块中,所述确定基于所述输入记录的维度属性的值,其中,确定所述输入记录应被存储在新块中是响应于确定所述输入记录的维度属性与任何现有块的配置都不匹配;
响应于确定所述输入记录应被存储在要创建的新块中,确定对应于要创建的新块的每个维度属性的值集;
动态创建用于存储所述输入记录的新块,所述新块与所确定的对应于每个维度属性的值集相关联;
通过将所述输入记录存储在所述新块中来更新所述超表;
在创建所述新块之后,接收识别所述超表和一个或更多个新输入记录的新插入请求;
对于所述一个或更多个新输入记录中的每一个,如果所述新输入记录的维度属性与现有块的配置匹配,则将所述新输入记录存储在所述现有块中,或者如果所述新输入记录的维度属性与所述新块的配置匹配,则将所述新输入记录存储在所述新块中;以及
响应于识别所述超表的一个或更多个随后查询而处理所更新的超表中存储的数据。
22.根据权利要求21所述的计算机系统,其中,所述数据库系统在一个或更多个服务器的集合上存储数据,其中,所述多个块跨一个或更多个位置分布,并且其中,每个位置对应于以下之一:
添加到来自由所述数据库系统使用的服务器的所述集合中的服务器的存储设备;
属于新服务器的存储设备,其中,所述新服务器被添加到由所述数据库系统使用的服务器的所述集合;或者
远程服务器的网络附接存储设备,其能够被来自由所述数据库系统使用的服务器的所述集合中的服务器访问。
23.根据权利要求21所述的计算机系统,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
确定一个或更多个最近创建的块的尺寸;
基于所述最近创建的块的尺寸预测所述新块的尺寸;以及
基于一个或更多个因素确定对应于所述新块的维度属性的值集,所述因素包括所预测的所述新块的尺寸。
24.根据权利要求21所述的计算机系统,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
确定一个或更多个最近创建的块的尺寸超过阈值;以及
其中,响应于确定所述最近创建的块的尺寸超过所述阈值,将对应于维度属性的值集确定为与对应于所述最近创建的块的维度属性的值集相比具有较少的元素。
25.根据权利要求21所述的计算机系统,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
监视一个或更多个现有块的性能;以及
基于所监视的性能确定对应于所述新块的维度属性的值集。
26.根据权利要求21所述的计算机系统,其中,用于确定对应于所述新块的每个维度属性的值集的指令包括用于以下操作的指令:
识别用于存储所述新块的存储介质;
访问所述存储介质的性质,所述性质描述所述存储介质上存储的数据的访问速率;以及
基于所述存储介质的所述性质确定对应于所述新块的维度属性的值集。
27.根据权利要求21所述的计算机系统,其中,用于响应于识别所述超表的一个或更多个随后数据库查询而处理所更新的超表中存储的数据的指令包括用于以下操作的指令:
接收用于处理所述超表中存储的数据的数据库查询;
识别所述超表的多个块,所述多个块中的每一个存储可能通过所述数据库查询处理的数据;
识别存储所述多个块的一个或更多个位置,所述一个或更多个位置中的每一个包括存储所述超表的一个或更多个块的存储设备;
针对所述一个或更多个位置中的每一个,基于所述位置中存储的数据确定所述数据库查询的部分结果;
聚合与所述一个或更多个位置中的每一个对应的部分结果以确定所述数据库查询的执行结果;以及
发送所述数据库查询的执行结果。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110318803.1A CN113468232B (zh) | 2017-02-27 | 2018-02-27 | 用于查询时间序列数据的可扩展数据库系统 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762464289P | 2017-02-27 | 2017-02-27 | |
US62/464,289 | 2017-02-27 | ||
PCT/US2018/019990 WO2018157145A1 (en) | 2017-02-27 | 2018-02-27 | Scalable database system for querying time-series data |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110318803.1A Division CN113468232B (zh) | 2017-02-27 | 2018-02-27 | 用于查询时间序列数据的可扩展数据库系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110622152A CN110622152A (zh) | 2019-12-27 |
CN110622152B true CN110622152B (zh) | 2021-04-13 |
Family
ID=63246292
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110318803.1A Active CN113468232B (zh) | 2017-02-27 | 2018-02-27 | 用于查询时间序列数据的可扩展数据库系统 |
CN201880014274.2A Active CN110622152B (zh) | 2017-02-27 | 2018-02-27 | 用于查询时间序列数据的可扩展数据库系统 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110318803.1A Active CN113468232B (zh) | 2017-02-27 | 2018-02-27 | 用于查询时间序列数据的可扩展数据库系统 |
Country Status (5)
Country | Link |
---|---|
US (3) | US10073903B1 (zh) |
EP (1) | EP3563268B1 (zh) |
CN (2) | CN113468232B (zh) |
CA (3) | CA3052832C (zh) |
WO (1) | WO2018157145A1 (zh) |
Families Citing this family (80)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10437780B2 (en) * | 2016-07-14 | 2019-10-08 | Snowflake Inc. | Data pruning based on metadata |
US10346398B2 (en) | 2017-03-07 | 2019-07-09 | International Business Machines Corporation | Grouping in analytical databases |
US10776363B2 (en) | 2017-06-29 | 2020-09-15 | Oracle International Corporation | Efficient data retrieval based on aggregate characteristics of composite tables |
US20190036703A1 (en) * | 2017-07-28 | 2019-01-31 | Nexenta Systems, Inc. | Shard groups for efficient updates of, and access to, distributed metadata in an object storage system |
US10747729B2 (en) * | 2017-09-01 | 2020-08-18 | Microsoft Technology Licensing, Llc | Device specific chunked hash size tuning |
US11113282B2 (en) | 2017-09-29 | 2021-09-07 | Oracle International Corporation | Online optimizer statistics maintenance during load |
US10860576B2 (en) | 2018-01-26 | 2020-12-08 | Vmware, Inc. | Splitting a query into native query operations and post-processing operations |
US11016972B2 (en) | 2018-01-26 | 2021-05-25 | Vmware, Inc. | Splitting a time-range query into multiple sub-queries for serial execution |
US11016971B2 (en) | 2018-01-26 | 2021-05-25 | Vmware, Inc. | Splitting a time-range query into multiple sub-queries for parallel execution |
US11144570B2 (en) | 2018-01-26 | 2021-10-12 | Vmware, Inc. | Data ingestion by distributed-computing systems |
US10824623B2 (en) | 2018-02-28 | 2020-11-03 | Vmware, Inc. | Efficient time-range queries on databases in distributed computing systems |
US10812332B2 (en) | 2018-02-28 | 2020-10-20 | Vmware Inc. | Impartial buffering in stream processing |
US11178213B2 (en) | 2018-02-28 | 2021-11-16 | Vmware, Inc. | Automated configuration based deployment of stream processing pipeline |
US11010363B2 (en) | 2018-04-05 | 2021-05-18 | Sap Se | Complementing existing tables while grouping tables in a distributed database |
US11003693B2 (en) * | 2018-04-05 | 2021-05-11 | Sap Se | Grouping tables with existing tables in a distributed database |
US11354310B2 (en) * | 2018-05-23 | 2022-06-07 | Oracle International Corporation | Dual purpose zone maps |
US11567969B2 (en) * | 2018-05-29 | 2023-01-31 | Sap Se | Unbalanced partitioning of database for application data |
US11120052B1 (en) * | 2018-06-28 | 2021-09-14 | Amazon Technologies, Inc. | Dynamic distributed data clustering using multi-level hash trees |
US10884644B2 (en) * | 2018-06-28 | 2021-01-05 | Amazon Technologies, Inc. | Dynamic distributed data clustering |
CN109165217A (zh) * | 2018-08-03 | 2019-01-08 | 北京涛思数据科技有限公司 | 一种时序数据的高效存储方法 |
CN112740195A (zh) * | 2018-08-06 | 2021-04-30 | 甲骨文国际公司 | 数据库系统中维护统计的技术 |
US11722470B2 (en) * | 2018-08-29 | 2023-08-08 | International Business Machines Corporation | Encrypted data according to a schema |
WO2020041872A1 (en) | 2018-08-30 | 2020-03-05 | Streamworx.Ai Inc. | Systems, methods and computer program products for scalable, low-latency processing of streaming data |
US11921750B2 (en) * | 2018-10-29 | 2024-03-05 | Salesforce, Inc. | Database systems and applications for assigning records to chunks of a partition in a non-relational database system with auto-balancing |
US11989186B2 (en) * | 2018-11-23 | 2024-05-21 | Amazon Technologies, Inc. | Scalable architecture for a distributed time-series database |
US11934409B2 (en) | 2018-11-23 | 2024-03-19 | Amazon Technologies, Inc. | Continuous functions in a time-series database |
US11086840B2 (en) | 2018-12-07 | 2021-08-10 | Snowflake Inc. | Transactional streaming of change tracking data |
US11126597B2 (en) * | 2019-01-17 | 2021-09-21 | Servicenow, Inc. | Efficient database table rotation and upgrade |
US11409725B1 (en) | 2019-02-04 | 2022-08-09 | Amazon Technologies, Inc. | Multi-tenant partitioning in a time-series database |
US11853317B1 (en) | 2019-03-18 | 2023-12-26 | Amazon Technologies, Inc. | Creating replicas using queries to a time series database |
US11163756B2 (en) | 2019-04-16 | 2021-11-02 | Snowflake Inc. | Querying over external tables in database systems |
JP7286412B2 (ja) * | 2019-05-22 | 2023-06-05 | キヤノン株式会社 | 画像処理装置およびその制御方法、撮像装置、監視システム |
CN110297858B (zh) * | 2019-05-27 | 2021-11-09 | 苏宁云计算有限公司 | 执行计划的优化方法、装置、计算机设备和存储介质 |
US11256719B1 (en) * | 2019-06-27 | 2022-02-22 | Amazon Technologies, Inc. | Ingestion partition auto-scaling in a time-series database |
US11321284B2 (en) * | 2019-07-19 | 2022-05-03 | Vmware, Inc. | Adapting time series database schema |
US11500829B2 (en) | 2019-07-19 | 2022-11-15 | Vmware, Inc. | Adapting time series database schema |
US11609885B2 (en) | 2019-07-19 | 2023-03-21 | Vmware, Inc. | Time series database comprising a plurality of time series database schemas |
US11762853B2 (en) | 2019-07-19 | 2023-09-19 | Vmware, Inc. | Querying a variably partitioned time series database |
JP7245954B2 (ja) * | 2019-07-30 | 2023-03-24 | ファルコンリー インコーポレイテッド | 大量の時系列データの滑らか且つ解像度が扱いやすいビュー |
US10977234B2 (en) | 2019-08-02 | 2021-04-13 | Timescale, Inc. | Combining compressed and uncompressed data at query time for efficient database analytics |
US11216487B1 (en) * | 2019-09-23 | 2022-01-04 | Amazon Technologies, Inc. | Schema-based spatial partitioning in a time-series database |
US11036762B1 (en) * | 2019-11-27 | 2021-06-15 | Amazon Technologies, Inc. | Compound partition and clustering keys |
CN111190882B (zh) * | 2019-12-03 | 2023-07-11 | 泰康保险集团股份有限公司 | 目标模板创建方法及装置、电子设备、存储介质 |
US20210182416A1 (en) * | 2019-12-13 | 2021-06-17 | Vmware, Inc. | Method and system for secure access to metrics of time series data |
US11176120B2 (en) * | 2019-12-13 | 2021-11-16 | Salesforce.Com, Inc. | Foreign key constraint enforcement across database instances |
US11321205B2 (en) | 2020-01-06 | 2022-05-03 | International Business Machines Corporation | Enterprise-scale time series graphite backend infrastructure |
US11372871B1 (en) * | 2020-02-21 | 2022-06-28 | Rapid7, Inc. | Programmable framework for distributed computation of statistical functions over time-based data |
US11954125B2 (en) * | 2020-05-22 | 2024-04-09 | Yahoo Assets Llc | Partitioned backing store implemented in a distributed database |
CN111694814B (zh) * | 2020-05-27 | 2024-04-09 | 平安银行股份有限公司 | 日期分区表批量扩展方法、装置、计算机设备及存储介质 |
CN111726249B (zh) * | 2020-06-02 | 2022-10-04 | 中盈优创资讯科技有限公司 | 网络设备的配置文件处理方法及装置 |
CN111949652A (zh) * | 2020-06-22 | 2020-11-17 | 联想(北京)有限公司 | 一种数据指纹检测方法、装置及存储介质 |
US11599516B1 (en) * | 2020-06-24 | 2023-03-07 | Amazon Technologies, Inc. | Scalable metadata index for a time-series database |
CN115917525A (zh) * | 2020-07-08 | 2023-04-04 | 阿里巴巴集团控股有限公司 | 用于分区数据库的路由指令 |
CN112051968B (zh) * | 2020-08-07 | 2021-10-22 | 东北大学 | 基于Kafka的分布式数据流分级缓存自动迁移方法 |
CN115867901A (zh) * | 2020-08-21 | 2023-03-28 | 富士胶片株式会社 | 信息处理装置、信息处理方法及信息处理程序 |
US11221944B1 (en) * | 2020-08-25 | 2022-01-11 | Vmware, Inc. | Managing metadata for a backup data storage |
US11468099B2 (en) | 2020-10-12 | 2022-10-11 | Oracle International Corporation | Automatic creation and maintenance of zone maps |
US20220129445A1 (en) * | 2020-10-28 | 2022-04-28 | Salesforce.Com, Inc. | Keyspace references |
US11782873B2 (en) | 2020-11-11 | 2023-10-10 | Emeter Corporation | System and method for managing timeseries data |
US11544294B2 (en) | 2020-12-10 | 2023-01-03 | Sap Se | Distributing tables in a distributed database using consolidated grouping sources |
CN112597199B (zh) * | 2020-12-22 | 2024-03-08 | 南京三眼精灵信息技术有限公司 | 异构多数据源适配方法及装置 |
US11449521B2 (en) | 2020-12-22 | 2022-09-20 | Trendminer N.V. | Database management system |
CN113779061A (zh) * | 2021-02-04 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Sql语句的处理方法、装置、介质及电子设备 |
CN112817544B (zh) * | 2021-03-05 | 2024-09-20 | 北京星网锐捷网络技术有限公司 | 一种数据处理方法、存储系统及存储设备 |
CN112948343A (zh) * | 2021-03-25 | 2021-06-11 | 兴业数字金融服务(上海)股份有限公司 | 基于分布式大数据块的海量内容存储系统和方法 |
US11341150B1 (en) * | 2021-05-20 | 2022-05-24 | Clari Inc. | Organizing time-series data for query acceleration and storage optimization |
US11461347B1 (en) | 2021-06-16 | 2022-10-04 | Amazon Technologies, Inc. | Adaptive querying of time-series data over tiered storage |
US11941014B1 (en) | 2021-06-16 | 2024-03-26 | Amazon Technologies, Inc. | Versioned metadata management for a time-series database |
US11645252B2 (en) | 2021-07-23 | 2023-05-09 | Bank Of America Corporation | System and method for efficiently validating time-series data using a hash-based representation of the data |
US11640389B2 (en) | 2021-07-23 | 2023-05-02 | Bank Of America Corporation | Hash-based identification of data corruption issues in time-series data |
CN114201504A (zh) * | 2021-11-15 | 2022-03-18 | 北京达佳互联信息技术有限公司 | 一种信息获取方法、装置、电子设备及存储介质 |
US20230161770A1 (en) * | 2021-11-19 | 2023-05-25 | Elasticsearch B.V. | Shard Optimization For Parameter-Based Indices |
CN114297227B (zh) * | 2021-12-24 | 2023-06-20 | 成都索贝数码科技股份有限公司 | 时序数据库的架构方法、查询方法和时序数据库 |
CN114443654B (zh) * | 2022-01-14 | 2024-01-26 | 苏州浪潮智能科技有限公司 | 一种在线修改数据库表空间数据块长度的方法及系统 |
US11941029B2 (en) | 2022-02-03 | 2024-03-26 | Bank Of America Corporation | Automatic extension of database partitions |
US11777519B2 (en) * | 2022-02-10 | 2023-10-03 | International Business Machines Corporation | Partitional data compression |
CN114880324B (zh) * | 2022-04-28 | 2024-08-20 | 西北工业大学 | 一种带有空间约束的消息交换装置 |
CN115062028B (zh) * | 2022-07-27 | 2023-01-06 | 中建电子商务有限责任公司 | 一种OLTP领域多表join查询的方法 |
US20240095248A1 (en) * | 2022-09-15 | 2024-03-21 | Sap Se | Data transfer in a computer-implemented database from a database extension layer |
US11995084B1 (en) * | 2023-10-05 | 2024-05-28 | Timescale, Inc. | Database system for querying time-series data stored in a tiered storage using a cloud platform |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102483731A (zh) * | 2009-06-11 | 2012-05-30 | 雅虎公司 | 具有根据搜索负荷被均衡的指纹数据库的媒体识别系统 |
CN103514229A (zh) * | 2012-06-29 | 2014-01-15 | 国际商业机器公司 | 用于在分布式数据库系统中处理数据库数据的方法和装置 |
CN103635900A (zh) * | 2011-03-31 | 2014-03-12 | 伊姆西公司 | 基于时间的数据分割 |
CN104182460A (zh) * | 2014-07-18 | 2014-12-03 | 浙江大学 | 基于倒排索引的时间序列相似性查询方法 |
Family Cites Families (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006046669A1 (ja) * | 2004-10-28 | 2006-05-04 | University Of Fukui | データベース管理装置、方法、プログラム |
US7752230B2 (en) * | 2005-10-06 | 2010-07-06 | Avaya Inc. | Data extensibility using external database tables |
US7890541B2 (en) * | 2006-02-17 | 2011-02-15 | International Business Machines Corporation | Partition by growth table space |
US7680765B2 (en) | 2006-12-27 | 2010-03-16 | Microsoft Corporation | Iterate-aggregate query parallelization |
CN101876983B (zh) * | 2009-04-30 | 2012-11-28 | 国际商业机器公司 | 数据库分区方法与系统 |
CN102667761B (zh) * | 2009-06-19 | 2015-05-27 | 布雷克公司 | 可扩展的集群数据库 |
US8156304B2 (en) * | 2009-12-04 | 2012-04-10 | Oracle International Corporation | Dynamic data storage repartitioning |
WO2011142026A1 (ja) * | 2010-05-14 | 2011-11-17 | 株式会社日立製作所 | 時系列データ管理装置、システム、方法、およびプログラム |
US9740762B2 (en) * | 2011-04-01 | 2017-08-22 | Mongodb, Inc. | System and method for optimizing data migration in a partitioned database |
US9507816B2 (en) * | 2011-05-24 | 2016-11-29 | Nintendo Co., Ltd. | Partitioned database model to increase the scalability of an information system |
US8595267B2 (en) * | 2011-06-27 | 2013-11-26 | Amazon Technologies, Inc. | System and method for implementing a scalable data storage service |
US9052831B1 (en) * | 2011-06-30 | 2015-06-09 | Amazon Technologies, Inc. | System and method for performing live partitioning in a data store |
US9390147B2 (en) * | 2011-09-23 | 2016-07-12 | Red Lambda, Inc. | System and method for storing stream data in distributed relational tables with data provenance |
US9753999B2 (en) * | 2012-01-06 | 2017-09-05 | Citus Data Bilgi Islemieri Ticaret A.S. | Distributed database with mappings between append-only files and repartitioned files |
US8799284B2 (en) * | 2012-11-30 | 2014-08-05 | Futurewei Technologies, Inc. | Method for automated scaling of a massive parallel processing (MPP) database |
US9152671B2 (en) | 2012-12-17 | 2015-10-06 | General Electric Company | System for storage, querying, and analysis of time series data |
US10977229B2 (en) * | 2013-05-21 | 2021-04-13 | Facebook, Inc. | Database sharding with update layer |
US9792349B2 (en) * | 2013-06-12 | 2017-10-17 | Oracle International Corporation | In-database sharded queue |
US9158472B2 (en) * | 2013-06-25 | 2015-10-13 | Google Inc. | Hierarchical chunking of objects in a distributed storage system |
US9811580B2 (en) * | 2013-10-10 | 2017-11-07 | International Business Machines Corporation | Policy based automatic physical schema management |
US9720989B2 (en) | 2013-11-11 | 2017-08-01 | Amazon Technologies, Inc. | Dynamic partitioning techniques for data streams |
US9720949B2 (en) | 2013-11-22 | 2017-08-01 | Sap Se | Client-side partition-aware batching of records for insert operations |
JP2017505936A (ja) * | 2013-12-02 | 2017-02-23 | キューベース リミテッド ライアビリティ カンパニー | インメモリデータベースをホストするシステム及び方法 |
WO2015149885A1 (en) | 2014-04-01 | 2015-10-08 | Huawei Technologies Co.,Ltd | Method for querying and updating entries in a data base |
US20150347555A1 (en) * | 2014-05-31 | 2015-12-03 | Linkedin Corporation | Waterwheel sharding |
CN105488043B (zh) * | 2014-09-15 | 2019-03-26 | 南京理工大学 | 基于Key-Value数据块的数据查询方法及系统 |
CN105404634B (zh) * | 2014-09-15 | 2019-02-22 | 南京理工大学 | 基于Key-Value数据块的数据管理方法及系统 |
EP2998881B1 (en) * | 2014-09-18 | 2018-07-25 | Amplidata NV | A computer implemented method for dynamic sharding |
US10067969B2 (en) * | 2015-05-29 | 2018-09-04 | Nuodb, Inc. | Table partitioning within distributed database systems |
US10671496B2 (en) * | 2016-05-31 | 2020-06-02 | Mongodb, Inc. | Method and apparatus for reading and writing committed data |
US20170371910A1 (en) * | 2016-06-28 | 2017-12-28 | Microsoft Technology Licensing, Llc | Real-time shard rebalancing for versioned entity repository |
US10585915B2 (en) * | 2017-10-25 | 2020-03-10 | International Business Machines Corporation | Database sharding |
-
2018
- 2018-02-27 EP EP18758152.5A patent/EP3563268B1/en active Active
- 2018-02-27 CA CA3052832A patent/CA3052832C/en active Active
- 2018-02-27 CN CN202110318803.1A patent/CN113468232B/zh active Active
- 2018-02-27 CN CN201880014274.2A patent/CN110622152B/zh active Active
- 2018-02-27 WO PCT/US2018/019990 patent/WO2018157145A1/en unknown
- 2018-02-27 CA CA3128761A patent/CA3128761C/en active Active
- 2018-02-27 US US15/907,105 patent/US10073903B1/en active Active
- 2018-02-27 US US15/907,114 patent/US10073888B1/en active Active
- 2018-02-27 CA CA3128753A patent/CA3128753C/en active Active
- 2018-08-22 US US16/109,644 patent/US10509785B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102483731A (zh) * | 2009-06-11 | 2012-05-30 | 雅虎公司 | 具有根据搜索负荷被均衡的指纹数据库的媒体识别系统 |
CN103635900A (zh) * | 2011-03-31 | 2014-03-12 | 伊姆西公司 | 基于时间的数据分割 |
CN103514229A (zh) * | 2012-06-29 | 2014-01-15 | 国际商业机器公司 | 用于在分布式数据库系统中处理数据库数据的方法和装置 |
CN104182460A (zh) * | 2014-07-18 | 2014-12-03 | 浙江大学 | 基于倒排索引的时间序列相似性查询方法 |
Also Published As
Publication number | Publication date |
---|---|
US20190188204A1 (en) | 2019-06-20 |
EP3563268A1 (en) | 2019-11-06 |
CN110622152A (zh) | 2019-12-27 |
EP3563268B1 (en) | 2022-09-14 |
CA3052832A1 (en) | 2018-08-30 |
US20180246934A1 (en) | 2018-08-30 |
CA3128761C (en) | 2023-04-04 |
CN113468232B (zh) | 2024-10-18 |
US10073888B1 (en) | 2018-09-11 |
CA3052832C (en) | 2021-11-16 |
US10073903B1 (en) | 2018-09-11 |
CA3128753A1 (en) | 2018-08-30 |
WO2018157145A1 (en) | 2018-08-30 |
CA3128753C (en) | 2023-04-18 |
US20180246950A1 (en) | 2018-08-30 |
CN113468232A (zh) | 2021-10-01 |
EP3563268A4 (en) | 2020-10-07 |
US10509785B2 (en) | 2019-12-17 |
CA3128761A1 (en) | 2018-08-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110622152B (zh) | 用于查询时间序列数据的可扩展数据库系统 | |
US10963456B2 (en) | Querying of materialized views for time-series database analytics | |
US10936562B2 (en) | Type-specific compression in database systems | |
US20220405284A1 (en) | Geo-scale analytics with bandwidth and regulatory constraints | |
US10614050B2 (en) | Managing object requests via multiple indexes | |
US11080207B2 (en) | Caching framework for big-data engines in the cloud | |
Ciritoglu et al. | Hard: a heterogeneity-aware replica deletion for hdfs | |
US11995084B1 (en) | Database system for querying time-series data stored in a tiered storage using a cloud platform | |
US11893016B1 (en) | Secure predicate derivation of queries using metadata | |
Dory | Study and Comparison of Elastic Cloud Databases: Myth or Reality? | |
Han | Design patterns for HBase configuration |
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 |