CN101763390A - 基于Berkeley DB的数据库存储系统及方法 - Google Patents
基于Berkeley DB的数据库存储系统及方法 Download PDFInfo
- Publication number
- CN101763390A CN101763390A CN200810241555A CN200810241555A CN101763390A CN 101763390 A CN101763390 A CN 101763390A CN 200810241555 A CN200810241555 A CN 200810241555A CN 200810241555 A CN200810241555 A CN 200810241555A CN 101763390 A CN101763390 A CN 101763390A
- Authority
- CN
- China
- Prior art keywords
- data
- database
- server
- local
- storage 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000013500 data storage Methods 0.000 claims description 8
- 238000013523 data management Methods 0.000 claims description 5
- 230000006854 communication Effects 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于Berkeley DB的数据库存储系统及数据库存储方法，系统采用分布式架构，每个服务器上维护本地数据；本服务器在接到数据请求后，先查找本地数据库；如果本地数据库中不存在，再计算出存储该数据的其他服务器，并把该数据缓存至本服务器的本地数据库中。相较之现有技术的关系型数据库，本发明在处理本地数据的时候不需要建立TCP连接，提高了数据库的存储效率，大大降低了系统的开销，大幅度的提高服务器的性能。
Description
【技术领域】
本发明涉及数据处理领域，特别涉及其中的数据库存储系统及数据访问方法。
【背景技术】
在计算机服务器端，经常存在着多个进程和线程同时访问一个数据库的问题。现有技术中存在的数据库主要有：
文件型数据库：文件型数据库是早期使用的数据库形式，现在不少简单的应用服务器系统也是适用这种数据库来管理数据。该方法的最大缺点就是不能实现数据的并发操作，一般一个对一个数据文件进行操作时，整个文件都是一个冲突域，即：在其他进程或者线程使用该数据库时，其他程序必须阻塞，等待其处理完成后，才能继续访问数据库。因此，所有数据的访问与线性访问数据的时间基本相同，是一种性能很低的解决方案，另外，文件型数据库由于没有自身的索引信息，所以查找和处理数据都非常困难，很难实现分布式的系统架构。但由于其本身比较简单，在现实中有不少的应用。
关系型数据库：关系型数据库是现在很多网站、公司内部系统使用的数据库解决方案，其中包括：MySQL、SQL Server、Oracle等，可以说该方案是现有数据库的主流解决方案，其最大的优点就是使用简单，支持标准SQL，然而由于它支持标准SQL的需求，因此其具有以下缺点：
主流的关系型数据库都是连接型数据库，即：在每次客户发出数据请求的时候，客户端和数据库之间首先建立一条TCP连接，然后使用这条连接进行数据的交互，即使应用程序和数据库在同一台机器上时，也必须建立连接。因此，服务器的很多处理都浪费在了处理连接的内容上，由此也降低了数据库的存储效率。而且传统的Select/Poll方式处理连接，处理的时间复杂度和连接数是平方的关系，所以，随着数据库处理的请求增多，处理的能力以平方的速度下降。
主流的关系型数据库支持标准SQL，因此数据库必须对每一个字段建立索引信息，而在实际的应用程序中，大多数的字段索引是没有用的。因此数据库存储了很多额外的信息，同时这些数据的存在也降低了数据库的效率。
【发明内容】
本发明的主要目的是：提供一种实现高效访问的数据库存储的解决方案。
为实现上述目的，本发明提出一种基于Berkeley DB的数据库存储系统，采用分布式架构，每个服务器上维护本地数据；本服务器在接到数据访问的请求后，先查找本地数据库；如果本地数据库中不存在，再计算出存储该数据的其他服务器，并把该数据缓存至本服务器的本地数据库中。
同时，本发明提出了一种基于Berkeley DB的数据库存储方法，每个服务器上维护本地数据；本服务器在接到数据访问的请求后，先查找本地数据库；如果本地数据库中不存在，再计算出存储该数据的其他服务器，并把该数据缓存至本服务器的本地数据库中。
上述的数据库存储系统或数据库存储方法，每个服务器的本地数据库包括本服务器需要维护的本机的用户数据存储区、用作缓存其他服务器数据的缓存数据存储区。
上述的数据库存储系统或数据库存储方法，在本地数据库中采用页级锁进行数据管理。在本地数据库中采用页级锁进行数据管理时，其中的磁盘页的大小根据整个系统存储总的用户数和处理用户请求的总的线程数，进行设定。可选方案之一，所述磁盘页的大小为每个页存储10个数据。
上述的数据库存储系统或数据库存储方法，在本服务器和其他服务器通信过程中，采用Epoll处理连接。
上述的数据库存储系统或数据库存储方法，根据散列算法计算出存储该数据的服务器。通过基于Berkeley DB的应用程序编程接口，提供所述数据访问的统一接口。
相较之现有技术的关系型数据库，本发明在处理本地数据的时候不需要建立TCP连接，提高了数据库的存储效率，大大降低了系统的开销，大幅度的提高服务器的性能。
对于用户多台服务器在逻辑上可以当成一台服务器透明地使用，用户可以就近连接服务器，解决网络生存周期过高的问题；
同时，在对底层数据的访问上采用对页加锁的技术，提高磁盘I/O的效率。
本发明中，应用Berkeley DB提供的一些功能，可以对存储系统的底层实现灵活配置，比如数据页的大小、内存缓存的大小、底层存储数据结构等。整个存储系统既支持单线程访问，又支持多线程访问。
【附图说明】
图1本发明实施例的具有两个节点的数据库存储系统的系统结构图；
图2是本发明实施例的分布式节点的架构图；
图3是本发明实施例的系统模块图。
【具体实施方式】
下面通过具体的实施例并结合附图对本发明作进一步详细的描述。
实施例一：
请结合图1和图2所示的系统结构图，为了提高系统的服务性能，本例的数据库存储系统，采用分布式架构，每个服务器上维护自己的数据；本地数据库分两部分：1.本服务器需要维护的本机用户数据，存储于本地数据库的用户数据存储区中；2.用作缓存其他服务器的数据，缓存于本地数据库的缓存数据存储区中。在接到数据请求后，先查找本地数据库，如果本地数据库中不存在，再根据散列算法计算出存储该数据的服务器，并把这个数据缓存在本地数据库中。在这个基础上，用户可以就近连接服务器，解决网络生存周期TTL(Time to Live)过高的问题。为提高访问本地文件的并发度，使用Berkeley DB页级锁；为提高处理TCP连接的速度，采用Linux 2.6内核的Epoll技术。
在本地数据库中，采用Berkeley DB的页级锁的策略进行数据管理，磁盘页的大小(即加锁的粒度)可以自行设定的，以增强系统的可配置性。对数据大小进行计算，计算页大小的方法是：获得整个系统存储总的用户数和处理用户请求的总的线程数，用系统用户数除以线程数，再除以一个经验数据，该数据可以随时调整，由于对每页都是加锁的，所以这个经验数据仅会影响系统的性能，而不会出错。本例中，经测试采用每个页存储10个数据，这样碰撞的概率比较低，此时，多个进程或者线程在这样的页面配置下基本不会发生碰撞，达到了读写数据库的并行性。
在本服务器和其他服务器通信过程中，采用Epoll处理连接，因此处理连接的速度比现有的关系型数据库速度要快。
请参考图3所示的系统模块图，MyDb构造函数：MyDb(string dbname，int env_flag，int dataStruct)；
dbname：要打开的数据库名称；
env_flag：数据库环境配置的参数；
dataStruct：数据库存储底层数据所采用的格式；
MyTable构造函数；MyTable(string tbname，int db_flag，int pagesize)；
tbname：要打开的表的名称；
db_flag：配置数据库表的参数；
pagesize：存储该数据结构所采用的页的大小。
在构造好MyDb和MyTable的指针后，可以使用图2提供的应用程序编程接口API访问数据。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。
Claims (10)
1.一种基于Berkeley DB的数据库存储系统，采用分布式架构，每个服务器上维护本地数据；本服务器在接到数据访问的请求后，先查找本地数据库；如果本地数据库中不存在，再计算出存储该数据的其他服务器，并把该数据缓存至本服务器的本地数据库中。
2.如权利要求1所述的数据库存储系统，其特征是：每个服务器的本地数据库包括本服务器需要维护的本机的用户数据存储区、用作缓存其他服务器数据的缓存数据存储区。
3.如权利要求2所述的数据库存储系统，其特征是：在本地数据库中采用页级锁进行数据管理。
4.如权利要求2所述的数据库存储系统，其特征是：在本服务器和其他服务器通信过程中，采用Epoll处理连接。
5.如权利要求2所述的数据库存储系统，其特征是：根据散列算法计算出存储该数据的服务器。
6.如权利要求2所述的数据库存储系统，其特征是：通过基于Berkeley DB的应用程序编程接口，提供所述数据访问的统一接口。
7.如权利要求3所述的数据库存储系统，其特征是：在本地数据库中采用页级锁进行数据管理时，其中的磁盘页的大小根据整个系统存储总的用户数和处理用户请求的总的线程数，进行设定。
8.如权利要求7所述的数据库存储系统，其特征是：所述磁盘页的大小为每个页存储10个数据。
9.一种基于Berkeley DB的数据库存储方法，每个服务器上维护本地数据；本服务器在接到数据访问的请求后，先查找本地数据库；如果本地数据库中不存在，再计算出存储该数据的其他服务器，并把该数据缓存至本服务器的本地数据库中。
10.如权利要求9所述的数据库存储方法，其特征是：每个服务器的本地数据库包括本服务器需要维护的本机的用户数据存储区、用作缓存其他服务器数据的缓存数据存储区。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810241555A CN101763390A (zh) | 2008-12-24 | 2008-12-24 | 基于Berkeley DB的数据库存储系统及方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810241555A CN101763390A (zh) | 2008-12-24 | 2008-12-24 | 基于Berkeley DB的数据库存储系统及方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101763390A true CN101763390A (zh) | 2010-06-30 |
Family
ID=42494554
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200810241555A Pending CN101763390A (zh) | 2008-12-24 | 2008-12-24 | 基于Berkeley DB的数据库存储系统及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101763390A (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102937997A (zh) * | 2012-11-26 | 2013-02-20 | 曙光信息产业(北京)有限公司 | 数据处理系统 |
| CN103188307A (zh) * | 2011-12-30 | 2013-07-03 | 旭智科技(深圳）有限公司 | 新型云应用方法及系统 |
| CN104731785A (zh) * | 2013-12-18 | 2015-06-24 | 中国移动通信集团上海有限公司 | 一种信息查询方法及装置 |
| CN106126536A (zh) * | 2016-06-15 | 2016-11-16 | 北京皮尔布莱尼软件有限公司 | 一种数据缓存的自动选择方法及系统 |
| CN106547898A (zh) * | 2016-10-27 | 2017-03-29 | 北京锐安科技有限公司 | 一种分布式数据库的数据处理方法及装置 |
| CN108363806A (zh) * | 2018-03-01 | 2018-08-03 | 上海达梦数据库有限公司 | 数据库的多版本并发控制方法、装置、服务器及存储介质 |
| CN110704388A (zh) * | 2018-07-10 | 2020-01-17 | 南京航空航天大学 | 基于BerkeleyDB存储管理的SETI索引实现技术 |
| CN113392126A (zh) * | 2021-08-17 | 2021-09-14 | 北京易鲸捷信息技术有限公司 | 基于分布式数据库的执行计划缓存及读取方法 |
-
2008
- 2008-12-24 CN CN200810241555A patent/CN101763390A/zh active Pending
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103188307A (zh) * | 2011-12-30 | 2013-07-03 | 旭智科技(深圳）有限公司 | 新型云应用方法及系统 |
| CN102937997A (zh) * | 2012-11-26 | 2013-02-20 | 曙光信息产业(北京)有限公司 | 数据处理系统 |
| CN104731785A (zh) * | 2013-12-18 | 2015-06-24 | 中国移动通信集团上海有限公司 | 一种信息查询方法及装置 |
| CN106126536A (zh) * | 2016-06-15 | 2016-11-16 | 北京皮尔布莱尼软件有限公司 | 一种数据缓存的自动选择方法及系统 |
| CN106547898A (zh) * | 2016-10-27 | 2017-03-29 | 北京锐安科技有限公司 | 一种分布式数据库的数据处理方法及装置 |
| CN108363806A (zh) * | 2018-03-01 | 2018-08-03 | 上海达梦数据库有限公司 | 数据库的多版本并发控制方法、装置、服务器及存储介质 |
| CN108363806B (zh) * | 2018-03-01 | 2020-07-31 | 上海达梦数据库有限公司 | 数据库的多版本并发控制方法、装置、服务器及存储介质 |
| CN110704388A (zh) * | 2018-07-10 | 2020-01-17 | 南京航空航天大学 | 基于BerkeleyDB存储管理的SETI索引实现技术 |
| CN113392126A (zh) * | 2021-08-17 | 2021-09-14 | 北京易鲸捷信息技术有限公司 | 基于分布式数据库的执行计划缓存及读取方法 |
| CN113392126B (zh) * | 2021-08-17 | 2021-11-02 | 北京易鲸捷信息技术有限公司 | 基于分布式数据库的执行计划缓存及读取方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Liao et al. | Multi-dimensional index on hadoop distributed file system | |
| US10275489B1 (en) | Binary encoding-based optimizations at datastore accelerators | |
| CN103020315B (zh) | 一种基于主从分布式文件系统的海量小文件存储方法 | |
| US11561930B2 (en) | Independent evictions from datastore accelerator fleet nodes | |
| US9251003B1 (en) | Database cache survivability across database failures | |
| CN110262754B (zh) | 一种面向NVMe和RDMA的分布式存储系统及轻量级同步通信方法 | |
| CN101763390A (zh) | 基于Berkeley DB的数据库存储系统及方法 | |
| CN106599199A (zh) | 一种数据缓存与同步方法 | |
| US20120072656A1 (en) | Multi-tier caching | |
| WO2013155751A1 (zh) | 面向并发olap的数据库查询处理方法 | |
| US10417257B2 (en) | Non-blocking database table alteration | |
| US20120290595A1 (en) | Super-records | |
| CN105183839A (zh) | 一种基于Hadoop的小文件分级索引的存储优化方法 | |
| US10146833B1 (en) | Write-back techniques at datastore accelerators | |
| CN103176754A (zh) | 一种海量小文件读取存储方法 | |
| CN110413612A (zh) | 一种基于混合索引的混合内存性能优化方法及系统 | |
| CN103942301B (zh) | 一种面向多数据类型访问应用的分布式文件系统 | |
| US20220391394A1 (en) | Caching for disk based hybrid transactional analytical processing system | |
| CN103595799A (zh) | 一种实现分布式共享数据库的方法 | |
| CN107066505A (zh) | 一种性能优化的小文件存储访问的系统及方法 | |
| US20220382758A1 (en) | Query processing for disk based hybrid transactional analytical processing system | |
| US11586353B2 (en) | Optimized access to high-speed storage device | |
| Duan et al. | Gengar: an RDMA-based distributed hybrid memory pool | |
| Zhao et al. | LS-AMS: An adaptive indexing structure for realtime search on microblogs | |
| CN105930519A (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 |
Application publication date: 20100630 |