内存数据库系统

2024-09-26

内存数据库系统（精选9篇）

内存数据库系统篇1

摘要：如何及时有效的恢复,使故障对数据库性能的影响降低到最小限度,显得至关重要。重点对内存数据库的系统故障进行探讨,并给出相关内容及解决处理方法。

关键词：内存数据库,故障,恢复技术

内存数据库运行在内存环境中,更易受到软件错误、系统崩溃、系统掉电等因素影响,致使系统出现故障而不能继续运行。在内存数据库出现故障后,如何及时有效的恢复,使故障对数据库性能的影响降低到最小限度,显得至关重要。内存数据库的故障类型包括事务、系统和介质等三种,文章重点对系统故障进行探讨,给出相关内容及解决处理方法。

1系统故障的概念

系统故障是指在运行的过程中,由于某种事件迫使系统停止运转并经重新启动才能正常运转,掉电和软件错误就属于两类典型的系统故障。内存数据库主版本存储在内存中,掉电后内存中的内容全部消失,而常见的软件错误可能覆盖主存的一部分,它们都能使系统出现故障停止运行。系统故障发生后,有些已提交事务对数据库的更新还没有写入到外存数据库。这时,作为恢复处理中最重要的一环,重装数据库以及重装过程中的恢复能将数据库有效地“还原”到某一种一致性状态。完全可以来说,系统故障一旦发生,只需将外存数据库载入到内存,而后对undo起始点后的日志进行undo操作就可以将数据库恢复到离故障点最近的一致性状态。总的来说,系统故障恢复的关键点是重载外存数据库到内存中及利用日志工具恢复,那么如何有效的重载入外存数据库和快速高效的日志恢复便成为解决问题的重点。

2重载恢复

重载指系统出现故障之后,重新启动,在此过程中,恢复管理器根据日志和外存数据库的信息先将未超截止期的活动事务所需的数据装入内存,若没有超过重装阈值,则将等待事务所需的数据装入,直到重装阈值。内存数据库的故障恢复时, 在不(或尽量少)影响实时事务的定时限制满足的情况下,优先载入优先级最高的事务和下一个要访问的数据,紧接着将需要紧迫执行的事务启动,此过程中选择数据逐步载入到内存时要按照某种策略进行。内存数据库载入策略的好坏直接影响主动实时数据库系统的性能,一旦采取的策略不当,最先载入的数据将闲置一段时间,而紧迫要运行的事务的数据却未被载入内存中,这样一来这些无用和有用数据将频繁循环交换。这对时间有严格要求的实时事务来说,将是一种灾难。

2.1重载算法概述

并发重载算法较为典型的有频率装载(FR)、智能装载(SR)和顺序优先级装载(ORP ),其共同点是通过预测需要立即使用的页面,并依此降低重载时间。这三者的区别在于磁盘备份的结构、是否利用数据访问频率、重装优先级、重装粒度。所谓重载粒度就是数据重载的最小单元,在这个单元的数据载入过程中,不会发生抢占,除此之外高优先级装入可以抢占低优先级装入。这些算法区分等待事务和执行事务。等待事务就是那些在系统崩溃时还未提交的激活事务,而执行事务则是在系统重新开始工作后到达的事务。

2.2改进的重载算法

该算法充分考虑了上述各重载算法的优点,同时参考重载事务的预分析、数据载入的影响因素和数据交换在数据库运行时的策略,具体的实现算法如下。

第一步:建立恢复缓冲区和脏页表,给出等待事务的标号。

第二步:将系统信息重载到MMDB系统区。

第三步:标识故障时处于活动和等待状态的事务及其存储所需的数据库片,并将这些数据库片组合在一起。组合的原则是按照柱面的不同确定,同时充分参照磁盘数据库目录提供的信息。

第四步:将外存数据重载到MMDB主数据区,当数据量达到重装阀值(RT)停止重载。重载的优先级策略如下:

首先以存取频率由高到低的顺序作为基础,将“等待”事务按照其优先级由高到低的顺序载入其数据;

其次根据日志对离发生故障最近一次的检查点之后被修改的脏数据页进行数据恢复;

最后将其余数据载入,载入时依照存取频率的高低顺序进行。

第五步:复制己提交事务的“后映像”,将这些都复制到其私有的缓冲区。

第六步:重载到达阀值,接着启动系统运行并开始处理事务。

第七步:重载其他的外存数据到MMDB主数据区,重载的优先级策略如下:

首先按请求载入新到达的执行事务所需求的相应数据库片;

其次载入“等待”事务所需的其他数据库片,仍然以柱面为基础;

最后载入其他柱面数据,载入时依据磁盘数据库的存储顺序进行。

2.3改进算法的实验与结论

本实验重写Hsqldb的恢复模块,将上面提出的重载算法编程实现,并进行实验对比。对比时,按照分别插入不同数目的记录,分别是100、1000、10000、100000。在数据库运行过程中强制执行关闭操作,得到其相应的日志文件。Hsqldb的顺序重载和按优先级重载的结果如表1和图1所示:

从图1可以看出:刚开始数据优先级重载的优越性并不明显,当插入记录的条数达到1000条后,按优先级重载的良好性能才能体现出来。那么在高并发的适应应用环境下,按优先级的重载性能优于顺序重载。

结果表明:1)数据优先级算法时间开销少于顺序重载算法;2) 一个有效的重载算法对于内存数据库系统来说是非常重要的;3) 事务优先级和数据的各种特性在设计实时内存数据库重载算法时显得尤为关键。

2.4重载后的恢复策略

系统故障恢复由两个步骤组成,分别是重载和重载后的恢复。重载后的恢复是指根据日志和检查点执行的相应操作,恢复数据库到离系统崩溃时最近一次的一致性状态。在系统重启过程中一旦发现脏页,将根据磁盘上的日志和数据库进行重载恢复,具体步骤如下:

第一步:发现到最后一个检查点。

第二步:从检查点中读入以下内容到内存:1完整的数据库镜像;2稳定全局日志尾指针;3活动事务表,包括所有活动事务的TID和状态信息;4所有活动事务的undo日志;5系统最后分配的事务提交顺序号csn。

第三步:在稳定日志中,将当前稳定日志尾指针作为开头, 按照自后向前的顺序进行搜索,直至寻找到第一个提交/失败记录,并移动稳定日志尾指针到该点。

第四步:将读入的检查点中记录的稳定日志尾指针作为起点,按照由前向后的顺序遍历日志直至日志尾,并执行以下操作:

第五步:对于在检查点处于活动状态的事务,如果redo日志中没有提交记录<commit Ti,csn(Ti)>且其状态也未被标记为“提交中”,那么从检查点中找到相应的undo日志并执行相应操作。

3小结

内存数据库的系统故障不同于磁盘数据库,内存数据库大多用在实时环境下,它要求事务和数据具有实时性,需要重新考虑其重载算法及重载过程中的恢复算法。系统故障分为故障后重载和重载过程中的恢复。改进的重载算法,表明:数据优先级算法时间开销少于顺序重载算法;一个有效的重载算法对于内存数据库系统来说是非常重要的;事务优先级和数据的各种特性在设计实时内存数据库重载算法时显得尤为关键。

内存数据库系统篇2

为SQLSERVER提供的可用内存越多，SQLSERVER就有越多的资源使用于缓冲区，即可减少服务器从磁盘读取数据以获取静态信息或编译过程计划的次数。调整SQLSERVER所占内存可通过在服务器配置文件中设置totalmemory参数进行，该参数的值指定了SQLSERVER在启动时所需的内存总量，如若该值为10000页，则SQLSERVER在启动时就将试图获得10000*2K=19.5M的内存，若不能满足则启动失败。

注意，若操作系统在进程的整个生命周期中支持动态内存分配，则可在SQLSERVER启动后为其分配额外的内存。

SQLSERVER启动时将内存分配给SQLSERVER可执行代码，SQLSERVER使用的静态内存，用户可配置参数占用的内存及不驻留在缓存上的数据结构，剩余的内存分配给两种SQLSERVER缓冲区即：数据缓冲区和过程缓冲区。两缓冲区的大小对整个系统的性能影响很大，在一个开发系统上可能要增加过多端程缓冲区的专用内存，而在一生产系统上则需减少过程缓冲区大小以便获得更大的数据缓冲区。

1.确定缓冲区大小

在totalmemory配置的总空间中，首先要除去可爱执行代码所占空间，其大小因平台和版本不同而异，可使用sp_configure查询executablecodesize参数的值得知，一般为3-4MB;其次需除去内部结构所占空间，内部结构分成内核结构和服务器结构，亦可将此部分内存看成静态开销和用户配置参数占用两个部分，前者大小不受用户可配置参数的影响，一般为2-3MB，而后者即用户可配置参数的大小则取决于配置参数的类型及其值的大小，包括numberofuserconnections, numberofopendatabases,numberofdevices,numberofopenobjects,numberoflocks等，要得到这些用户配置参数使用内存大小的精确估计，可调用不带选项的sp_configure以显示所有参数和每个参数使用的内存量，其和即是用户配置参数所占用内存。

除去上述占用，剩余内存将以procedurecachepercent配置参数的值按比例分配给过程缓冲区和数据缓冲区，例若值为20，即表示剩余内存的20%分配给过程缓冲区而80%分配给数据缓冲区。

确定缓冲区大小的另一种方法是检查SQLSERVE启动时写入SQLSERVER错误日志的内存信息，其中准确地说明了分配给过程缓冲区和数据缓冲区的数据量，以及多少个过程或其他编译对象能同时驻留在缓冲区中，如相关信息为：

server:Numberofprocbuffersassocated:556

server:Numberofblocksleftforprocheaders:629

server:Memoryallocatedforthedefaultdatacache:4144kb

前两行为过程缓冲区信息，过程缓冲区总大小是分配给过程缓冲区的内存(第一行)及分配给过程头(即存放编译对象如存储过程的地方，根据被存储对象的大小，可能需要一个或多个过程头) 的内存(第二行)之和，可存储在过程缓冲区中的编译对象受到此二者中较小者的限制。上述信息中，第一行指明了分配给过程缓冲区的缓冲区数量为556，每个缓冲区大小为76B，故过程缓冲区大小即为42256B，合21页;第二行则指明了分配给过程头的空间为629页，由此可以得出，过程缓冲区总大小为629+21=650页，合1.27M。

信息中第三行则指明了分配给默认数据库缓冲区的空间大小。此外，若配置了命名缓冲区，则相关信息还将包含每个命名缓冲区的信息，再加上这些命名缓冲区所占内存大小即得到总的数据缓冲区大小。欲知数据缓冲区大小还可通过sp_helpcache过程得到每个缓冲区和捆绑到这些缓冲区中的对象以及与不同缓冲区大小相关的开销的详细信息。

2.缓冲区管理

数据缓冲区保存SQLSERVER当前使用和最近使用过的数据页,索引页和日志页.初装SQLSERVER时,会产生一个默认的数据缓冲区.SQLSERVER允许系统管理员把数据缓冲区分成独立的命名数据缓冲区,然后可把数据库或数据库对象捆绑到这些命名缓冲区上,以对缓冲区空间进行更合理的组织,控制数据库,表和索引在内存的驻留.另外,系统管理员还可在缓冲区内创建缓冲池,用于执行大块的磁盘I/O,改善数据查询性能,减少磁盘I/O.有关数据库缓冲区的指令有：

sp_cacheconfig创建或删除命名缓冲区,改变缓冲区的大小或类型

sp_poolconfig创建或删除I/O缓冲池,并改变其大小

sp_bindeache将数据库或数据库对象捆绑到缓冲区

sp_unbindcache从一个缓冲区中取消对指定对象或数据库的捆绑

sp_unbindcache_all从一个缓冲区中取消所有对象的捆绑

sp_helpcache报告有关数据缓冲区的小结信息,并显示捆绑于缓冲区的数据库和对象

sp_cachestrategy报告有关为表,索引设置的缓冲区策略,禁止或重新允许先提或MRU策略

sp_logiosize为日志改变默认的I/O大小

sp_spaceused估计表和索引大小或有关数据库使用的空间量的信息

sp_estspace估计表和索引的大小,给出表包含的行的数目

sp_help报告表将捆绑于哪个缓冲区

sp_helpindex报告索引将捆绑于哪个缓冲区

sp_helpdb报告数据库将捆绑于哪个缓冲区

setshowplanon报告有关用于查询的I/O大小和缓冲区的应用策略

setstatisticsioon报告为查询进行的读操作数量

setprefetchon/off允许或禁止某个会话的预先提取

(1)查询数据库缓冲区的信息

查看默认数据缓冲区的大小,可使用指令sp_cacheconfig“defaultdatacache”,显示结果如下,由两部分构成,上部分报告每个缓冲区中的内存池配置信息并总计了所有配置缓冲区的大小;下部分提供了每个缓冲区中的其他详细信息。

第一部分输出各列含义为:cachename为缓冲区名;status指示该缓冲区是否激活(值为pend/act时表示该缓冲区刚建立,重启后将被激活;值为active时表示该缓冲区目前正处于激活状态;值为pend/del时表示该缓冲区处于激活状态,但在服务器重启后将被删除);type 指示缓冲区是否可以存储数据(“mixed”)和日志页(“logonly”),只有默认缓冲区才会有“default”类型,且默认的数据缓冲区类型不能改变,其他类型缓冲区也不能改为“default”; configvalue显示下次SQLSERVER重启后缓冲区的大小,在此情况下,默认缓冲区不能显式配置,故信息中其大小为0;runvalue显示SQLSERVER目前使用的大小,对于默认数据缓冲区,该值将作为未显示配置到其他缓冲区中的所有数据缓冲区空间。

第二部分输出各列含义为:IOsize显示缓冲池中的缓存大小,所有缓冲池缺省都分配2K空间(有效空间大小为2K,4K,8K,16K);washsize指示缓冲池的刷洗区大小;configsize和runsize显示配置大小和目前使用的大小,该两值在2K的缓冲池中是不同的(因为不能显式配置其大小),而对于其他缓冲池,若试图在缓冲池间移动空间而一些空间又不能被释放时, 上述两值也不同。

CacheNameStatusTypeConfigvalueRunvalue

---------------------------------------------------------

defaultdatacacheActiveDefault0.00MB59.36MB

-------------------------------

Total0.00MB59.36MB

=================================================

Cache:defaultdatacache,status:Active,Type:Default

ConfigSize:0.00MB,Runsize:59.36MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB59.36MB

(2)配置数据缓冲区

配置数据缓冲区有两种途径:一是使用过程sp_cacheconfig和sp_poolconfig进行交互式配置,二是编辑配置文件中的totalmemory参数后重启使之生效。

A.交互式配置

创建命名缓冲区(新创建的命名缓冲区从缺省缓冲区defaultdatacache中分配空间) ，每次执行sp_cacheconfig或sp_poolconfig时,SQLSERVER都将新的缓冲区或缓冲池信息写入配置文件中并将文件的旧版本拷贝到一个备份文件中,给出备份文件名的信息被送至错误日志。

创建一个新的名为pubs_cache的10M缓冲区指令如下,大小单位除M外,还可为P页,K,G, (默认为K).该指令将改变系统表并将新值写入配置文件但暂不激活缓冲区,要使其生效须重启SQLSERVER.

sp_cacheconfigpubs_cache,“10M”

在重启SQLSERVER使新值生效前,可先用sp_cacheconfig“pubs_cache”查看配置信息。如下,其中的status列值为pend/act说明该缓冲区的配置是挂起的,要待重启后生效,故Configvalue(配置的值)和Runvalue(正在使用的值)不同。

CacheNameStatusTypeConfigvalueRunvalue

--------------------------------------------

pubs_cachepend/actmixed10.00MB00.00MB

-------------------------------

Total10.00MB00.00MB

重启后再允许不带缓冲区名参数的sp_cacheconfig,则信息改变如下,可见pubs_cache 已被激活,默认缓冲区从其空间中分出了10M给该缓冲区.可利用sp_cacheconfig过程设置默认数据缓冲区的最小值,该部分空间将被锁定给默认数据缓冲区.例如设置默认数据缓冲区大小最少不低于25M则指令为sp_cacheconfig“defaultdatacache”“25M”。

CacheNameStatusTypeConfigvalueRunvalue

---------------------------------------------------------

defaultdatacacheActiveDefault0.00MB49.28MB

pubs_cacheActivemixed10.00MB10.00MB

-------------------------------

Total10.00MB59.28MB

===========================================

Cache:defaultdatacache,status:Active,Type:Default

ConfigSize:0.00MB,Runsize:49.28MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB49.28MB

===========================================

Cache:pubs_cache,status:Active,Type:mixed

ConfigSize:10.00MB,Runsize:10.00MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB10.00MB

若要保留一个只用于事务日志的缓冲区的类型,可以将缓冲区的类型设为“logonly”, 如创建“logonly”类型的pubs_log缓冲区为sp_cacheconfigpubs_log,“7M”,“logonly”, 下示为该缓冲区在重启前的状态。

CacheNameStatusTypeConfigvalueRunvalue

---------------------------------------------------------

pubs_cachepend/actlogonly7.00MB0.00MB

-------------------------------

Total7.00MB0.00MB

创建命名缓冲区后一般都须将某些对象捆绑到该缓冲区上。若建立命名缓冲区后未将任何对象捆绑到该命名缓冲区上，则该命名缓冲区所占内存将被浪费，因为任何未指定缓冲区的对象都将缺省使用默认数据缓冲区defaultdatacache.

将数据缓冲区划分为缓冲池建立数据缓冲区后,可将其划分成缓冲池,各不同的缓冲池具有不同的I/O大小,当SQLSERVER进行大I/O操作时,可将许多页一次读入缓冲区中,故可提高I/O效率.这些页总是被当作一个单元进行处理,它们共存于缓冲区中,作为一个单元被写到磁盘中。

缓冲池的页大小可为2K,4K,8K,16K,缓冲池的总大小不能低于512K.所有关于缓冲池的配置都是动态的,无需重启SQLSERVER即可生效.SQLSERVER内2K页缓冲池的个数必须保持一个合理的值，否则将会影响SQLSERVER性能，因为某些命令只能使用2K的I/O块如diskinit及某些dbclearcase/“ target=”_blank“ >cc命令，

在pubs_cache数据缓冲区中创建一个每页16K,总空间为7MB的缓冲池,指令如下.通常,创建命名数据缓冲区时,其空间总是被默认划分为每页2K的缓冲池,创建其它页大小的缓冲池时,该2K页缓冲池空间被部分分配给新缓冲池.下例中2K页大小的缓冲池原共有10M空间,分配给7M给16K页的新缓冲池后,2K页缓冲池还剩3M空间。

>;sp_poolconfigpubs_cache,”7M“,”16K“

>;go

>;sp_cacheconfigpubs_cache

CacheNameStatusTypeConfigvalueRunvalue

--------------------------------------------

pubs_cacheActivemixed10.00MB10.00MB

-------------------------------

Total10.00MB10.00MB

====================================

Cache:pubs_cache,status:Active,Type:mixed

ConfigSize:10.00MB,Runsize:10.00MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB3.00MB

16KB1424KB7.00MB7.00MB

在默认数据缓冲区中也可创建缓冲池,如创建16K缓冲池,空间大小为8M,则指令为：sp_poolconfig”defaultdatacache“,”8M“,”16K“.

若要为一个数据库的事务日志创建缓冲区,应配置缓冲区中大部分空间来匹配日志I/O的大小.默认值为4K,若没有4K的可用缓冲池,SQLSERVER就为日志使用2K的I/O.

日志I/O的大小可通过系统过程sp_logiosize来改变,每个数据库的日志I/O大小会在SQLSERVER启动后的错误日志中报告,也可通过使用数据库和执行不带参数的过程sp_logiosize来检查一个数据库的日志I/O大小.如为pubs_log缓冲区配置4K页大小的缓冲池指令为sp_poolconfigpubs_log,”3M“,”4K“,也可在默认数据缓冲区中创建一个4K页缓冲池,以供未被捆绑至其它缓冲区的任何数据库的事务日志来使用:sp_poolconfig”defaultdatacache“,”2.5M“,”4K“.

此外，可修改缓冲池大小，如从16K页I/O的缓冲池中取出1M空间增加到4K页I/O缓冲池中:sp_poolconifgpub_cache,”1M“,”4K“,”16K“

缓冲区悃绑操作

系统管理员把数据缓冲区分成独立的命名数据缓冲区后,可将数据库对象捆绑到这些缓冲区上,以控制数据库,表和索引在内存的驻留.若建立命名缓冲区后未将任何对象捆绑到该命名缓冲区上，则该命名缓冲区所占内存将被浪费，因为任何未指定缓冲区的对象都将缺省使用默认数据缓冲区defaultdatacache.为了将任何系统表, 包括事务日志syslogs捆绑至缓冲区中,数据库须处于单用户模式.对象被捆绑后立即生效而无需重启SQLSERVER.注意,进行捆绑或删除捆绑操作时,SQLSERVER需锁定相应对象,故相应对象上的其它操作可能有延迟.此外,可不删除现有的捆绑而重新捆绑

对象.另外,当被捆绑对象上有脏的读活动或有打开的游标时,捆绑或删除捆绑的操作将不能进行。

1>;sp_dboptionpubs2,single,true置pubs2库为单用户状态

2>;usepubs2

3>;checkpoint

4>;go准备进行数据库对象的捆绑。注意，捆绑对象须在对象所在的库中进行。

>;sp_bindcachepubs_cache,pubs2,titles

将pubs2库中的表titles捆绑至缓冲区pubs_cache.

>;sp_bindcachepubs_cache,pubs2,titles.titleind

在titles上捆绑索引,并将pubs2库中的表titles捆绑至缓冲区pubs_cache.

>;sp_bindcachepubs_cache,pubs2,”hj.sale_east“

将pubs2库中用户hj的表sale_east捆绑至缓冲区pubs_cache.

>;sp_bindcachepubs_log,pubs2,syslogs

将pubs2库的事务日志syslogs捆绑至缓冲区pubs_log.

>;sp_bindcachepubs_cache,pubs2,au_pix,”textonly“

表的text和image列存储在一个单独的数据结构中,若将此表捆绑至缓冲区,需加”text“参数.

1>;sp_dboptionpubs3,single,true置pubs3库为单用户状态

2>;usepubs3

3>;checkpoiot

4>;usemaster

5>;go准备进行数据库的捆绑，注意，捆绑数据库须在master库中进行。

>;sp_bindcachetempdb_cache,tempdb

将数据库tempdb捆绑至缓冲区tempdb_cache。注意，被捆绑到日志缓冲区上的对象只能是syslogs表。可通过sp_helpcache过程查询所有或指定缓冲区及其中被捆绑对象的捆绑信息.如下例示,其中status列报告缓冲区的捆绑是(”V“)否(”I“)有效.若数据库或对象被捆绑至缓冲池而该缓冲区已被删除,则捆绑信息仍保留在系统表中但缓冲区捆绑被标记无效,所有无效的捆绑对象均使用默认的数据库缓冲区.若随后用与被删除的缓冲区相同的名字创建了另一个缓冲区,则当该缓冲区通过重启SQLSERVER而被激活时,上述捆绑又将变为有效。

删除缓冲区捆绑可用两个过程:sp_unbindcache用于删除缓冲区中对一个实体的捆绑; sp_unbindcache_all则用于删除缓冲区中对所有对象的捆绑,但若捆绑至缓冲区的数据库超过8个,或数据库的对象超过8个,就不能使用p_unbindcache_all,此情况下,必须使用sp_unbindcache删除单个的数据库或对象,使捆绑的数据库不超过8个.此外,当删除缓冲区对一个对象的捆绑时,内存中所有当前的页都被从缓冲区中清除.

>;sp_unbindcachepubs2

删除对数据库pubs2的捆绑

>;sp_unbindcachepubs2,titles

删除对pubs2库中对titles表的捆绑

>;sp_unbindcachepubs2,titles,titleidind

铲除对pubs2库中titles表上titleidind索引的捆绑.

>;改变命名数据缓冲区大小

可通过sp_cacheconfig指定一个新的空间以增加或减少指定缓冲区的大小,所有新增空间都将从缺省数据缓冲区defaultdatacache内的2K缓冲池中被加到指定缓冲区内的2K页缓冲池中,所有减少的空间亦从指定缓冲区内的2K页缓冲池中被释放到缺省数据库缓冲区defaultdatacache内的2K缓冲池中。

>;sp_cacheconfigpubs_cache

CacheNameStatusTypeConfigvalueRunvalue

--------------------------------------------

pubs_cacheActivemixed10.00MB10.00MB

-------------------------------

Total10.00MB10.00MB

=======================================

Cache:pubs_cache,status:Active,Type:mixed

ConfigSize:10.00MB,Runsize:10.00MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB720KB0.00MB3.00MB

4KB1024KB4.00MB4.00MB

16KB1424KB3.00MB3.00MB

现以sp_cacheconfigpubs_cache,”20M“后重启,则改变如下:

>;sp_cacheconfigpubs_cache

CacheNameStatusTypeConfigvalueRunvalue

----------------------------------------------

pubs_cacheActivemixed20.00MB20.00MB

-------------------------------

Total20.00MB20.00MB

========================================

Cache:pubs_cache,status:Active,Type:mixed

ConfigSize:20.00MB,Runsize:20.00MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB13.00MB

4KB1024KB4.00MB4.00MB

16KB1424KB3.00MB3.00MB

返回pubs_log缓冲区报告:

>;sp_cacheconfigpubs_log

CacheNameStatusTypeConfigvalueRunvalue

-------------------------------------------

pubs_logActivelogonly7.00MB7.00MB

-------------------------------

Total7.00MB7.00MB

====================================

Cache:pubs_log,status:Active,Type:logonly

ConfigSize:7.00MB,Runsize:7.00MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB4.00MB

4KB1024KB3.00MB3.00MB

再运行以指令sp_cacheconfigpubs_log,”6M“后重启,则改变为:

>;sp_cacheconfigpubs_log

CacheNameStatusTypeConfigvalueRunvalue

----------------------------------------------

pubs_logActivelogonly6.00MB6.00MB

-------------------------------

Total6.00MB6.00MB

==========================================

Cache:pubs_log,status:Active,Type:logonly

ConfigSize:6.00MB,Runsize:6.00MB

IOSizeWashSizeConfigSizeRunSize

-----------------------------------

2KB512KB0.00MB3.00MB

4KB1024KB3.00MB3.00MB

欲彻底删除一个数据缓冲区,将其大小复位为0可使用sp_cacheconfigpubs_log,”0“. 则将缓冲区状态变为”pend/del“,重启SQLSERVER后此改变生效.在执行该操作前,缓冲区需保持激活状态,捆绑至缓冲区的所有对象仍使用该缓冲区执行I/O操作.若有对象捆绑于待删除的数据缓冲区,则SQLSERVER重启后,缓冲区的捆绑被标记为无效,所有无效缓冲区捆绑的对象都使用默认数据缓冲区.当捆绑被标记为无效时,警告信息将被输入错误日志.注意,默认数据缓冲区不能删除。

(责任编辑：铭铭)

内存数据库中间件系统设计方案篇3

内存数据库是对计算机内存进行优化的处理,将数据常驻内存中实现全事务处理的数据库系统。目前在国内电信行业已经是普遍使用了,其中主要是TT、Altibase、EXtremeDB。本系统主要是利用Hibernate实现一个内存数据库和客户端的中间件,从而向程序员提供一个基Hibernate的统一接口,方便对HSqlDB进行访问。

1 Hibernate简介

Hibernate是一种新的ORM映射工具,它同时提供了从Java类到数据表的映射和数据查询、恢复等机制,实现数据层对象的持久性。相对于使用JDBC和SQL来手工操作数据库,使用Hibernate可以大大减少操作数据库的工作量,并且Hibernate可以和多种Web服务器以及应用服务器良好地集成。ORM即对象关系映射。它是将关系数据库中表的数据映射成为对象,以对象的形式展现,这样开发人员就可以把对数据库的操作转化为对这些对象的操作。

2 HSqldb简介

HSqldb是一个开放源代码的JAVA数据库,其具有标准的SQL语法和JAVA接口,它可以自由使用和分发,非常简洁和快速。具有Server模式、进程内模式(In-Process)和内存模式(MemoryOnly)三种。

3 内存数据库中间件系统结构及实现

3.1 系统的总体结构

系统在应用时的分层模型如图1。Application指用于应用程序,Hibernate是JAVA平台向程序员提供的统一的编程接口和平台,再往下一层的Hibernate Data Provider for HSqlDB就是本项目实现的核心部分,它调用下层的HSqlDB数据库接口,作为Hibernate平台中的一部分,向程序员提供针对HSqlDB数据库的操作。本系统中包含一个数据库表转移部件,用于将SQL Server中的数据转存到HSqlDB中,这就使得系统的移植更加方便。

3.2 Hibernate

Data-Provider for HSqlDB Hibernate DataProvider for HSqlDB逻辑上与Hibernate Data Provider for SQL Server等在同一层次。本系统为简化系统复杂度,减少层次以优化性能,直接提供一个面向HSqlDB的数据提供程序。

此数据提供程序使用JAVA语言实现,调用了hsqldb.jar提供的org.hsqldb.jdbcDriver驱动接口,将接口的相关信息包括用户名和密码写入到配置文件中。核心类部分包括Configure,SessionFactory,Session,扩展类部分包括HsqldbCommandBuilder、HsqldbParameter、HsqldbParameterCollection和HsqldbTransaction中的部分接口。数据提供程序最终以HsqldbDataProvider.jar包文件的形式供程序员调用。使用本数据提供程序,程序员可以通过统一的接口,像对SQL Server数据库一样,通过sql语句对HSqlDB数据库进行基本的查询、修改、插入、删除操作。

3.3 数据库表的迁移

数据库表的迁移是数据转换程序提供的数据转换功能,使原来存放在SQL Server数据库中的数据批量转存到HSqlDB数据库中的相同表中,以方便系统的移植。

数据库表的迁移的工作原理是:(1)首先利用Hibernate Data Provider for SQL Server,将SQL Server数据库中的数据提取出来,并转存为XML格式。(2)将生成的XML文件进行格式转换为HSqlDB数据库可以识别的XML文件。(3)把转换好的XML文件导入HSqlDB数据库。经过上述三步,数据转换程序就完成了数据的转移。目前本系统中的数据转换器只能提供单个表中数据的批量转换。要将整个数据库进行移植,需要手工将每个表依次进行转换。

4 性能测试与结论

本系统使用一个简易的JSP网站进行了基本测试工作,在JAVA平台上,利用Hibernate Data Provider for HSqlDB和Hibernate Data Provider for SQL Server,分别对HSqlDB和SQL Server数据库进行了对比测试。

测试中使用的数据库表格式为:persons(name int,age int,address string)。

4.1 查询测试

进行查询操作的测试是,HSqlDB数据库和SQL Server数据库中分别存放好300000条数据。从300000条数据中查询2000条数据的时间:HSqlDB需6.263秒、SQL Server需12.324秒。

4.2 插入测试

分别插入30000条记录时,HSqlDB和SQL Server用时分别为:31.528秒和52.143秒。当插入数据量较少时,HSqlDB的性能并不比SQL Server高。主要是因为SQL Server和Hibernate都有缓存机制,当数据量小时,其缓存可以存放所有数据,因此HSqlDB无法体现其优势。

5 结论

在操作的数据量足够大时(大于磁盘数据库系统的数据缓存),内存数据库HSqlDB与传统的磁盘数据库相比,性能有明显的提升。尤其是在进行只读操作时,性能提升更加明显,通常可以将时间缩短1到2个数量级。数据量较小的情况下,内存数据库的性能提升并不明显。

测试结果显示,内存数据HSqlDB较适合存在大量只读操作的系统,如经典文献储藏网站、各类信息消息的发布查询网站等。

摘要：内存数据库IMDB通过JAVA作为操作数据语言实现的程序可以为数据库事务逻辑处理带来的性能提升。该系统利用当前流行的SSH框架中的Hibernate实现Date Provider for HSqlDB,程序员可以通过相应的接口对HSqlDB进行查询、添加、删除、更新等操作,并在大容量的数据操作时,效果会有明显的提升。

关键词：HSqlDB,JAVA,Hibernate,内存数据库系统

参考文献

内存数据库系统篇4

机器内存很大，但越用越少，发现执行完一些批操作命令后，内存竟不释放（vmstat看free很少）。请教大家是不是minfreemaxfreeminpermmaxperm的设置有问题？

现在的minfree/maxfree较小，maxperm偏大。

谢谢！

zhilan 回复于：2003-01-08 16:11:41我执行compress大文件的时候，内存free越来越少，paging space用了 6%。但compress完毕后，内存free还在往下掉，按说应该回到compress前的水平啊。另外paging space还是占用了6%，没有释放。

好使回复于：2003-01-08 16:15:09如果系统运行正常的话，没问题。

系统在VM方面，有一大部分用在文件的缓存上了，建议看看关于性能调整的资料。

zhilan 回复于：2003-01-08 16:41:22谢谢！问题是上次作load database时机器死了，当时paging space满了，剩余内存为0。机器是s85, 内存24 GB, paging space 8 GB。我估计作load database时内存free就不多了。如果是file cache占用过多的话，应该可以腾出作load database啊。调整maxperm/minfree/maxfree会有用吗？

另外，我一台跑cics，另一台跑sybase，两台问题都一样。按说跑cics的应该不会有问题的啊。

zhilan 回复于：2003-01-08 16:46:57另外一台s80没有这个问题。free很多，而且做完批命令后内存free马上恢复到原来的水平。跑的应用差不多。

我准备调整minfree/maxfree/maxperm等试试，还请各位多多指教！

好使回复于：2003-01-08 16:48:24系统的补丁全吗？是不是memory leak?

tonylau 回复于：2003-01-08 17:24:24可以设置最大永久占有内存参数，/usr/samples/kernel/vmtune -h 1

这样系统的uncompute内存最大到80%(topas),系统会有10%的内存Free

vofsky 回复于：2003-01-08 17:27:37打补丁看看

tonylau 回复于：2003-01-08 17:41:01这个现象打补丁没用。

zhilan 回复于：2003-01-08 20:41:31谢谢几位！已经解决了，除按tonylau所说做了vmtune h 1外，还改了minfree/maxfree/minperm/maxperm。感觉h 1挺管用的。

再次向大家表示衷心的谢意！

另外把这些参数修改加在了/etc/inittab中，这样reboot后也自动执行。

又碰到一个棘手的问题，再发帖请教。

ibm6000 回复于：2003-01-08 20:48:05这个帖子不错，有头有尾，加为精华：）

lljj 回复于：2003-01-08 21:06:31我还发现sybase

load数据库时！的确有这个问题！

大最新的sybase补丁！

jflong 回复于：2003-01-09 08:55:49请问一下minfreemaxfreeminpermmaxperm怎么设置?

zhilan 回复于：2003-01-09 10:00:24/usr/samples/kernel/vmtune -p ** -P ** -f **** -F **** -h 1

jinyingtao 回复于：2003-01-09 14:24:47这类问题属于内存分配问题。

类似大量文件类操作，如compress、database的dump/load会大量占有内存中的文件型内存（在AIX系统中，内存简单可以分为两类：计算型内存和文件型内存）。所以按照系统缺省的配置，文件型内存最多会占用total real memory的80%（这个可以利用nmon看到），当内存很少时，就会产生换叶到paging space的现象，主要换出文件型内存帧。

这个问题可以通过vmtune加以控制，在/etc/inittab中添加：vmtune:2nce:/usr/samples/kernel/vmtune -p 5 -P 20 -h 1将文件型内存控制在total real memory的5%～20%之间，也就是minperm和maxperm。

前提是必须安装vmtune，好像在bos.adt.samples中

tonylau 回复于：2003-01-09 16:20:33调整MAXPERM和MINPERM是SOFT LIMIT,调整后实际效果并不好，调整STRICT_MAXPERM(-h 1)是HARD LIMIT,强制。

zhilan 回复于：2003-01-14 17:51:18jinyingtao 你好！我正是这样做的，将maxperm设置为远小于缺省值，并执行严格的maxperm策略（即h 1）。

先看参数的意义：

If percentage of RAM oclearcase/“ target=”_blank“ >ccupied by file pages falls below minperm, VMM steals both file and computational pages

If percentage of RAM occupied by file pages rises above maxperm, VMM steals only file pages

If percentage of RAM occupied by file pages is between minperm and maxperm, VMM will steal only file pages Unless file repaging rate is higher than computational repaging rate

将maxperm设小，可避免这样的情形：当执行大量文件类操作时，文件性内存耗用过多，而计算性内存将不敷使用，从而产生大量的换页操作。而事实上此时文件性内存应作为page-stealer的偷取对象，因为它被重复引用的可能性非常低。

zhilan 回复于：2003-01-14 17:53:13jinyingtao 你好！我正是这样做的，将maxperm设置为远小于缺省值，并执行严格的maxperm策略（即h 1）。

先看参数的意义：

If percentage of RAM occupied by file pages falls below minperm, VMM steals both file and computational pages

If percentage of RAM occupied by file pages rises above maxperm, VMM steals only file pages

If percentage of RAM occupied by file pages is between minperm and maxperm, VMM will steal only file pages Unless file repaging rate is higher than computational repaging rate

zhilan 回复于：2003-01-14 17:54:19jinyingtao 你好！我正是这样做的，将maxperm设置为远小于缺省值，并执行严格的maxperm策略（即h 1）。

先看参数的意义：

If percentage of RAM occupied by file pages falls below minperm, VMM steals both file and computational pages

If percentage of RAM occupied by file pages rises above maxperm, VMM steals only file pages

If percentage of RAM occupied by file pages is between minperm and maxperm, VMM will steal only file pages Unless file repaging rate is higher than computational repaging rate

将maxperm设小，可避免这样的情形：当执行大量文件类操作时，文件性内存耗用过多，而计算性内存将不敷使用，从而产生大量的换页操作，

而事实上此时文件性内存应作为page-stealer的偷取对象，因为它被重复引用的可能性非常低。

zhilan 回复于：2003-01-08 16:03:03

好使回复于：2003-01-08 16:15:09如果系统运行正常的话，没问题。

系统在VM方面，有一大部分用在文件的缓存上了，建议看看关于性能调整的资料。

另外，我一台跑cics，另一台跑sybase，两台问题都一样。按说跑cics的应该不会有问题的啊。

zhilan 回复于：2003-01-08 16:46:57另外一台s80没有这个问题。free很多，而且做完批命令后内存free马上恢复到原来的水平。跑的应用差不多。

我准备调整minfree/maxfree/maxperm等试试，还请各位多多指教！

好使回复于：2003-01-08 16:48:24系统的补丁全吗？是不是memory leak?

tonylau 回复于：2003-01-08 17:24:24可以设置最大永久占有内存参数，/usr/samples/kernel/vmtune -h 1

这样系统的uncompute内存最大到80%(topas),系统会有10%的内存Free

vofsky 回复于：2003-01-08 17:27:37打补丁看看

tonylau 回复于：2003-01-08 17:41:01这个现象打补丁没用。

zhilan 回复于：2003-01-08 20:41:31谢谢几位！已经解决了，除按tonylau所说做了vmtune h 1外，还改了minfree/maxfree/minperm/maxperm。感觉h 1挺管用的。

再次向大家表示衷心的谢意！

另外把这些参数修改加在了/etc/inittab中，这样reboot后也自动执行。

又碰到一个棘手的问题，再发帖请教。

ibm6000 回复于：2003-01-08 20:48:05这个帖子不错，有头有尾，加为精华：）

lljj 回复于：2003-01-08 21:06:31我还发现sybase

load数据库时！的确有这个问题！

大最新的sybase补丁！

jflong 回复于：2003-01-09 08:55:49请问一下minfreemaxfreeminpermmaxperm怎么设置?

zhilan 回复于：2003-01-09 10:00:24/usr/samples/kernel/vmtune -p ** -P ** -f **** -F **** -h 1

jinyingtao 回复于：2003-01-09 14:24:47这类问题属于内存分配问题。

前提是必须安装vmtune，好像在bos.adt.samples中

tonylau 回复于：2003-01-09 16:20:33调整MAXPERM和MINPERM是SOFT LIMIT,调整后实际效果并不好，调整STRICT_MAXPERM(-h 1)是HARD LIMIT,强制。

zhilan 回复于：2003-01-14 17:51:18jinyingtao 你好！我正是这样做的，将maxperm设置为远小于缺省值，并执行严格的maxperm策略（即h 1）。

先看参数的意义：

If percentage of RAM occupied by file pages falls below minperm, VMM steals both file and computational pages

If percentage of RAM occupied by file pages rises above maxperm, VMM steals only file pages

If percentage of RAM occupied by file pages is between minperm and maxperm, VMM will steal only file pages Unless file repaging rate is higher than computational repaging rate

zhilan 回复于：2003-01-14 17:53:13jinyingtao 你好！我正是这样做的，将maxperm设置为远小于缺省值，并执行严格的maxperm策略（即h 1）。

先看参数的意义：

If percentage of RAM occupied by file pages falls below minperm, VMM steals both file and computational pages

If percentage of RAM occupied by file pages rises above maxperm, VMM steals only file pages

If percentage of RAM occupied by file pages is between minperm and maxperm, VMM will steal only file pages Unless file repaging rate is higher than computational repaging rate

zhilan 回复于：2003-01-14 17:54:19jinyingtao 你好！我正是这样做的，将maxperm设置为远小于缺省值，并执行严格的maxperm策略（即h 1）。

先看参数的意义：

If percentage of RAM occupied by file pages falls below minperm, VMM steals both file and computational pages

If percentage of RAM occupied by file pages rises above maxperm, VMM steals only file pages

If percentage of RAM occupied by file pages is between minperm and maxperm, VMM will steal only file pages Unless file repaging rate is higher than computational repaging rate

内存数据库系统篇5

数据库自诞生以来经过几十年时间的发展,已经走向成熟;另一方面,纯机械化也已不能满足许多行业生产和发展的需要;于是业务系统和当代数据库理所当然地走到了一起,向着自动化迈进。数据库的加入带来最直接的好处就是可以使大量的业务数据得以完好地保存,并且统一进行读写和业务调度,而目前看来,第三代关系型数据库做得最完善,其自身的优点结合突飞猛进的计算机硬件,使得关系数据库的应用范围越来越广,许多大数据量的实时性行业,如证券期货交易系统、电子商务、卫星导航等也包含在其中。

下面以一个典型的例子——证券交易清算系统为例简单介绍一下数据库的运作情况,该系统为证券公司提供开销户、行情转换、委托交易、清算对账等一系列功能。客户在某一营业部下委托时,系统将生成一笔委托单,发送给报盘系统,同时存储在数据库中。证券公司通过交易所给定的方式接收清算有关的dbf数据库文件,交易系统就通过清算数据接收,把dbf文件接收到数据库的一级清算表中,同时将保存在数据库中的公司当交易的二级数据进行合计,然后进行一二级对账,同时把返回的资金从客户的账户中进行加减。

然而,纯关系数据库在处理某些数据事务和业务流程上确实遇到了困难。主要反映在交易数据量大的时候会来不及下单并且会阻塞掉。有两次严重时几乎出现了不能正常交易的大事故。在求证过程中,我们查阅了不少资料,同时也发现了这类问题在几乎所有上规模的同类业务系统中都存在。

那么如何解决实时大数据量和现有关系数据库系统的矛盾呢?大家知道在内存中处理数据比在硬盘上面快得多,如果把数据库中经常用到和更新的表放到内存中去,事务运行时从内存而不是从硬盘里面读写数据,这样就会大大提高处理效率。鉴于以上思路,我们设计了一套完全适合该系统的内存机制来解决以上出现的问题。

2 内存机制的设计和实现

2.1 内存机制的前期设计

设计程序运行的主体,界面,内存表装载运行等,还要把客户的需求结合进来研究一些可实际运行的方案。目的是建立一个可以参考的原型化系统。主要包括以下几个方面:

1)界面操作参数设计,

2)进程和互斥管理,

3)内存机制的配置方法,

4)字段数据类型的支持和重建,

5)内存机制的运行和维护,

6)内存机制初始化,

7)内存表加载进程,

8)内存状态监控。

2.2 内存表设计

这是内存机制的核心内容。主要实现内存表储存、建立、控制、查询、修改等内容,为实施提供了导引和基准。

2.2.1 内存表的存储

和普通文件类似,内存表有表头、索引体和记录体3部分构成。表头部分存储该表的一些基本信息,索引体储存红黑索引树结点,记录体存放硬盘表中的数据镜像。表头的定义尤为重要,它需要存储的信息至少要有表ID、记录行所占字符数和最大行数,所处的物理位置等静态信息,此外还需要一些诸如当前记录数、起始空闲位置等动态信息等。表头的定义如下:

定义中包含表ID属性。它是一个内存首地址,对应唯一一张内存表。机制中的所有函数都是通过它来识别具体是哪张内存表。

2.2.2 表级操作

1) 内存表创建

创建内存表包括创建表头信息和分配内存空间两个方面。系统至少必须指定未来可能创建索引的数量、记录数、每条记录长度3项才能获得一个静态的分配值。

2) 打开内存表函数

如果文件被成功打开,此函数就返回一个共享表的句柄;失败时会返回NULL值,并输出具体的出错信息。

3) 获取内存表信息

该函数的功能为获取打开的共享内存表概要信息,以便操作者了解此表的对应关系、现今状态,还可以手工判断其是否需要进行维护和扩充。内存表的摘要信息存放在文件头中,返回的时候只要把这些信息全部输出就可以了。如果找不到句柄,就返回失败和错误信息。

4) 关闭内存表函数

该函数的功能为关闭打开内存表时返回的句柄SMTHandle。需要注意的是,关闭内存表不是删除内存表,其实际占用的内存空间不会被去除和释放。

5) 内存表清空

该函数的功能为快速删除整张表格的数据,相当于truncate命令。执行这句语句后,记录体被清空,但是表头和索引体仍然保留。

6) 内存表去除

当硬盘表被drop或发现建立的内存表不符合要求时,就要将其从系统内存中去除。

2.2.3 内存表查询

查询部分提供了基本功能包括:读取指定行记录、读取符合条件的记录、返回内存表基本信息(如记录数、索引数)等。这些操作也由上一级函数调用,不经过硬盘直接读取相应共享表的内存区块。在作查询操作时可以加共享锁,也可以不加锁。

2.2.4 内存表修改

当硬盘表进行修改操作后,为了业务功能函数能够取到正确值,内存表也必须同步修改。其方法和硬盘表相似,主要分为插入、更新、删除3种。

2.2.5 批量数据处理[2]

一个好的内存表需要提供便捷的批量处理能力,我们知道硬盘表一般是通过游标来处理的,频繁打开关闭游标等一系列操作会大大降低系统的运行效率。这也是整体效率低下的一个原因。在不引入内存机制的时代,有不少开发者宁可通过复杂的变成,套用一系列的循环和判断操作而避免使用游标。引入内存机制后,我们思考把游标的指向有硬盘表指向内存表进行一系列操作,游标的存储依然在内存中实现,这样既降低了游标对系统性能的影响,同时又提高了数据批量处理的效率,可谓一举两得。

1) 游标的建立

内存表的游标和普通游标一样,是一系列指针的集合,他的主体可以看作一张写满地址的内存表。内存表游标也提供两种建立方式,及索引和全检索。另外使用游标时首先要对其指向的内存表加写意向锁,避免由于删除记录等操作引起的指向错误。

2) 打开游标

根据游标的两种不同类型,打开游标也使用两种对应的方式。一种方式是打开根据索引方式检索的一个查询游标。另一种方式是打开一个全表检索的查询游标,这种方式不需要提供索引号,取而代之的是一个比较数据和其在记录中的偏移位置

3) 关闭游标

即关闭已经打开的查询游标,与关闭内存表一样,这个函数并不释放游标占用的内存。

4) 返回记录数

交易系统时常要都要统计各种分类的交易比数,为了操作员能直接去到这个值,我们需要提供对游标记录数的返回函数。

5) 获取当前游标记录

这个是游标系统的主要功能函数,用于获取当前位置的游标中的记录数据,执行原理如图1。

在游标刚刚打开的时候,取到的为游标首记录的数据。

6) 游标移动

游标移动包括上移和下移,指的是在游标中向上(或向下)移动一个游标位置指针。

2.3 索引研究

红黑树是在1972年由Rudolf Bayer发明的,又称作"对称二叉B树"[1]。它是一种高效的复杂树,一颗n结点红黑树可以在O(lg n)时间内完成查找、插入或删除操作。红黑树作为二叉查找树,它们当中每一个节点的比较值都必须大于或等于在它的左子树中的所有节点,并且小于或等于在它的右子树中的所有节点。这也确保了红黑树运作时能够快速的在树中查找给定的值。除了二叉查找树带有的一般要求,我们对任何有效的红黑树加以如下增补要求:

1) 节点是红色或黑色。

2) 根是黑色。

3) 所有叶子(外部节点)都是黑色。

4) 每个红色节点的两个子节点都是黑色(从每个叶子到根的所有路径上不能有两个连续的红色节点)。

5) 从每个叶子到根的所有路径都包含相同数目的黑色节点。

这些约束强制了红黑树的关键属性: 从根到叶子的最长的可能路径不多于最短的可能路径的两倍长。因为操作比如插入、删除和查找某个值都要求与树的高度成比例的最坏情况时间,这个在高度上的理论上限允许红黑树在最坏情况下都是高效的,而不同于普通的二叉查找树[2]。一个典型的红黑树如图2。

红黑树和AVL树一样都对插入时间、删除时间和查找时间提供了最好可能的最坏情况担保。这不只是使它们在时间敏感的应用如即时应用(real time application)中有价值,而且使它们有在提供最坏情况担保的其他数据结构中作为建造板块的价值。

我们根据数据结构红黑树的原理创建了一套高效的索引机制。

2.4 内存表的并发和共享设计

我们改进了硬盘表的加锁机制使之能够适用于该内存机制,同时内存锁和硬盘锁配合使用[3]。由于内存表放于主内存中,而linux的安全保护政策是允许多个核心进程存在的,所以这样做并不能避免被事先分配给内存表的共享内存区块被某些优先级很高的系统进程所抢占,但是可以大大减少此类事情发生的可能性[4]。

2.4.1 锁机制设计

主要包括对内存表的加锁和解锁,同时提供一个进行加锁分析的功能,用于手工分析该加什么锁[5]。加锁分下列五个阶段进行:

1)内存表建立阶段,

2)内存表/索引读取阶段,

3)内存表/索引写入阶段,

4)内存表同步阶段,

5)内存表消亡阶段。

2.4.2 锁机制实现

锁机制也是由函数控制。这里的实现不包括硬盘表部分,因为这些已经由主关系数据库实现了,锁机制部分只是调用而已,真正要实现的主要部分是对内存表进行锁控制。

2.5 系统维护与监控

我们设计了内存表的监控程序来完成系统的维护与监控,它包括两个部分:一方面用于监控已经存在的内存表状态,另一方面用于监控当前关系数据库中硬盘表的状态,这个监控程序需要考虑表的总流量、瞬时流量、访问次数、平均队列响应时间等一系列参数。既可以监控未建立内存表的硬盘表,衡量其是否适宜建立内存表都很大,又可以检测关系数据库是否产生了故障。

3 总结与体会

总的来讲,该研究实现了6个方面的内容:分析和设计了一套适合交易系统和原有关系数据库的内存机制实现框架;把关系数据库的表格存储和操作搬到了内存上;采用红黑树数据结构建立了一套灵活的内存读写索引;设计了一套内存并发与共享机制;优化了内存和原硬盘数据同步读取和更新;建立了一套有效的维护和监控方案。这6个方面构成了一套完整的交易数据库内存系统。这套系统是建立在应用服务器的主内存(系统内存)中,把原先在硬盘上进行读写的一些业务操作通过高效的内存来处理,可使单表操作的速度提高一至两个数量级,从而使整个业务的效率提高几倍。而且这套系统的原理还可以用在大多数实时性高数据量大的业务关系数据库系统中,具有比较好的通用性。

参考文献

[1]陈强璋.一种高效的二叉查找树———红黑树.华东师范大学学报(自然科学版),2000(3):39—42

[2]Ford W,Topp W,等.数据结构C++语言描述—应用标准模板库(STL)(第2版).陈君译.北京:清华大学出版社,2003

[3]邹建.SQL Server2000开发与管理应用实例.北京:人民邮电出版社,2005

[4]Love R.Linux内核设计与实现(第二版).陈莉君,康华,张波,译.北京:机械工业出版社,2006

内存数据库关键技术研究篇6

关键词：内存数据库,事务,日志,检查点,故障恢复

1 引言

内存数据库的研究起于20世纪70年代, 人们思考能否将数据库的全部或大部分数据存于内存, 省去运行时复杂的I/O操作, 从而提高存取效率。同时, 随着嵌入式设备的广泛应用, 人们在其里面存储着各种信息, 如何对这些信息进行有效的管理至关重要。近年来, 内存数据库技术不断发展, 各种新的思想和解决方法不断涌现, 丰富了内存数据库的理论基础。

2 内存数据库的定义及特点

设数据库系统DBS;数据库DB;在某时刻t, DB在内存的数据集DBM (t) , DBM (t) ⊆DB;所有可能的事务的集合TS, 在时刻t处于活动状态的事务集AT (t) , AT (t) ⊆TS;事务T在时刻t所操作的数据集Dt (T) , Dt (T) ⊆DB。任一时刻t, 若均有:∀T∈AT (t) , Dt (T) ⊆DBM (t) 成立, 则称DBS为内存数据库系统, 简称MMDBS;DB为内存数据库, 简称MMDB。

内存数据库的特点主要有常驻内存;优化体系结构设计的目标是提高内存和CPU效率;事务处理无需进行磁盘访问, MMDB性能较高。

3 内存数据库关键技术研究

3.1 内存数据库的存储结构

内存数据库存储在易失性内存中, 可以由处理机直接存取, 因而存取时间较短, 短至10-8量级。内存的顺序访问和随机访问时间开销相同, 提高内存的空间利用率是系统追求的目标, 内存是字节或字编址的。内存数据库物理组织多采用区-段式。此方式属关系模型, 它将存储空间划分为区, 每一区存储一个关系, 区由段组成。段是内外存I/O的单位, 也是内存空间分配和数据库恢复的单位。

3.2 索引的结构

常用的内存数据库索引结构为数组、AVL树、B/B+树、T树及hash索引等方法。其中, 它们具有各自的优点和缺点, 数组作为索引需要移动大量的数据, AVL树存储利用率低, 每一节点只能存储一个数据项, B树及其变种B+树操作性能好, 能动态维护, 但内存利用率低。内存数据库普遍应用T树, 它是一种AVL树和B树结合起来的二叉树。

3.3 并发控制

内存数据库的并发控制具有新的特点。首先, 内存访问速度快, 事务持有锁的时间很短, 对锁的竞争比较小。其次, 可以用统一的方式访问数据和元数据。对更加复杂的内存数据库系统, 采用单一的加锁方式不能满足长短事务的需要, 一般采用多粒度锁机制。

3.4 故障恢复

数据存储在内存中, 内存本身具有易失性, 再加上内存数据库很多用在易发生断电等故障的嵌入式设备, 因此内存数据库出现系统故障或事务故障较为频繁, 建立有效的恢复机制变得很关键。内存数据库恢复系统中, 有的数据库采用了特殊的硬件作为支撑, 主要有两种: (1) 采用非易失性内存 (NVRAM) , 将数据库的影子拷贝和日志放入其中, 减少I/O操作的次数, 提高吞吐量; (2) 为恢复处理操作, 增加一个恢复处理器, 负责日志管理、执行检查点、故障后的恢复操作。

3.4.1 日志协议

数据库的日志协议一般包括redo日志, undo日志和redo/undo日志协议。内存数据库中尽量使用redo日志, 而避免过多使用undo日志。redo日志采取延迟更新技术, 日志记录被写到磁盘后, 被更新数据可以在任何时候写入磁盘。有些内存数据库结合了上述两种日志协议的优点, 结合影子页面技术的思想, 提出事务私有缓冲区的概念, 同时, 该协议吸收了redo日志和undo日志的优点, 摒弃它们的很多缺点, 形成新的redo-undo日志协议, 该日志协议同时记录redo日志和undo日志, 但是当事务提交时, 只将redo日志保留, undo日志被删除, undo日志只在检查点操作时被刷新到磁盘, 这样可以减少日志的数量及I/O操作的次数, 同时又能利用undo日志处理检查点过程中的撤销操作, 实现模糊检查点的策略, 提高检查点过程中事务的并发性, 减少检查点与正常事务的冲突。

3.4.2 检查点 (Checkpoint) 选取

做检验点的策略有两种:静止检查点, 这种方法要求检查点开始运行时, 不在接纳新的事务, 等待当前运行的所有事务结束, 检查点结束, 新的事务开始运行。静止检查点虽原子地反映一个事务活动, 但是检查点过程可能由于等待一个长事务而消耗时间。静止检查点方法不适合内存数据库。

动态检查点, 在检查点执行的过程中, 可以接受新的事务, 同时基本上能保证事务或活动的原子性。典型的动态检查点包括fuzzy checkpoint技术, Ping—Pong方式, 黑白检验点, 更新时复制检验点等方法。

3.4.3 内存数据库的重装

为了不降低整个系统性能而快速恢复事务处理, 必须开发出一种有效的重装机制, 把数据库备份从磁盘转到内存。重装算法分两类:简单重装和并发重装。在简单重装中, 系统直到整个数据库装入主存中才恢复正常操作。并发重装中, 重装和事务处理并行进行。在并发重装机制中, 系统在整个数据库装入内存前就开始执行事务了。有的方法在系统日志和它们的索引装入内存后就可以开始正常事务处理了。当事务需要访问那些还没有装入内存的关系或者索引时, 恢复管理器就会重装相应的部分。典型的并发重装算法有顺序优先级装载 (ORP) 、智能装载 (SR) 和频率装载 (FR) 等三种算法, 这三种都通过预测哪些页面需要立刻使用来降低重装时间。

4 结语

内存数据库的应用领域日益广泛, 新的研究成果和技术不断涌现, 关注的人越来越多。把内存数据库引入到电信, 军事国防, 工业控制领域已成为必然趋势并将为解决这些领域的难题提供新的解决思路。

参考文献

[1]王珊, 等.内存数据库关键技术研究[J].计算机应用, 2007, 27 (10) .

[2]杨武军, 等.内存数据库技术综述[J].西安邮电学院学报, 2005, 10 (03) .

内存数据库关键技术探讨篇7

1 内存数据库与磁盘数据库区别

这两个数据库区别主要体现在物理机制上, 内存数据库的数据的“主拷贝”护着“工作版本”是常驻于内存的, 而磁盘数据库则是常驻磁盘。由于两者本身的不同, 导致内存与磁盘之间也存在差异, 如表1所示。

2 几个开源的内存数据库系统

2.1 SQLite

SQLite其实通过用C语言来书写的同时进行大部分SQL92为标准的数据库。和My SQL或者Postgre SQL相比较, SQLite特殊性表现在全部数据库都存储在单一的一个文件中, 能够直接集成在程序里, 其广泛的在应用在一些大型公共软件中, 如Skype。在许多语言, 如Java、Perl以及一些运行Symbian的手机上都应用了SQLite。SQLite自身所存在的不足表现在:在如多线程的并发中读写方面的性能较弱, 数据库可能存在被写操作独占的情况, 进而导致在其它事务的读写操作中产生阻塞或者报错;对SQL标准支持不全。

2.2 H2

H2 (Hypersonic 2) 是Thomas Mueller在2004年5月开发的一个开源的、纯java实现的关系数据库。它的主要特性是:非常快速, 支持JDBC API;支持嵌入式与服务器模式;提供以控制台应用为基础浏览器;占用压缩后极小的空间。H2内部应用的是b-tree的格式来实现表数据与索引存储。每一个b-tree存储的记录是一个关键字 (一行或多行) 和数据 (0或多行) 的列表。

2.3 FastDb

FastDb作为能够拥有实时处理能力的同时还有C++接口的高效内存数据库。Fast Db对客户—服务模式是不支持的, 应用Fast Db的程序与Fast Db应运行在相同的一台台主机上。Fast Db假定数据库整体存在RAM中, 同时以这个假定优化为基础查询算法与接口。数据库大小超过物理内存时, 操作系统交换机制就会工作, 性能与不超过时相比会有一定的降低。Fast Db在应用中支持事务在线备份, 同时还支持系统在崩溃后能够实现自动恢复。

2.4 Berkeley DB

Berkeley DB是由美国Sleepycat Software公司 (在2006年被Oracle收购) 开发的一套开放源码的嵌入式数据库的程序库 (database library) 。它可以在不同的编程语言、硬件平台以及存储介质中应用。Berkeley DB提供的多种语言的API, 如ANSI-C, C++, Java, C#, Perl, Python, Ruby and Erlang等。Berkeley DB支持应用通过网络接访问 (SQLite不支持) , 并提供文件存取方法。Berkeley DB将任一“key/data”对存储成字节数组, 实现单个键值能够有效支持多个数据项。其在支持成千上万个的线程同时访问时, 还能对规模较大的数据进行管理。

3 内存数据库的关键技术

3.1 数据组织

在磁盘数据库中, 数据是以文件的形式被存放在磁盘的, 从减少磁盘存取的要求出发, 通常应用的是聚集格式。从物理内存的角度分析现有的内存数据库可以得出, 在组织数据的方式上存在的主要是区段式和影子内存式。

区段式组织是以关系数据模型为基础的, 吧共享内存空间划为呈若干分区, 而一个分区又由若干段组成, 而每个段通常是共享内存动态分配中的一个单位。数据库中具体数据的记录是被保存在段中的记录块中。组织结构图如图1所示:

现有的以关系表为基础的内存数据库通常都应用的是区段式的数据组织方式, 比较有代表性的是SQLite。

在影子内存式的组织结构中, 内存数据库的空间划分是:一部分是内存数据库的主拷贝PDB;另一部分为“影子拷贝”SM。PDB与SM在数据库的操作期间中分别产生对应的地址, 同时对SM试探, 如果没有成功, 则再对主拷贝实施操作。全部更新操作是在SM中实施的, 同时记录活动日志。其组织结构如图2所示。

影子内存在事务并发度较高但是数据实时性要求不高的场合具有较大的应用优势, 开发人员能够通过把影子拷贝概念导入的方式对事务进行简化处理, 进而提升并发的程度。

3.2 并发控制

内存数据库与磁盘数据库中所应用的并发控制是基本相同的, 但是在细节上仍存在差异。因为内存在访问速度要比磁盘快, 导致MMDB中在事务执行速度也比较快。在采用基于锁的并发控制的系统中, 这意味着锁的时间不会保持太长, 系统中并发冲突较少, 由此在做并发控制时不必像DRDB那样时刻注意对锁的控制和操作。通过下属方法的应用减少锁的开销:一是在MMDB系统中应用较大的锁粒度;二是采用乐观加锁方式, 乐观并发控制中不需要事先进行冲突检查, 采用乐观并发控制时, 事务执行分为读 (read phase) 、校验 (validation) 和写 (write phase) 三个阶段;三是减少锁的类型;四是把锁信息存储到数据自身。值得注意的是, 长事务于短事务在应用中通常是并存的, 因提供一类粒度的锁是不行的。

从内存数据库的层面来看, 封锁所出现的CPU代价会给性能带来极大的影响, 尤其是在以短小事物工作负载为主的应用中。针对此问题, 有学者提出了接近串行的并发控制协议 (Almost Serial Protocol) , 是一种改进了的两阶段锁协议, 其改进之处在于写事务在数据库整体上施加互斥锁, 同时通过时间戳与互斥锁在记录未到磁盘前能确保所提交的读事务不会读到未提交数据。

3.3 恢复技术

从确保系统所具有的可靠性与事务的ACID出发, MMDB写日志与备份数据到磁盘等中是必须的。即使是在内存上运行的操作系统如Tinycore Linux也为数据库提供存储到磁盘的结构。现有内存数据库中所应用的恢复技术包括日志、检验点和重装几类。

日志中存在的记录包括系统运行、事务行为以及数据库变更三类, 其中, 系统运行的记录中含有系统的运行信息, 日志的存在为数据库恢复提供了应有的依据。在事务开始恢复执行前, 日志记录后的数据镜像也被装入内存中。

检查点操作通常是让数据库能够处在静止状态, 也就是说让当前事务在执行完毕同时阻止新事务执行, 且系统记录数据的部分或整体快照, 以此作为进行恢复的数据镜像。为减少对正常事务的干扰。在MMDB中广泛采用fuzzy checkpoint技术, 该技术作为非阻塞方式中的一类, 可以在任意的时间点进行checkpoint, 且不受事务或者动作其所在状态的限制, 但在系统恢复的实施下, checkpoint需要与日志文件之间进行协调配合才可以完成。为了尽量减少恢复机制给内存数据库带来的额外开销, 可以将日志记录记载于独立的缓冲区内, 当缓冲区写满或者事务提交时, 再将日志写回磁盘。

重装作为数据库外存版SDB与日志把内存数据库恢复到内存版MDB的过程。其分为完全重装与部分重装。前者应用在掉电等系统出现故障时, 在初装策略也可以应用。后者则主要应用在内存介质故障或内存不能存储在数据库整体的情况下, 其重点在换入数据的选择上。

4 结语

内存数据库经过二十多年的发展, 目前出现了越来越多的商用系统。这些商用的系统有开源的, 也有收费的。随着移动应用的不断增加, 如何更优的利用内存所具有的优势, 提高内存数据库所具有的性能与稳定性, 应不断加深在此方面的研究与应用。

参考文献

[1]曹猗宣, 王晶.内存数据库在彩铃业务中的应用[J].计算机系统应用, 2011, 20 (5) .

[2]杨武军, 张继荣, 屈军锁.内存数据库技术综述[J].西安邮电学院学报, 2005, 10 (3) .

基于内存数据库的索引算法研究篇8

关键词：内存数据库,缓存,CSB+树,TLB,索引

0 引言

近年来,内存数据库的应用越来越广,尤其是在智能电网领域中。因为在智能电网环境中,牵扯到各种各样的数据,从更新的实时性来看分为动态信息和静态信息,从种类的角度来看又分为线路、绝缘、塔杆以及温度报警信息等等,这类信息的增长速度是非常迅速的,目前来看,电网系统内部还是以选用磁盘数据库为主流,但是就目前数据增长的速度来看,磁盘数据库已经达到了瓶颈状态,数据库不停地访问磁盘已经耗费了大量的I/O时间,查询效率非常的低。而随着内存价格的不断下降,使得数据库服务可以应用在内存当中,那么之前制约磁盘数据库的问题就已经变为访问内存的延迟问题了,因为对于CPU的速度来说,访问内存的处理代价还是有点高,所以有必要有效地去使用缓存来提高数据索引的性能。

本文在索引结构上,以缓存敏感的索引结构为讨论方向,介绍了CSB+树的基本概念以及对其优缺点进行分析,指出其不足的地方。然后根据其不足和缺陷提出一种改进的CSB+树,并在此基础上实现索引的查询算法。

1 缓存敏感CSB+树

1.1 缓存敏感CSB+树

从名字可以看出其首先应该是一个对缓存非常敏感的树形结构,在进行索引查询时,其可以非常充分地利用缓存,并能把缓存的优势最大化的发挥出来,进而提高查询效率。缓存敏感索引树一般具有以下特点:①在缓存敏感索引树中,通常情况下人们所说的额交换数据是以缓存块为单位的,他扮演着重要的角色,由于索引项分布的十分紧密,这样无效信息就会非常的少,但是因此也会极大地增加有效信息在缓存中的比例,所以,缓存敏感树在其查询索引的过程中具有缓存失配率下降的特点,并且因为缓存失配率的下降,其缓存置换也会相应的减少。在这里需要对缓存敏感索引树节点的大小进行注意,在进行查找索引的情况下,使其查找的范围控制在一个缓存块当中,一般为64Byte或者128Byte,这样可以提高查询的效率。第二点就是对指针的空间进行了压缩,使其拥有很少的指针数量,而指针数量的减少也会增大数据在内存中的空间。总之要加大对缓存的研究,最终达到提高缓存利用率的目的。而CSB+树是其中应用比较广泛的索引树。

CSB+树英文全称Cache Sensitive B+Tree。虽然CSB+的前身是B+树,但是其也有很多不同的地方如:CSB+树和B+树最大的不同就是指针数量上的不同,B+树含有多个指针并且每个指针都指向某个节点,而CSB+树只含有一个指针,并且指向缓存敏感树中的下一个节点组。在这里要解释下节点组的概念,节点组顾名思义就是节点的集合,在这里是指CSB+树中的所有连续存储的兄弟节点的一个集合。从这里就可以看出如何确定索引项的下一节点的地址,就是通过当前的节点的指针和其偏移量的值相加得到。通过这样的设计对指针数量的控制就可以释放出更多的空间来存放数据,又可以通过减少指针的数量来提高索引的性能。

从以上可以看出,CSB+树不仅注重空间使用率并考虑到查询的性能,是一个非常棒的改进。但是CSB+树也有其不足的地方,主要表现在为了让索引树的效率提高,需要把节点大小设置为一个缓存块的大小,这样会无形地增加索引树的深度,导致当索引变得非常庞大的时候,查询算法所涉及的查询路径会非常的大,导致CPU访问次数过多,最终导致索引查询的效率降低[1]。

1.2 CSB+树TLB概念以及计算模型

TLB是传输后备缓冲器的缩写。目前所有的桌面型和服务器型处理器都使用了TLB。其工作原理为:在每次CPU进行响应时,都要先去存储器查找逻辑地址的页号,如果存储器有其逻辑地址页号,那么称这个过程称为TLB响应,反之称为TLB失配[2]。

这里假设几个变量:c是数据集,为<key,RID>大小,μ是节点利用率,是节点大小,为树节点元数据的大小,是索引项大小,是缓存块大小,那么依据这些参数,可以得出式(1)、式(2)以及式(3):

CSB+树节点的个数计算公式:

CSB+树节点散出度计算公式:

CSB+树的高度计算公式:

在进行第一次的索引查询时,缓存失配的次数就等于访问缓存块的次数。而在第二次乃至以后的查询中,在第一次查询时已经把刚刚查询过的索引储存在了缓存中,这样次数就会大大的降低。就像查询时,高层的节点总是会被查询到,而底层的节点查询的次数就会比较少,这就导致高层的缓存失配比低层的缓存失配少很多。因此本文定义了如下公式:

式(4)中X为只访问一次的节点数目,q表示总的查询次数,n是CSB+树中总节点的个数。

那么可以认为平均缓存失配次数的模型为:

其中,n(i)表示树的第i层节点的个数,n(i)=fi-1。

式(6)和式(7)分别为整个节点装入缓存中所需缓存个数以及TLB失配次数模型:

1.3 CSB+树的缺陷

在CSB+树的设计中,因为需要考虑到缓存的利用率的问题,本文把CSB+树的结点大小都设置为一个缓存块大小。这样做必将导致当索引非常大时,CSB+树的深度会非常的大,所以索引在索引树中的平均查询路径也会很大,这样索引的效率就会降低。通过实验发现,当缓存块的大小小于索引树结点大小时,查询功能会得到显著的提升。为了解决TLB失效问题,考虑通过缩小索引树的高度来提高整体的效率。本文提出一种改进的CSB+树,其设计思路是通过扩大节点的容量来减少其本身的高度,这样做也可以保持其原有的缓存敏感度,从而减少TLB失配的次数,提高其查询的性能[3]。

2 改进CSB+树的设计

2.1 改进CSB+树的总体结构

改进后的CSB+树与CSB+树不同,并没有把节点大小设置和缓存块大小一致,而是其整数倍,并且把节点分为几个区,而其中每个区的大小就等于缓存块的大小,这样的话就等于在没有降低其敏感度的情况下把树的高度给降低了。在进行数据处理的时候,除了第一次CPU会发生缓存失效的问题,后续的索引查询就可以直接在缓存中进行,因为第一次已经把该区放进了缓存中去,提高了索引的效率[4]。在改进的CSB+树中,扩展了CSB+树的节点概念,改进后的CSB+树中的某个节点已经不在是以前的节点概念,而是在节点的基础上有了分区的概念,并且对应之前CSB+树中某个节点。

图1给出了改进的CSB+树的总体结构。

不难理解,改进后的CSB+树就是扩展版的CSB+树图,图中虚方形就是CSB+树某个分区内所有的索引项所组成的一个集合,即节点组,而用实线围成的方形则代表节点,实方形中的圆形则代表节点内的分区。从图1中可以得出,其就是一个嵌套的结构,每个部分都包含另外一个部分,直到最小单位区。

2.2 改进CSB+树的节点内部结构

从图1中可以看出,改进后的CSB+树的节点被无形扩大,里面包含了n个分区,而之前的索引是不包括对分区的索引,所以需要对节点内的分区进行索引设计,具体设计如下所示。

在改进CSB+树中设计一个与缓存块大小一致的分区,并且把这个分区设置在节点的第一位,用于存放索引数组和子节点组的指针。节点内的每个分区是顺序存储的,且每个分区大小是固定的,因此采取一维数组对节点内的分区进行索引。因此根据数组下标可以快速定位节点内的每个分区[5,6,7]。

因为节点内部第一个分区含有整个节点的索引,所以当需要去访问CSB+树整个节点时,首先应该访问其索引分区,然后把key值与分区中的数组值想比较,由此可以获得访问节点内部分区的排列号,从而快速定位到节点内的分区,实现了简单聚簇索引。

图2为改进后的CSB+树的节点。

2.3 改进的CSB+树的查询算法

因为在国网系统中,对数据的操作主要是查询,所以本文将在改进CSB+树结构的基础上,详细设计其查询算法。

改进后的CSB+树的查询算法是自顶向下。首先确定要查找的主键值key,然后从根结点开始,看是否能够找到key值。如果找到了key值则返回其索引值,如果没有找到则去其子节点寻找,一直查询到其叶子节点为止,如果直到叶子节点也没有找到,则返回空值。其中若是在非叶子节点内的分区内没有找到key值,可以根据这个位置以及指针的值最终确定可能存在在哪个节点的分区内,并且以此递归,一直查询到叶子节点为止[8,9,10,11]。

图3为改进CSB+树在节点中查询算法的代码,本文把要查找的值设置为key,缓存块的大小为s,CSB+树节点的指针类型为Node,而当前查询的树节点为current Node。具体实现如图3所示。

3 实验对比及分析

本实验在同一台PC机上分别建立了以上两种树的索引,并且数据也是完全一样的,这样才能保证索引值是完全一致的。本文分别对其中任意的索引序列执行查询操作,然后通过比较平均缓存失配次数以及平均TLB失配次数来分析其算法性能。

实验结果如图4-5所示。

从实验结果中的缓存失配图可以看出,改进后的CSB+树和CSB+树的缓存失配次数是基本一样的,并没有什么明显的改变,这就说明其缓存敏感度并没有降低。在此基础上从平均TLB失配图的实验结果图明显可以看出,改进的CSB+树的TLB失配次数最大值还小于CSB+树的最小次数,这正是因为整个的缓存敏感索引树的高度下降所致。由此可以得出结论:改进后的CSB+树的确可以在不降低缓存敏感度的情况下优化查询的效率,降低TLB失配次数,对内存数据库的索引结构具有很高的价值。

4 结束语

本文主要研究了内存数据库的索引结构。在引言中分析了当前电网下的各种数据以及目前的形势,指出了内存数据库已经有了取代磁盘数据库的迹象。接着介绍了CSB+这种典型的缓存敏感树,分析出了CSB+的优缺点,并在注重缓存敏感的同时降低其平均TLB失配次数,提高查询的总体性能,在最后给出了查询算法的设计以及实验结果分析。所以,内存数据库缓存敏感的索引结构的研究与应用仍然是今后内存数据库技术的一个重点,并具有很高的研究价值。

参考文献

[1]Luan Hua,Du Xiao-yong,Wang Shan.Prefetching J+-Tree:A Cache-Optimized Main Memory Database Index Structure[J].Journal of Computer Science&Technology,2009(4):687-707.

[2]Sun Han-xin,Yang Kun-peng,Zhao Yu-lai.CASA:A New IFU Architecture for Power-Efficient Instruction Cache and TLB Designs[J].Journal of Computer Science&Technology,2008(1):141-153.

[3]肖富平.内存数据库存储及索引技术研究[D].重庆:重庆大学,2009:81.

[4]李国徽,杨进才.内存数据库查询优化[J].华中科技大学学报:自然科学版,2003(4):21-23,29.

[5]王澜.内存数据库中B+树和CSB+树的性能比较[J].通讯世界,2015(12):277.

[6]段敏娟,何强.浅析内存数据库中的几种关键技术[J].技术与市场,2015(1):69.

[7]李玉.基于Redis内存数据库的RADIUS镜像系统研究[J].电信技术,2014(8):48-51.

[8]高小猛.列式内存数据库的自组织元组重构方法研究[D].哈尔滨:哈尔滨工业大学,2013:32-41.

[9]刘勇.基于GPU的内存数据库索引技术研究[D].广州:华南理工大学,2013:50-61.

[10]李灿辉.基于内存数据库的空间索引结构CSR树性能研究[J].数字技术与应用,2011(9):128.

内存数据库在高速缓存方面的应用篇9

自改革开放以来, 我国计算机网络技术进入了飞速发展阶段, 随着高速缓存技术的发展, 互联网接入网速度得到了显著的提升, 同时由于主干带宽不断扩容, 用户规模不断扩大, 有关宽带用户认证计费管理方面的问题也随之显现出来。内存数据库进入高速缓存系统, 虽然能够提高计算机网路应用的综合性能, 但其装置成本也会大大提高[1]。目前, 我国拥有的网络用户数量庞大, 所以互联网运营商为了维护企业的切实利益, 逐渐加大了宽带用户认证计费力度, 其目的在于让高速缓存技术在突破网络服务器承载力局限性的同时, 扩大网络运营宽带用户认证计费系统的影响力, 以维护计算机网络工程和互联网运营企业的均衡发展。

在互联网工程中引入高速缓存技术, 将传统的互联网服务器扩展为互联网内存数据库, 这种技术维护, 有效的解决了磁盘数据库中CPU和磁盘之间的矛盾。目前我国应用的高速缓存技术的内存数据库设计简单, 且性能高效, 在减少互联网服务器负载的同时, 提高了网络服务器传输信息的响应速度, 对互联网综合性能的发展具有重要意义[2]。

2 内存数据库在高速缓存方面的应用

Cache即高速缓冲存储器, 其应用性能是提高网络服务器CPU和内存之间的缓存速度。在互联网运行过程中, 由于网络信息交流量巨大, 其主服务器CPU经常会出现信息输出延迟现象, 这种延迟等待是为了给网络内存数据库分析信息的时间, 当网络信息浏览量超过极限值时, 系统会因CPU数据交流信息过大而崩溃。应用高速缓存储存器的网络系统, 其信息数据缓存速度很快, 作为一种缓存介质, Cache很好的完成了系统设定的任务。

Cache主要分为本地缓存和远端缓存两大类, 其应用性能, 主要表现在以下几个方面: (1) 本地缓存, 是安装在互联网前端的前置机, 网络用户发出信息检索指令之后, 这个前置机会代替网络服务器接受用户请求, 并自动处理请求信息, 使网络信息数据内存与网络服务器保持自动同步更新状态; (2) 远端缓存, 这种缓存装置是安装在网络应用程序中的, 是一个计算机应用缓存组件。将内存数据信息与网络服务器应用紧密耦合。到目前为止, 仍有很多Cache内存数据模型不能完全设定主存, 会受到物理内存的限制, 这是所有内存数据库共同的限制。但还是可以将大量数据尤其是热点数据置于主存, 仍然可以充分发挥内存数据库的优势[3]。

3 基于内存数据库的应用探讨宽带用户认证计费相关内容

引进高速缓存技术后的互联网, 必须有一个完善的宽带用户认证机制作做支撑, 传统的网络用户认证模式和计费系统存在很多问题, 网络运营商无法实时掌握网络用户的计费收费情况, 所以建立一个集中式的宽带用户认证系统对网络运营企业至关重要, 其系统结构如图1所示。

通常情况下, 互联网采用以SHCP技术为核心的宽带用户认证系统, 因为DHCP技术的应用性能很好, 能够保证系统在复杂网络环境下安全、稳定的运行。从目前互联网环境下来看, 宽带用户认证系统不仅能够为网络运营商提供坚实的资金基础, 还能通过网络计费的方式将网络IP地址分配给各省市地区, 做到互联网系统的集中控制、分级管理。

计费中心能对所有互联网宽带用户进行统一管理、集中维护, 通过对互联网各系统业务的统一分析, 可以让网络运营商实时掌控宽带用户资费信息。与此同时, 宽带用户认证系统还可以支持分权分级, 各省市的网络用户开户、维护、收费等操作, 都需要宽带用户认证系统来完成。用户上网认证和授权由计费中心进行统一处理, 其资费信息会记入系统历史账单, 每月计费中心会通过核查这些历史账单, 检验其宽带用户认证系统是否完善, 是否存在漏洞。由此可见, 要想实现网络内存数据库的应用价值, 必须在创建高速缓存系统的同时, 维护宽带用户认证系统, 两者协调发展, 才是推动网络高速发展的主要动力[4]。

结论:本文通过研究Cache高速缓存技术和SHCP用户认证系统可知, 虽然Cache能够满足高响应速度的缓存需求, 但是随着缓存技术的不断发展, 内存数据库的应用形式会发生很大的改变, 要想使其不影响正常的网络运营, 保证网络运营的经济效益, 就必须建立一个完善、稳定的宽带用户认证系统。

摘要：近年来, 随着计算机网络技术的不断发展, 互联网内存数据库的缓存承载能力有了显著的提高, 扩展网络服务器的访问距离, 是提高网络运营稳定性的重要解决方案。Cache内存数据库是目前被广泛应用的内存数据库缓存技术, 其综合应用性能非常好。基于此, 本文对内存数据库在高速缓存方面的应用进行深入分析。

关键词：内存数据库,高速缓存,应用与研究

参考文献

[1]杨艳, 李炜, 王纯.内存数据库在高速缓存方面的应用[J].现代电信科技, 2011, 11 (11) :111-116.

[2]王心妍.Mencacahed和Redis在高速缓存方面的应用[J].无线互联科技, 2012, 11 (09) :134-145.

[3]牛晓晴.海量数据实时分析技术的研究与应用[D].北京邮电大学, 2013 (3) :145-156.

【内存数据库系统】推荐阅读：

内存数据09-27

从全站仪内存数据到AutoCAD图形的转换方法探讨06-15

内存管理系统06-12

基于内存的文件系统07-21

系统内存使用率05-27

Linux系统内存使用经验08-21