CN101458707A - 一种大数据量记录的存储方法 - Google Patents
一种大数据量记录的存储方法 Download PDFInfo
- Publication number
- CN101458707A CN101458707A CNA2008102274091A CN200810227409A CN101458707A CN 101458707 A CN101458707 A CN 101458707A CN A2008102274091 A CNA2008102274091 A CN A2008102274091A CN 200810227409 A CN200810227409 A CN 200810227409A CN 101458707 A CN101458707 A CN 101458707A
- Authority
- CN
- China
- Prior art keywords
- data
- key
- record
- value
- hash
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种大数据量记录的存储方法，将每个关键字对应的最后一条记录的地址存储在Hash桶；记录当前文件的长度为key_off1；采用Hash函数计算待存储记录中KEY数据的关键字；根据关键字检索Hash桶，获得关键字的最后一条记录的地址key_off2；将待存储记录中的KEY数据信息、VALUE数据信息、最后一条记录的地址key_off2构造成一个数据块，添加到当前文件的尾部；更新关键字对应的Hash桶的值为key_off1。采用了本发明的技术方案，在处理简单的、大数据量的记录存储和访问时，能够保持稳定的高速度存储数据。
Description
技术领域
本发明涉及计算机技术领域，尤其涉及一种大数据量记录的存储方法。
背景技术
在设计UNIX/LINUX平台下的应用软件时，如果数据种类繁多，数据与数据之间关系比较复杂，就会选用一些大型的企业级数据库系统，如DB2，ORACLE、SYBASE等，如果软件规模不大，就倾向选用如MYSQL、POSTGRESQL等中小型数据库。但是在企业级应用开发中，如果涉及到重要的数据存储，一般都会选择更为严格的企业级数据库系统，MYSQL、POSTGRESQL一般都不予考虑。
企业级的数据库系统在提供了丰富的关系型数据库功能的同时，必然在数据操作和访问的性能方面带来一些损耗。一般来说，企业级关系型数据库一般都是通过Client-Server的方式提交SQL语句来操作数据。在这个过程中，SQL语句解析的消耗和通讯的开销对性能的影响不可小视。
当应用软件管理的数据类型较少，不需要Client-Server访问数据，并且查询条件单一、对数据操作要求高效率时，业界常用的是Berkeley DB，Berkeley DB中的每一个记录由数据标识和数据实体(即KEY数据/VALUE数据)构成。数据可以是简单的数据类型，也可以是复杂的数据类型，例如C语言中结构。Berkeley DB提供了一系列应用程序接口(API)来操作数据，应用程序和DB所提供的库在一起编译成为可执行程序。这种方式从两方面极大提高了效率。第一，DB库和应用程序运行在同一个地址空间，没有客户端程序和数据库服务器之间昂贵的网络通讯开销，也没有本地主机进程之间的通讯；第二，不需要对SQL代码解码，对数据的访问直截了当。
虽然Berkeley DB能够方便的存储数据，但是随着数据量的加大，其索引的构建过程会随着数据量的加大而越来越慢，从而影响到数据添加的速度。当数据量达到一定程度的情况下，数据添加的速度根本无法满足生产的要求。
发明内容
本发明的目的在于提出一种大数据量记录的存储方法，在处理简单的、大数据量的记录存储和访问时，能够保持稳定地高速度存储数据。
为达此目的，本发明采用以下技术方案：
一种大数据量记录的存储方法，包括以下步骤：
A、将每个关键字对应的最后一条记录的地址存储在Hash桶；
B、记录当前文件的长度为key_off1；
C、采用Hash函数计算待存储记录中KEY数据的关键字；
D、根据所述关键字检索Hash桶，获得所述关键字的最后一条记录的地址key_off2；
E、将所述待存储记录中的KEY数据信息、VALUE数据信息、所述最后一条记录的地址key_off2构造成一个数据块，添加到所述当前文件的尾部；
F、更新所述关键字对应的Hash桶的值为key_off1。
步骤E中，所述KEY数据信息包括所述KEY数据长度、所述KEY数据内容。
步骤E中，所述VALUE数据信息包括所述VALUE数据长度、所述VALUE数据内容。
步骤E中，所述数据块还包括记录类型。
所述Hash桶的值通过MMAP映射到内存。
采用了本发明的技术方案，这种新的索引构建方式使得无论数据量多大，数据库每次添加记录的开销从理论上来说是一致的，从而能够保证数据在存储的过程中，既构建索引，又能始终保持稳定的高速度。
附图说明
图1是本发明具体实施方式中数据库添加记录的流程图。
具体实施方式
下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。
在生产环境下，经常会有大数据量的记录需要存储，并且需要以某个简单的条件进行快速查询，所以对记录的某个部分需要建立索引，为此，设计了一个基于Hash索引的存储方案，下称Hulk DB。
Hulk DB主要适应于简单、大数据量的记录存储和访问。Hulk DB对需要管理的记录看法很简单。数据库包含若干条记录，每一个记录由数据标识和数据实体(即KEY数据/VALUE数据)构成。数据可以是简单的数据类型，也可以是复杂的数据类型，例如C语言中的结构。Hulk DB对数据类型不做任何解释，完全由程序员自行处理。同时，由于Hulk DB不提供SQL查询，应用于对数据存储和访问性能要求比较高，查询相对简单的场合。
Hulk DB采用Hash算法来构建索引。众所周之，在构造Hash函数时，要尽量使函数值分布均匀以减少冲突的发生，但是事实上冲突是不可避免的，所以在构造Hash函数的同时，必须考虑处理冲突的方法。
Hulk DB采用链地址法来处理冲突，即将所有关键字相同的记录链接成一条反向的单向线性链表，每个数据块中保留的是相同关键字的上一个数据块的地址，并把链尾的地址放在Hash桶里面。这种解决冲突的方法，充分考虑到了在磁盘上存储数据的特点，有效地降低了磁盘操作的数量。同时，这种方式使得添加数据的IO操作是固定的，不会因为数据量的增加而增加IO操作，从而影响效率。
Hulk DB把存放记录的地方叫做数据块，每一个数据块存放一条记录，每条记录都由一个KEY数据和一个VALUE数据组成。KEY数据和VALUE数据可以是简单的数据类型，也可以是复杂的数据类型，例如C语言中结构。Hulk DB对数据类型不做任何解释，完全由程序员自行处理。
数据块结构如表1所示：
表1
| 字段名称 | 数据类型 | 长度(byte) | 说明 |
| key_len | int | 4 | KEY数据的长度 |
| val_len | int | 4 | VALUE数据的长度 |
| data_tag | int | 4 | 记录类型，1表不有效数据，0表不已经删除的数据 |
| prev_off | off_t | 8 | Hash后的关键字相同的上一条记录的地址 |
| key | void | 变长 | KEY数据，是一个变长的空间，数据类型不定，长度由key_len决定 |
| value | void | 变长 | VALUE数据，是一个变长的空间，数据类型不定，长度由val_len决定 |
Hulk DB采用单个文件来存储数据，在实际生成中，可以按照特定的条件(如日期等)对数据进行多文件存储，这个过程由应用决定。数据文件分三个部分：
1、文件头(Header)，文件头记录了该数据文件使用的Hash桶的大小；
2、Hash桶，以数组方式存在，记录了数据块链尾数据的地址；
3、数据块，顺序存储，在文件尾追加记录。
下面具体介绍如何添加记录。图1是本发明具体实施方式中数据库添加记录的流程图。如图1所示，数据块添加记录的流程包括以下步骤：
步骤101、将每个关键字对应的最后一条记录的地址存储在Hash桶；
步骤102、记录当前文件的长度为key_off1；
步骤103、采用Hash函数计算待存储记录中KEY数据的关键字；
步骤104、根据待存储记录中KEY数据的关键字去检索Hash桶，获得该关键字的最后一条记录的地址key_off2；
步骤105、将待存储记录中的KEY数据长度和数据内容信息、VALUE数据长度和数据内容信息、记录类型和最后一条记录的地址key_off2构造成一个数据块，添加到当前文件的尾部；
步骤106、将该关键字对应的Hash桶的值更新为key_off1。
Hulk DB在处理Hash桶的过程中，使用了MMAP文件映射内存的技术，即将Hash桶的值全部用MMAP技术映射到内存。这是因为，首先Hash桶相对而言不是很大，8个字节一个单元，一个100万容量的Hash桶只占用不到8M的空间；其次通过MMAP之后减少了IO的操作，提高了数据操作的性能。
从上面的流程分析，如果不使用MMAP文件映射内存，共需要7个或者4个IO操作：
1、步骤102中需要一个lseek或者是stat得到文件的长度；
2、步骤104需要用一个lseek加一个read得到key_off2，或者用一个pread得到；
3、步骤105中需要一个write操作将文件添加到文件尾；
4、步骤106需要一个lseek加一个write更新Hash桶，或者用一个pwrite把Hash桶映射内存后，步骤103、步骤106中的操作全部用指针操作完成，最终文件的同步由操作系统来完成。
到这里，可以很清楚地看到，一个添加记录的调用，应用层的IO操作只有两个，而且固定是两个，不会因为数据量加大而发生变化。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉该技术的人在本发明所揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。
Claims (5)
1、一种大数据量记录的存储方法，其特征在于，包括以下步骤：
A、将每个关键字对应的最后一条记录的地址存储在Hash桶；
B、记录当前文件的长度为key_off1；
C、采用Hash函数计算待存储记录中KEY数据的关键字；
D、根据所述关键字检索Hash桶，获得所述关键字的最后一条记录的地址key_off2；
E、将所述待存储记录中的KEY数据信息、VALUE数据信息、所述最后一条记录的地址key_off2构造成一个数据块，添加到所述当前文件的尾部；
F、更新所述关键字对应的Hash桶的值为key_off1。
2、根据权利要求1所述的一种大数据量记录的存储方法，其特征在于，步骤E中，所述KEY数据信息包括所述KEY数据长度、所述KEY数据内容。
3、根据权利要求1所述的一种大数据量记录的存储方法，其特征在于，步骤E中，所述VALUE数据信息包括所述VALUE数据长度、所述VALUE数据内容。
4、根据权利要求1所述的一种大数据量记录的存储方法，其特征在于，步骤E中，所述数据块还包括记录类型。
5、根据权利要求1所述的一种大数据量记录的存储方法，其特征在于，所述Hash桶的值通过MMAP映射到内存。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008102274091A CN101458707A (zh) | 2008-11-26 | 2008-11-26 | 一种大数据量记录的存储方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008102274091A CN101458707A (zh) | 2008-11-26 | 2008-11-26 | 一种大数据量记录的存储方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101458707A true CN101458707A (zh) | 2009-06-17 |
Family
ID=40769563
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2008102274091A Pending CN101458707A (zh) | 2008-11-26 | 2008-11-26 | 一种大数据量记录的存储方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101458707A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104615750A (zh) * | 2015-02-12 | 2015-05-13 | 中国农业银行股份有限公司 | 一种主机系统下的内存数据库的实现方法 |
| CN109902071A (zh) * | 2019-01-31 | 2019-06-18 | 阿里巴巴集团控股有限公司 | 业务日志存储方法、系统、装置及设备 |
-
2008
- 2008-11-26 CN CNA2008102274091A patent/CN101458707A/zh active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104615750A (zh) * | 2015-02-12 | 2015-05-13 | 中国农业银行股份有限公司 | 一种主机系统下的内存数据库的实现方法 |
| CN104615750B (zh) * | 2015-02-12 | 2017-11-03 | 中国农业银行股份有限公司 | 一种主机系统下的内存数据库的实现方法 |
| CN109902071A (zh) * | 2019-01-31 | 2019-06-18 | 阿里巴巴集团控股有限公司 | 业务日志存储方法、系统、装置及设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11468027B2 (en) | Method and apparatus for providing efficient indexing and computer program included in computer readable medium therefor | |
| CA2777425C (en) | Method for performing transactions on data and a transactional database | |
| CN101499094B (zh) | 一种数据压缩存储并检索的方法及系统 | |
| US8051045B2 (en) | Archive indexing engine | |
| US8738572B2 (en) | System and method for storing data streams in a distributed environment | |
| US8959075B2 (en) | Systems for storing data streams in a distributed environment | |
| CN103023982B (zh) | 一种云存储客户端的低延迟元数据访问方法 | |
| US8719254B2 (en) | Efficient querying using on-demand indexing of monitoring tables | |
| US20070124277A1 (en) | Index and Method for Extending and Querying Index | |
| US11321315B2 (en) | Methods and systems for database optimization | |
| JP2014197425A (ja) | 個別にアクセス可能なデータユニットの記憶の取り扱い方法 | |
| EP2663939A2 (en) | Systems and methods for high-speed searching and filtering of large datasets | |
| CN110096509A (zh) | 大数据环境下实现历史数据拉链表存储建模处理的系统及方法 | |
| CN116257523A (zh) | 一种基于非易失存储器的列式存储索引方法及装置 | |
| CN101458707A (zh) | 一种大数据量记录的存储方法 | |
| US8005844B2 (en) | On-line organization of data sets | |
| CN102597969A (zh) | 带属性的键值存储的数据库管理装置及其键值存储结构的高速缓存装置 | |
| EP3436988B1 (en) | "methods and systems for database optimisation" | |
| CN104834664A (zh) | 面向光盘库的全文检索系统 | |
| CN104572711A (zh) | 一种分布式文档形数据存取方法及装置 | |
| CN113688130B (zh) | 一种内存数据库存储引擎管理方法 | |
| CN112988668B (zh) | 基于PostgreSQL的流式文档处理方法、装置以及装置的应用方法 | |
| JP5226445B2 (ja) | データベースに対する問合せを処理する装置、処理方法、プログラムおよび記録媒体 | |
| CN117149775A (zh) | 拉链表的数据处理方法和装置 | |
| CN103810209A (zh) | 一种保存数据的方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Open date: 20090617 |