WO2013138953A1 - 数据存储与查询方法 - Google Patents
数据存储与查询方法 Download PDFInfo
- Publication number
- WO2013138953A1 WO2013138953A1 PCT/CN2012/000534 CN2012000534W WO2013138953A1 WO 2013138953 A1 WO2013138953 A1 WO 2013138953A1 CN 2012000534 W CN2012000534 W CN 2012000534W WO 2013138953 A1 WO2013138953 A1 WO 2013138953A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- minitable
- key
- request
- server
- address
- Prior art date
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/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24542—Plan optimisation
-
- 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
Definitions
- the present invention relates to the field of computer application technologies, and in particular, to a data storage and query method supporting agile development and horizontal expansion.
- the business of the Internet industry is changing rapidly and the product development cycle is short. Especially for social networking sites, the product development cycle is measured in days.
- a data management system that is a fundamental component of Internet products must support an agile development model to reduce product development cycles.
- a data management system that simultaneously supports a scale-out mode that supports massive data and an agile development model that supports a short development cycle is the key to building an Internet service system.
- Key-Value Store This technique abstracts the data into a two-dimensional vector (Key, Value). Key is a unique identifier for data storage and query, and Value is the data content corresponding to a specific key.
- the Key-Value Store has three basic primitives. Boolean Put(Key, Value): Store (Key, Value), if saved successfully Returns True, and returns False if the deposit fails. Boolean Del (Key): Delete (Key, Value), if the deletion returns True, the deletion fails or there is no corresponding Key, then returns False. String Get(Key), Get the value corresponding to the Key. If it fails or does not exist, it returns NULL. Since there is no dependency between any two (Key, Value) pairs, the horizontal expansion of the Key-Value Store can be implemented using a consistent hash or a B+ tree.
- Key-Row Store (or Big Table). This technique abstracts data into a nested n+1-dimensional vector (Key, (SubKey 1, Value 1), (SubKey 2, Value 2), ..., (SubKey n, Value n)) 0
- Key is a unique identifier for data row storage and query. Each data row contains multiple data, and the corresponding value is obtained through SubKey.
- the Key-Row Store has five basic primitives. Boolean Put (Key, SubKey, Value): Add (SubKey, Value) to the corresponding data row of Key, return True if the deposit succeeds, and return False if the save fails. Boolean Del (Key): Deletes the data row corresponding to the Key. If the deletion succeeds, it returns True. If the deletion fails or there is no corresponding Key, it returns False. Boolean Del (Key, SubKey): Deletes the (SubKey, Value) in the corresponding data row of the Key. If the deletion succeeds, it returns True.
- the technical problem solved by the present invention is to provide a data storage and query method, wherein the data storage includes creating and updating data; the method satisfies the horizontal expansion feature and supports the SQL syntax, and is more suitable for the agile development mode.
- the data is abstracted into a binary group (Key, MiniTable), and any MiniTable (removing the data set) is identified by a unique Key;
- MiniTable is composed of several data rows, and the structure of the data row is restricted by a predefined pattern, and the row is defined by mode. Sort the primary key;
- the Key-MiniTable mode has three basic primitives and three physical entities.
- the three physical entities are:
- the client uses three basic primitives to initiate a request to the Key server and receives the request result.
- the Key server receives the request initiated by the client, and searches for the IP address and port number of the MiniTable server where the Key corresponds to the MiniTable, and forwards the request to the corresponding MiniTable server.
- the MiniTable server receives the request forwarded by the Key server, parses the SQL statement of the request, generates an execution plan, and acquires and writes data in the distributed storage system, and completes the request to return the result to the client.
- each MiniTable is limited. Generally, it is less than or equal to 64M. It is convenient to put the entire MiniTable into a data block of the Hadoop distributed file system. You cannot perform operations between joins in the relational database between two different MiniTables. Multiple tables are jointly locked; Key is not only the identity of the MiniTable, but also the storage location identifier of the MiniTable in the distributed storage system.
- the MiniTable records the data in the log format.
- the add, delete, and modify data are written to the end of the file.
- the log is merged to generate a new file.
- the Key server and the MiniTable server are doing any The operation is written to the system log file before the operation, and the return value is also written to the system log file when the operation is completed or fails.
- the Key server has three core data structures:
- B+ tree stores the correspondence between the Key and the address number
- MiniTable server monitoring table store each address number corresponding to the load of the MiniTable server
- the Key server When the Key server receives a primitive request, it checks whether it is a legal Query primitive; if it is a legal Query primitive, it queries the B+ tree for the address number corresponding to the Key; if the Key does not exist, it returns the Key non-existent information; If the key exists, query the IP address and port number corresponding to the address number in the address translation table; if the IP address and port number do not exist, an error is returned; if yes, the request is forwarded to the IP address and the port number.
- MiniTable server MiniTable server
- the request is not a legal Queiy primitive, it is checked whether it is a legal Create primitive; if it is a legal Create primitive, it is queried in the B+ tree for the existence of a given Key; if the Key exists, the return Key exists. If the key does not exist, allocate an address number according to the scheduling algorithm and the MiniTable server monitoring table, update the MiniTable server monitoring table, use the address number to query the corresponding IP address and port number, and forward the request to the corresponding MiniTable server;
- the request is not a legal Create primitive, it is checked whether it is a legal Delete primitive; if it is a legal Delete primitive, it is queried in the B+ tree for the existence of a given Key; if the Key does not exist, the return Key does not exist information; If the key exists, query the IP address and port number corresponding to the address number in the address translation table, delete the corresponding key in the B+ tree, update the monitoring table of the MiniTable server, query the IP address and port number, and forward the request to the corresponding MiniTable. server.
- the MiniTable server has two core data structures:
- the MiniTable server After receiving the request forwarded by the Key server, the MiniTable server performs semantic parsing on the request to determine whether the MiniTable of the request operation is locked. If the lock is added, the request is added to the waiting queue. If the lock is not locked, the MiniTable is locked and generated.
- Execution plan After that, determine whether the MiniTable is in the memory table, if the request is directly executed in the memory table; if not in the memory table, further determine whether there is enough memory space; if not, according to the scheduling policy, write a part of the MiniTable Distributed file system; Compare the difference between the MiniTable memory version and the file version when writing, and only write the updated part in the log compression format; after obtaining sufficient memory space, read the MiniTable file from the distributed file system and decompress it; Convert the MiniTable log file to a data format and store it in the memory table; then execute the request, unlock the MiniTable, and return the result.
- the present invention can construct a data management system that supports storage (including creation and update) and query of data, and the system satisfies the following two important properties.
- Agile development The operation of MiniTable internal data supports SQL syntax, which can quickly implement complex logic queries and complex conditional insertion.
- Scale-out Remove the dependencies between MiniTables through the Key-MiniTable mode.
- FIG. 1 is a structural diagram of a Key-MiniTable system of the present invention
- Figure 3 is a flow chart of the execution of the MiniTable server.
- FIG. 1 it is a structural diagram of the Key-MiniTable system in the present invention.
- the Key-MiniTable system is built on top of a distributed file system, such as the Hadoop Distributed File System (HDFS).
- the data stored in the distributed file system is divided into two parts:
- MiniTable log file The MiniTable is stored in the data block. In order to improve access and cache performance, the data size of MiniTable does not exceed the maximum capacity of the data block (typically 64M). To mention write performance, MiniTable records data in a log format, and adds, deletes, and modifies data to the end of the file. Log merge is performed when the size of the MiniTable file is close to the maximum capacity of the data block, and a new log file is generated.
- System log file The Key server and MiniTable server write the operation to the system log file before doing any operation. The return value is also written to the system log file when the operation is completed or fails. Maintaining system log files restores the previous normal state in the event of a system failure.
- the user When data needs to be created, updated, or deleted, the user initiates a primitive request to the Key server using the client.
- the Key server execution process is shown in Figure 2.
- the Key server has three core data structures:
- B+ tree Stores the correspondence between the Key and the address number.
- Address translation table Stores the correspondence between the address number and the IP address and port number.
- MiniTable server monitoring table Stores the load status of each MiniTable server corresponding to each address number.
- the Key server When the Key server receives a primitive request, it checks if it is a legal Query primitive. If it is a legal Query primitive, the address number corresponding to the Key is queried from the B+ tree. If the Key does not exist, the key does not exist. If the Key exists, query the IP address and port number corresponding to the address number in the address translation table. If the IP address and port number do not exist, an error is returned. If yes, the request is forwarded to the MiniTable server corresponding to the IP address and port number.
- the request is not a legal Query primitive, check if it is a legal Create primitive. If it is a legal Create primitive, it is queried in the B+ tree for the existence of a given Key. If the Key exists, it returns the Key existing information. If the key does not exist, allocate an address number according to the scheduling algorithm and the MiniTable server monitoring table, update the MiniTable server monitoring table, query the corresponding IP address and port number by using the address number, and forward the request to the corresponding MiniTable server.
- the request is not a legal Create primitive, check if it is a legal Delete primitive. If it is a legal Delete primitive, it is queried in the B+ tree for the existence of a given Key. If the Key does not exist, there is no information in the Return Key. If the key exists, query the IP address and port number corresponding to the address number in the address translation table, delete the corresponding key in the B+ tree, update the monitoring table of the MiniTable server, query the IP address and port number, and forward the request to the corresponding MiniTable server.
- the MiniTable server has two core data structures:
- Memory table According to the cache policy, some MiniTables are stored in the memory.
- MiniTable lock Record the locked MiniTable.
- the MiniTable server After receiving the request forwarded by the Key server, the MiniTable server performs semantic analysis on the request. Determine whether the MiniTable requesting the operation is locked. If locked, the request is added to the waiting queue. If not locked, Then lock the MiniTable and generate an execution plan. After that, it is determined whether the MiniTable is in the memory table. If the request is executed directly in the memory table. If it is not in the memory table, further determine whether there is enough memory space. If not, part of the MiniTable is written to the distributed file system according to the scheduling policy. Compare the difference between the MiniTable memory version and the file version when writing, and only write the updated part in the log compression format. After obtaining enough memory space, read in the MiniTable file from the distributed file system and decompress it.
- the invention utilizes a method for removing the dependency relationship between data sets to obtain the horizontal expansion capability of the system, and at the same time retains the dependency relationship between the data within the data set to support the SQL-like syntax, thereby obtaining the characteristics of the agile development.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Operations Research (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
公开了计算机应用技术领域中的一种支持敏捷开发和横向扩展的数据存储与查询方法。其中将数据抽象为一个二元组（Key，MiniTable），任意MniTable(去除数据集合）由唯一的Key标识；MiniTable由若干数据行组成，并且由预先定义的模式限制数据行的结构，行按模式定义的主键进行排序；利用去除数据集合之间依赖关系的方法获取系统的横向扩展能力，同时保留数据集合内部数据之间的依赖关系以支持类SQL语法，从而获取敏捷开发的特性。该方法可以应用于支持海量数据的横向扩展模式和支持短开发周期的敏捷开发模式的数据管理系统。
Description
技术领域
本发明涉及计算机应用技术领域， 特别涉及一种支持敏捷开发和横向扩展 的数据存储与查询方法。
背景技术
随着互联网的飞速发展， 特别是在线社交网络 （Social Networks ) 在线社 交媒体 （Social Media) 等新型 Web 2.0业务的出现， 互联网产业对数据管理系 统提出了两个重要的挑战。
1、 互联网中的数据呈指数增长， 业界称之为 "海量数据 （Big Data)"。 海 量数据给现有的纵向扩展数据管理系统带来了巨大的压力。 数据管理系统已成 为大量互联网服务系统中的瓶颈。
2、 互联网行业的业务变化迅速， 产品开发周期短。 特别是社交网站， 其产 品开发周期均以天作为度量单位。 作为互联网产品基础部件的数据管理系统必 须支持敏捷开发模式以降低产品的开发周期。
因此， 同时满足支持海量数据的横向扩展模式和支持短开发周期的敏捷开 发模式的数据管理系统是构建互联网服务系统的关键。
到目前为止， 主要有两大类数据管理技术支持横向扩展模式。
1、 Key-Value Store。 该技术把数据抽象为一个二维向量 (Key, Value)。 Key 是数据存储与查询的唯一标识符， Value为特定 Key对应的数据内容。 Key-Value Store有三个基本原语。 Boolean Put(Key， Value): 存储 (Key, Value), 若存入成功
返回 True, 存入失败则返回 False。 Boolean Del(Key): 删除 (Key, Value), 若删除 成功返回 True, 删除失败或不存在对应 Key则返回 False。 String Get(Key), 获 取 Key对应的 Value,若失败或不存在对应 Key则返回 NULL。由于任意两个 (Key, Value)对之间不存在依赖关系， 因此可以利用一致性哈希或 B+树实现 Key-Value Store的横向扩展。
2、 Key-Row Store (或称之为 Big Table)。该技术把数据抽象为一个嵌套 n+1 维向量 (Key, (SubKey 1， Value 1), (SubKey 2， Value 2)， ......， (SubKey n, Value n))0
Key是数据行存储与查询的唯一标识符，每一数据行包含多个数据，通过 SubKey 获取对应的 Value。 Key-Row Store有五个基本原语。 Boolean Put(Key, SubKey, Value): 在 Key对应数据行中加入 (SubKey, Value), 若存入成功返回 True, 存入 失败则返回 False。 Boolean Del(Key): 删除 Key对应的数据行， 若删除成功返回 True, 删除失败或不存在对应 Key则返回 False。 Boolean Del(Key, SubKey): 删 除 Key对应数据行中的 (SubKey, Value),若删除成功返回 True,删除失败或不存 在对应 Key或 SubKey则返回 False。 String Get(Key), 获取 Key对应数据行， 若 失败或不存在对应 Key则返回 NULL。 String Get(Key, SubKey), 获取 Key对应 数据行中 SubKey对应的 Value, 若失败或不存在对应 Key或 SubKey则返回 NULL。与 Key- Value Store相同， 数据行与数据行之间没有依赖关系， 同样可以 利用一致性哈希或 B+树实现 Key-Row Store的横向扩展。
虽然如上两种技术支持横向扩展模式， 满足互联网产业对数据管理系统的 第一个挑战， 但是这两种技术均只提供简单原语， 而这些简单原语难以快速地 构建具有复杂逻辑的应用， 因此不支持敏捷开发模式， 不能满足互联网产业对 数据管理系统的第二个挑战。
目前， SQL语言， 因其标准统一、 语义丰富、 结构简单， 已成为使数据管 理系统支持敏捷开发的主要技术。 但是兼容 SQL语义将会使得数据与数据之间 相互依赖， 从而失去横向扩展的特性。 因此目前兼容 SQL语义的关系数据库只
能依赖纵向扩展， 不能满足互联网大数据的挑战。
发明内容
本发明解决的技术问题在于提供一种数据存储与査询方法， 其中数据存储包 括对数据的创建和更新； 本方法在满足横向扩展特性同时， 支持类 SQL语法， 更适合敏捷开发模式。
本发明解决上述技术问题的技术方案是：
将数据抽象为一个二元组 (Key, MiniTable),任意 MiniTable (去除数据集合） 由唯一的 Key标识； MiniTable由若干数据行组成， 并且由预先定义的模式限制 数据行的结构， 行按模式定义的主键进行排序；
Key-MiniTable模式有三个基本原语和三个物理实体，三个物理实体分别为： 客户端， 利用三个基本原语向 Key服务器发起请求， 并接收请求结果；
Key服务器，接收客户端发起的请求，查找 Key对应 MiniTable所处 MiniTable 服务器的 IP地址及端口号， 据此转发该请求给对应 MiniTable服务器；
MiniTable服务器， 接收 Key服务器转发的请求， 解析该请求的类 SQL语 句， 生成执行计划， 并在分布式存储系统中获取和写入数据， 完成请求返回结 果给客户端。
Key-MiniTable模式的三个基本原语为：
1 ) Boolean Create (Key, 列名 1:数据类型，列名 2:数据类型， ......， 列名 n:数 据类型， PRIMARY KEY: 列名）， 创建一个标识为 Key的 MiniTable, 并定义该 MiniTable的模式； 若创建成功返回 True, 创建失败则返回 False;
2) Boolean Delete (Key),删除 Key对应的 MiniTable;若删除成功返回 True, 删除失败或不存在对应 Key则返回 False;
3) String Query (Key,类 SQL语句)， 在 Key对应的 MiniTable内部执行类
SQL语句， Query原语返回其参数中类 SQL语句的返回值； 类 SQL语句包括十 个保留字： Select Where, Inserts Update, Delete^ Order By、 Limit、 Distinct、 And 、 Or; 六个运算符： =、 >、 >=、 <=、 <、 o; 保留字与运算符的语法和语 义与 SQL标准定义相同。
每个 MiniTable的大小受限， 一般小于等于 64M, 便于将整个 MiniTable放 入 Hadoop分布式文件系统的一个数据块中； 两个不同 MiniTable之间不能做关 系数据库中的 join等表间操作，不需多个表进行联合加锁; Key不仅是 MiniTable 的身份标识， 也是 MiniTable在分布式存储系统中的存储位置标识。
MiniTable采用日志格式记录数据， 添加、 删除与修改数据均在文件末尾写 入日志； 在 MiniTable文件大小接近数据块最大容量时执行日志归并， 生成新的 曰志文件； Key服务器和 MiniTable服务器在做任何操作之前均将操作写入系统 日志文件， 在操作完成或失败时也将返回值写入系统日志文件。
Key服务器有三个核心数据结构：
1 ) B+树： 存储 Key与地址号之间的对应关系；
2) 地址转换表： 存储地址号与 IP地址和端口号之间的对应关系；
3 ) MiniTable服务器监控表： 存储每一个地址号对应 MiniTable服务器的负 载情况；
当 Key服务器收到一个原语请求时， 检查是否是合法 Query原语； 若是合 法 Query原语， 则从 B+树中査询 Key对应的地址号； 若 Key不存在， 则返回 Key不存在信息； 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和 端口号； 若 IP地址和端口号不存在， 则返回错误； 若存在， 则将该请求转发给 IP地址和端口号对应的 MiniTable服务器；
若请求不是合法 Queiy原语，则检査是否为合法 Create原语;若是合法 Create 原语， 则在 B+树中査询是否存在给定的 Key; 若 Key存在， 则返回 Key己存在
信息；若 Key不存在，则根据调度算法和 MiniTable服务器监控表分配一个地址 号， 更新 MiniTable服务器监控表， 利用地址号査询对应的 IP地址和端口号， 并转发请求给对应的 MiniTable服务器；
若请求不是合法 Create 原语， 则检査是否为合法 Delete原语； 若是合法 Delete原语， 则在 B+树中査询是否存在给定的 Key; 若 Key不存在， 返回 Key 不存在信息； 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和端口 号， 并删除 B+树中对应的 Key, 更新 MiniTable服务器监控表， 査询 IP地址和 端口号， 转发请求给对应的 MiniTable服务器。
MiniTable服务器有两个核心数据结构：
1 ) 内存表： 根据缓存策略， 将部分 MiniTable存储在内存中；
2) MiniTable锁： 记录已加锁的 MiniTable;
MiniTable服务器收到 Key服务器转发的请求后， 对请求做语义解析， 判断 请求操作的 MiniTable是否加锁； 若加锁则将该请求加入等待队列； 若未加锁， 则对 MiniTable加锁， 并生成执行计划； 之后， 判断 MiniTable是否在内存表中， 若在内存表中直接执行请求； 若不在内存表中， 则进一步判断是否有足够内存 空间； 若没有， 则根据调度策略， 将部分 MiniTable写入分布式文件系统； 写入 时比较 MiniTable内存版本与文件版本的区别，仅将更新的部分以日志压缩格式 写入；在获取足够内存空间后，从分布式文件系统读入 MiniTable文件，解压縮； 将 MiniTable 日志文件转换为数据格式存入内存表； 之后执行请求， 解锁 MiniTable, 并返回结果。
本发明可以构建一个数据管理系统， 支持对数据的存储（包括创建和更新） 与査询， 并且该系统满足如下两个重要性质。 1 )敏捷开发： 对 MiniTable内部 数据的操作支持类 SQL语法， 从而可以快速地实现复杂逻辑查询和复杂条件插 入。 2) 横向扩展： 通过 Key-MiniTable模式， 去除 MiniTable之间的依赖关系，
从而可以通过增加服务器数量， 拟线性地扩展系统的容量和吞吐量， 以支持亿 量级的 MiniTable和十万每秒量级的请求。
附图说明
下面结合附图对本发明进一步说明：
图 1是本发明 Key-MiniTable系统结构图；
图 2是 Key服务器执行流程图；
图 3是 MiniTable服务器执行流程图。
具体实施方式
见图 1所示， 是本发明中 Key-MiniTable系统结构图。 Key-MiniTable系统 建立在分布式文件系统之上， 例如 Hadoop分布式文件系统（HDFS)。存入分布 式文件系统的数据分为两部分：
1、 MiniTable日志文件： MiniTable存储在数据块中。 为了提高访问和缓存 性能， MiniTable的数据大小不超过数据块最大容量 （一般为 64M)。 为了提到 写入性能， MiniTable采用日志格式记录数据， 添加、 删除与修改数据均在文件 末尾写入日志。在 MiniTable文件大小接近数据块最大容量时执行日志归并， 生 成新的日志文件。
2、 系统日志文件： Key服务器和 MiniTable服务器在做任何操作之前均将 操作写入系统日志文件， 在操作完成或失败时也将返回值写入系统日志文件。 维护系统日志文件使系统发生故障时可以恢复到之前的正常状态。
当需要创建、 更新或删除数据时， 用户使用客户端向 Key服务器发起一个 原语请求。
Key服务器执行流程如图 2所示。 Key服务器有三个核心数据结构：
1、 B+树： 存储 Key与地址号之间的对应关系。
2、 地址转换表： 存储地址号与 IP地址和端口号之间的对应关系。
3、 MiniTable服务器监控表： 存储每一个地址号对应 MiniTable服务器的负 载情况。
当 Key服务器收到一个原语请求时， 检査是否是合法 Query原语。 若是合 法 Query原语， 则从 B+树中査询 Key对应的地址号。 若 Key不存在， 则返回 Key不存在信息。 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和 端口号。 若 IP地址和端口号不存在， 则返回错误。 若存在， 则将该请求转发给 IP地址和端口号对应的 MiniTable服务器。
若请求不是合法 Query原语,则检查是否为合法 Create原语。若是合法 Create 原语， 则在 B+树中查询是否存在给定的 Key。若 Key存在， 则返回 Key已存在 信息。若 Key不存在，则根据调度算法和 MiniTable服务器监控表分配一个地址 号， 更新 MiniTable服务器监控表， 利用地址号査询对应的 IP地址和端口号， 并转发请求给对应的 MiniTable服务器。
若请求不是合法 Create 原语， 则检査是否为合法 Delete原语。 若是合法 Delete原语， 则在 B+树中查询是否存在给定的 Key。 若 Key不存在， 返回 Key 不存在信息。 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和端口 号， 并删除 B+树中对应的 Key, 更新 MiniTable服务器监控表， 査询 IP地址和 端口号， 转发请求给对应的 MiniTable服务器。
见图 3所示， 是 MiniTable服务器执行流程图。
MiniTable服务器有两个核心数据结构：
1、 内存表： 根据缓存策略， 将部分 MiniTable存储在内存中。
2、 MiniTable锁： 记录已加锁的 MiniTable。
MiniTable服务器收到 Key服务器转发的请求后， 对请求做语义解析。判断 请求操作的 MiniTable是否加锁。 若加锁则将该请求加入等待队列。 若未加锁，
则对 MiniTable加锁， 并生成执行计划。之后， 判断 MiniTable是否在内存表中。 若在内存表中直接执行请求。 若不在内存表中， 则进一步判断是否有足够内存 空间。 若没有， 则根据调度策略， 将部分 MiniTable写入分布式文件系统。 写入 时比较 MiniTable内存版本与文件版本的区别，仅将更新的部分以日志压缩格式 写入。在获取足够内存空间后，从分布式文件系统读入 MiniTable文件，解压缩。 将 MiniTable 日志文件转换为数据格式存入内存表。 之后执行请求， 解锁 MiniTable, 并返回结果。 本发明利用去除数据集合之间依赖关系的方法获取系统的横向扩展能力， 同时保留数据集合内部数据之间的依赖关系以支持类 SQL语法， 从而获取敏捷 开发的特性。
Claims
1、 一种支持敏捷开发和横向扩展的数据存储与査询方法， 其特征在于： 将 数据抽象为一个二元组 (Key, MiniTable), 任意 MiniTable由唯一的 Key标识； MiniTable由若干数据行组成， 并且由预先定义的模式限制数据行的结构， 行按 模式定义的主键进行排序；
Key-MiniTable模式有三个基本原语和三个物理实体，三个物理实体分别为： 客户端， 利用三个基本原语向 Key服务器发起请求， 并接收请求结果；
Key服务器，接收客户端发起的请求，查找 Key对应 MiniTable所处 MiniTable 服务器的 IP地址及端口号， 据此转发该请求给对应 MiniTable服务器；
MiniTable服务器， 接收 Key服务器转发的请求， 解析该请求的类 SQL语 句， 生成执行计划， 并在分布式存储系统中获取和写入数据， 完成请求返回结 果给客户端。
2、根据权利要求 1所述的数据存储与査询方法，其特征在于: Key-MiniTable 模式的三个基本原语为：
1 ) Boolean Create (Key,列名 1:数据类型，列名 2:数据类型, ......，列名 n:数 据类型， PRIMARY KEY: 列名）， 创建一个标识为 Key的 MiniTable, 并定义该 MiniTable的模式； 若创建成功返回 True, 创建失败则返回 False;
2) Boolean Delete (Key),删除 Key对应的 MiniTable;若删除成功返回 True, 删除失败或不存在对应 Key则返回 False;
3 ) String Query (Key,类 SQL语句)， 在 Key对应的 MiniTable内部执行类 SQL语句， Query原语返回其参数中类 SQL语句的返回值； 类 SQL语句包括十 个保留字： Select、 Where > Insert、 Update, Delete > Order By> Limit、 Distinct、 And 、 Or; 六个运算符： =、 >、 >=、 <=、 <、 o; 保留字与运算符的语法和语 义与 SQL标准定义相同。
3、根据权利要求 1所述的数据存储与査询方法，其特征在于：每个 MiniTable 的大小受限， 一般小于等于 64M， 便于将整个 MiniTable放入 Hadoop分布式文 件系统的一个数据块中；两个不同 MiniTable之间不能做关系数据库中的 join等 表间操作， 不需多个表进行联合加锁； Key不仅是 MiniTable的身份标识， 也是 MiniTable在分布式存储系统中的存储位置标识。
4、根据权利要求 2所述的数据存储与査询方法，其特征在于:每个 MiniTable 的大小受限， 一般小于等于 64M， 便于将整个 MiniTable放入 Hadoop分布式文 件系统的一个数据块中；两个不同 MiniTable之间不能做关系数据库中的 join等 表间操作， 不需多个表进行联合加锁； Key不仅是 MiniTable的身份标识， 也是 MiniTable在分布式存储系统中的存储位置标识。
5、 根据权利要求 1至 4任一项所述的数据存储与査询方法， 其特征在于： MiniTable采用日志格式记录数据， 添加、 删除与修改数据均在文件末尾写入日 志； 在 MiniTable文件大小接近数据块最大容量时执行日志归并， 生成新的日志 文件； Key服务器和 MiniTable服务器在做任何操作之前均将操作写入系统日志 文件， 在操作完成或失败时也将返回值写入系统日志文件。
6、 根据权利要求 1至 4任一项所述的数据存储与查询方法， 其特征在于： Key服务器有三个核心数据结构：
1 ) B+树： 存储 Key与地址号之间的对应关系；
2) 地址转换表： 存储地址号与 IP地址和端口号之间的对应关系；
3 ) MiniTable服务器监控表： 存储每一个地址号对应 MiniTable服务器的负 载情况；
当 Key服务器收到一个原语请求时， 检査是否是合法 Query原语； 若是合 法 Query原语， 则从 B+树中査询 Key对应的地址号； 若 Key不存在， 则返回 Key不存在信息； 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和 端口号； 若 IP地址和端口号不存在， 则返回错误； 若存在， 则将该请求转发给 IP地址和端口号对应的 MiniTable服务器；
若请求不是合法 Query原语，则检査是否为合法 Create原语；若是合法 Create 原语， 则在 B+树中查询是否存在给定的 Key; 若 Key存在， 则返回 Key已存在 信息；若 Key不存在，则根据调度算法和 MiniTable服务器监控表分配一个地址 号， 更新 MiniTable服务器监控表， 利用地址号査询对应的 IP地址和端口号， 并转发请求给对应的 MiniTable服务器；
若请求不是合法 Create 原语， 则检查是否为合法 Delete原语； 若是合法 Delete原语， 则在 B+树中査询是否存在给定的 Key; 若 Key不存在， 返回 Key 不存在信息； 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和端口 号， 并删除 B+树中对应的 Key, 更新 MiniTable服务器监控表， 査询 IP地址和 端口号， 转发请求给对应的 MiniTable服务器。
7、 根据权利要求 5所述的数据存储与查询方法， 其特征在于： Key服务器 有三个核心数据结构：
1 ) B+树： 存储 Key与地址号之间的对应关系；
2) 地址转换表： 存储地址号与 IP地址和端口号之间的对应关系；
3 ) MiniTable服务器监控表： 存储每一个地址号对应 MiniTable服务器的负 载情况；
当 Key服务器收到一个原语请求时， 检査是否是合法 Query原语； 若是合 法 Query原语， 则从 B+树中査询 Key对应的地址号； 若 Key不存在， 则返回 Key不存在信息； 若 Key存在， 则在地址转换表中查询地址号对应的 IP地址和 端口号； 若 IP地址和端口号不存在， 则返回错误； 若存在， 则将该请求转发给 IP地址和端口号对应的 MiniTable服务器；
若请求不是合法 Query原语，则检査是否为合法 Create原语;若是合法 Create 原语， 则在 B+树中査询是否存在给定的 Key; 若 Key存在， 则返回 Key已存在 信息；若 Key不存在，则根据调度算法和 MiniTable服务器监控表分配一个地址 号， 更新 MiniTable服务器监控表， 利用地址号査询对应的 IP地址和端口号， 并转发请求给对应的 MiniTable服务器；
若请求不是合法 Create原语， 则检査是否为合法 Delete原语； 若是合法 Delete原语， 则在 B+树中查询是否存在给定的 Key; 若 Key不存在， 返回 Key 不存在信息； 若 Key存在， 则在地址转换表中査询地址号对应的 IP地址和端口 号， 并删除 B+树中对应的 Key, 更新 MiniTable服务器监控表， 査询 IP地址和 端口号， 转发请求给对应的 MiniTable服务器。
8、 根据权利要求 1至 4任一项所述的数据存储与查询方法， 其特征在于：
MiniTable服务器有两个核心数据结构-
1 ) 内存表： 根据缓存策略， 将部分 MiniTable存储在内存中；
2) MiniTable锁： 记录已加锁的 MiniTable;
MiniTable服务器收到 Key服务器转发的请求后， 对请求做语义解析， 判断 请求操作的 MiniTable是否加锁； 若加锁则将该请求加入等待队列； 若未加锁， 则对 MiniTable加锁， 并生成执行计划； 之后， 判断 MiniTable是否在内存表中， 若在内存表中直接执行请求； 若不在内存表中， 则进一步判断是否有足够内存 空间； 若没有， 则根据调度策略， 将部分 MiniTable写入分布式文件系统； 写入 时比较 MiniTable内存版本与文件版本的区别，仅将更新的部分以日志压缩格式 写入；在获取足够内存空间后，从分布式文件系统读入 MiniTable文件，解压缩； 将 MiniTable 日志文件转换为数据格式存入内存表； 之后执行请求， 解锁 MiniTable, 并返回结果。
9、 根据权利要求 5所述的数据存储与査询方法， 其特征在于： MiniTable服务器有两个核心数据结构：
1 ) 内存表： 根据缓存策略， 将部分 MiniTable存储在内存中；
2) MiniTable锁： 记录已加锁的 MiniTable;
MiniTable服务器收到 Key服务器转发的请求后， 对请求做语义解析， 判断 请求操作的 MiniTable是否加锁； 若加锁则将该请求加入等待队列； 若未加锁， 则对 MiniTable加锁， 并生成执行计划； 之后， 判断 MiniTable是否在内存表中， 若在内存表中直接执行请求； 若不在内存表中， 则进一步判断是否有足够内存 空间； 若没有， 则根据调度策略， 将部分 MiniTable写入分布式文件系统； 写入 时比较 MiniTable内存版本与文件版本的区别，仅将更新的部分以日志压縮格式 写入；在获取足够内存空间后，从分布式文件系统读入 MiniTable文件，解压缩; 将 MiniTable 日志文件转换为数据格式存入内存表； 之后执行请求， 解锁 MiniTable, 并返回结果。
10、 根据权利要求 6所述的数据存储与查询方法， 其特征在于：
MiniTable服务器有两个核心数据结构：
1 ) 内存表： 根据缓存策略， 将部分 MiniTable存储在内存中；
2) MiniTable锁： 记录已加锁的 MiniTable;
MiniTable服务器收到 Key服务器转发的请求后， 对请求做语义解析， 判断 请求操作的 MiniTable是否加锁； 若加锁则将该请求加入等待队列； 若未加锁， 则对 MiniTable加锁， 并生成执行计划； 之后， 判断 MiniTable是否在内存表中， 若在内存表中直接执行请求； 若不在内存表中， 则进一步判断是否有足够内存 空间； 若没有， 则根据调度策略， 将部分 MiniTable写入分布式文件系统； 写入 时比较 MiniTable内存版本与文件版本的区别，仅将更新的部分以日志压缩格式 写入；在获取足够内存空间后，从分布式文件系统读入 MiniTable文件，解压缩； 将 MiniTable 日志文件转换为数据格式存入内存表； 之后执行请求， 解锁 MiniTable, 并返回结果。
11、 根据权利要求 7所述的数据存储与査询方法， 其特征在于：
MiniTable服务器有两个核心数据结构：
1 ) 内存表： 根据缓存策略， 将部分 MiniTable存储在内存中；
2) MiniTable锁： 记录已加锁的 MiniTable;
MiniTable服务器收到 Key服务器转发的请求后， 对请求做语义解析， 判断 请求操作的 MiniTable是否加锁； 若加锁则将该请求加入等待队列； 若未加锁， 则对 MiniTable加锁， 并生成执行计划； 之后， 判断 MiniTable是否在内存表中， 若在内存表中直接执行请求； 若不在内存表中， 则进一步判断是否有足够内存 空间； 若没有， 则根据调度策略， 将部分 MiniTable写入分布式文件系统； 写入 时比较 MiniTable内存版本与文件版本的区别，仅将更新的部分以日志压縮格式 写入；在获取足够内存空间后，从分布式文件系统读入 MiniTable文件，解压缩； 将 MiniTable 日志文件转换为数据格式存入内存表； 之后执行请求， 解锁 MiniTable, 并返回结果。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/342,097 US9367585B2 (en) | 2012-03-20 | 2012-04-18 | Data storage and query method |
| EP20120871750 EP2706468A4 (en) | 2012-03-20 | 2012-04-18 | METHOD FOR STORING AND INTERROGATION OF DATA |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2012100733272A CN102663007B (zh) | 2012-03-20 | 2012-03-20 | 一种支持敏捷开发和横向扩展的数据存储与查询方法 |
| CN201210073327.2 | 2012-03-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2013138953A1 true WO2013138953A1 (zh) | 2013-09-26 |
Family
ID=46772498
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2012/000534 WO2013138953A1 (zh) | 2012-03-20 | 2012-04-18 | 数据存储与查询方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US9367585B2 (zh) |
| EP (1) | EP2706468A4 (zh) |
| CN (1) | CN102663007B (zh) |
| WO (1) | WO2013138953A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114706919A (zh) * | 2022-06-06 | 2022-07-05 | 南京安元科技有限公司 | 一种布式存储数据存储兼容方法及系统 |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150220590A1 (en) * | 2014-01-31 | 2015-08-06 | HGST Netherlands B.V. | Synthetic updates for file system information |
| CN104408159B (zh) * | 2014-12-04 | 2018-01-16 | 曙光信息产业(北京)有限公司 | 一种数据关联、加载、查询方法及装置 |
| US10067959B1 (en) * | 2014-12-19 | 2018-09-04 | Amazon Technologies, Inc. | Techniques for adapting data storage systems for peaky usage models |
| WO2017088180A1 (zh) * | 2015-11-27 | 2017-06-01 | 华为技术有限公司 | 向队列存储数据的方法、装置及设备 |
| US10394789B1 (en) | 2015-12-07 | 2019-08-27 | Amazon Technologies, Inc. | Techniques and systems for scalable request handling in data processing systems |
| CN108647283A (zh) * | 2018-05-04 | 2018-10-12 | 武汉灵动在线科技有限公司 | 一种游戏数据配置敏捷生成与解析方法 |
| US11941501B2 (en) | 2018-05-30 | 2024-03-26 | Samsung Electronics Co., Ltd. | Electronic apparatus and control method thereof |
| KR20190136891A (ko) * | 2018-05-30 | 2019-12-10 | 삼성전자주식회사 | 전자 장치 및 그 제어 방법 |
| CN109299057A (zh) * | 2018-10-09 | 2019-02-01 | 北京快友世纪科技股份有限公司 | Hadoop多管道数据处理分析方法 |
| CN110222045B (zh) * | 2019-04-23 | 2024-05-28 | 平安科技（深圳）有限公司 | 一种数据报表获取方法、装置及计算机设备、存储介质 |
| CN113193974B (zh) * | 2021-07-02 | 2021-11-09 | 深圳华云信息系统有限公司 | 基于组播的行情信息推送方法、系统、设备及介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04291458A (ja) * | 1990-12-07 | 1992-10-15 | Digital Equip Corp <Dec> | 関係型照会を使用して非関係型データファイルにアクセスする方法及び装置 |
| CN102375854A (zh) * | 2010-08-23 | 2012-03-14 | 杭州华三通信技术有限公司 | 一种对数据库进行数据处理的方法和装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1217544A1 (en) * | 2000-12-22 | 2002-06-26 | Dataevents Cyprus Limited | System for and method of storing and disseminating data |
| US20040230571A1 (en) * | 2003-04-22 | 2004-11-18 | Gavin Robertson | Index and query processor for data and information retrieval, integration and sharing from multiple disparate data sources |
| EP1510932A1 (en) * | 2003-08-27 | 2005-03-02 | Sap Ag | Computer implemented method and according computer program product for storing data sets in and retrieving data sets from a data storage system |
| CN100337218C (zh) * | 2005-02-23 | 2007-09-12 | 北京邦诺存储科技有限公司 | 网络存储系统中的数据管理方法及其构建的网络存储系统 |
| US8583652B2 (en) * | 2010-11-30 | 2013-11-12 | Oracle International Corporation | Efficiently registering a relational schema |
| TWM430057U (en) * | 2011-11-18 | 2012-05-21 | Speedtech Corp | Improve structure of the lift cover connector |
| US9471711B2 (en) * | 2013-09-23 | 2016-10-18 | Teradata Us, Inc. | Schema-less access to stored data |
-
2012
- 2012-03-20 CN CN2012100733272A patent/CN102663007B/zh active Active
- 2012-04-18 WO PCT/CN2012/000534 patent/WO2013138953A1/zh active Application Filing
- 2012-04-18 US US14/342,097 patent/US9367585B2/en active Active
- 2012-04-18 EP EP20120871750 patent/EP2706468A4/en not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04291458A (ja) * | 1990-12-07 | 1992-10-15 | Digital Equip Corp <Dec> | 関係型照会を使用して非関係型データファイルにアクセスする方法及び装置 |
| CN102375854A (zh) * | 2010-08-23 | 2012-03-14 | 杭州华三通信技术有限公司 | 一种对数据库进行数据处理的方法和装置 |
Non-Patent Citations (2)
| Title |
|---|
| LU, DONGHAI ET AL.: "The Analysis of NoSQL Database", SCIENCE AND TECHNOLOGY OF WEST CHINA, vol. 10, no. 2, January 2011 (2011-01-01), pages 14 - 16, XP008171452 * |
| See also references of EP2706468A4 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114706919A (zh) * | 2022-06-06 | 2022-07-05 | 南京安元科技有限公司 | 一种布式存储数据存储兼容方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2706468A4 (en) | 2015-04-29 |
| US20140222778A1 (en) | 2014-08-07 |
| EP2706468A1 (en) | 2014-03-12 |
| CN102663007A (zh) | 2012-09-12 |
| CN102663007B (zh) | 2013-12-18 |
| US9367585B2 (en) | 2016-06-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2013138953A1 (zh) | 数据存储与查询方法 | |
| JP6123339B2 (ja) | エンコードされたトリプルを格納するデータベース、装置及び方法 | |
| Pokorny | NoSQL databases: a step to database scalability in web environment | |
| US10089377B2 (en) | System and method for data transfer from JDBC to a data warehouse layer in a massively parallel or distributed database environment | |
| US10885031B2 (en) | Parallelizing SQL user defined transformation functions | |
| US10417257B2 (en) | Non-blocking database table alteration | |
| WO2021184761A1 (zh) | 数据访问方法和装置、数据存储方法和装置 | |
| Bansel et al. | Cloud-based NoSQL data migration | |
| Borkar et al. | Have your data and query it too: From key-value caching to big data management | |
| US10642841B2 (en) | Document store utilizing partial object compression | |
| Romero et al. | Tuning small analytics on Big Data: Data partitioning and secondary indexes in the Hadoop ecosystem | |
| Özsu et al. | Distributed and Parallel Database Systems. | |
| US9836513B2 (en) | Page feed for efficient dataflow between distributed query engines | |
| Mittal et al. | Efficient random data accessing in MapReduce | |
| Ho et al. | Data partition optimization for column-family NoSQL databases | |
| US11256695B1 (en) | Hybrid query execution engine using transaction and analytical engines | |
| Xu et al. | Sparkrdf: In-memory distributed rdf management framework for large-scale social data | |
| Zhao et al. | A multidimensional OLAP engine implementation in key-value database systems | |
| Hsieh et al. | Data partition optimisation for column-family nosql databases | |
| Gowraj et al. | S2mart: smart sql to map-reduce translators | |
| Yu et al. | MPDBS: A multi-level parallel database system based on B-Tree | |
| Le et al. | Cloud Database | |
| Pirzadeh | On the performance evaluation of big data systems | |
| Trucksäß | Evaluation of Distributed Semantic Databases | |
| Batra et al. | Modeling sparse and evolving data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12871750 Country of ref document: EP Kind code of ref document: A1 |
|
| REEP | Request for entry into the european phase |
Ref document number: 2012871750 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2012871750 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 14342097 Country of ref document: US |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |