内存数据库系统

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

内存数据库系统 第1篇

计算机硬件的快速发展带来了多核技术, 这使得并行编程真正得以实现[1]。为了使并行编程模型中的各进程相互协作, 目前有如下几种技术:信号量、消息队列、共享内存和socket。信号量是初始值非负的整数值, 在信号量上的操作只有两种:加和减, 在操作中要保证信号量一直非负[2]。消息队列是一个消息链表, 具有添加消息权限的进程可以向其添加消息, 有获取消息权限的进程可以从其中取得消息。由于消息队列比信号量的信息更为丰富, 所以可以用于更复杂的情况[3]。共享内存技术则是开辟一块特殊内存区域, 使得不同进程可以共享这块内存进行读写操作, 其优势在于通过共享内存进程间可以交换大批量数据。Socket编程是不同机器进程间通信的基本方法, 当然也可用于同一机器的进程间通信。

1 共享内存的原理

在多任务操作系统中, 进程的地址空间是相对独立的, 相互并不影响, 就是说相同的一个地址, 在不同的进程中, 对应有不同的数据。这样每个进程的地址空间就变大了, 而且安全性也提高了。进程的地址空间是虚拟的地址空间, 在读写内存时, 需要内存管理单元 (MMU) 将虚拟内存映射到实际的物理内存。但是, 当进程间需要交换大量数据时, 需要多个进程使用同一块物理内存, 而不是每个进程都保留共享数据的一个拷贝。这个功能的实现是通过将不同进程的虚拟内存页映射到同一个实际内存页上。不同的操作系统提供了不同的API函数实现共享内存的操作。在linux下主要有有两个函数:

Void*mmap (void*start, size_t length, int prot, int flags, int fd, off_t offset) ;

Int munmap (void*start, size_t length)

其中, mmap函数用于创建共享内存, munmap则是取消共享内存的映射。在windows下创建共享内存、解除内存映射则分别用CreateFileMapping和UnmapViewOfFile函数[4]。在.net framework下, 没有API用于内存映射, 所以, 需要在.net代码中调用以上所列c函数, 完成内存映射。

2 内存数据库介绍

内存数据库就是将数据放入内存中直接操作的数据库, 与传统的数据库有很大不同, 主要在于传统数据库的数据主要存在硬盘上, 而内存数据库的数据主要存放于内存中。因为硬盘的io读写速度远慢于cpu和内存读写, 因此, 传统数据库在读写方面的主要研究点在于尽量减少硬盘的读写次数, 而内存数据库的主要研究点在于快速算法、并行操作等保证实时性数据存取方面。

3 共享内存在内存数据库系统中的应用实例

内存数据库用多进程保证并行操作, 这便需要这多个进程共享内存中的数据, 而数据库数据通常是庞大的, 因此共享内存在内存数据库中有很好的应用价值。在内存数据库中应用共享内存进行数据的加载与共享操作如图1所示。

内存数据库的数据仍然要存储于硬盘上, 实例所用数据均存储于一个文件内, 文件格式则是程序中既定的。在启动数据库时, 整个文件将被加载到内存中。加载结束后, 后台读写进程启动。每个进程启动后, 都将用共享内存映射函数将进程地址映射到内存数据库的数据地址。这样, 这些进程将同时操作一块内存, 而不是每个进程都有一个数据拷贝。至于读写的同步问题, 数据文件中设置有一个位图, 用来监控内存中数据的可用信息。当进程需要读写内存数据时, 首先将查看位图, 以找出数据可用与否的信息, 然后再进行真实读取。位图信息的同步则通过信号量来控制。

4 结论

内存数据库因为其实时性被用于嵌入式系统、电信计费、股票交易等行业领域, 并取得了良好的效果。内存数据库的概念出现在20世纪90年代, 目前已经有较为成熟的内存数据库产品产生, 如oracle的TimesTen。但是商业内存数据库的价格昂贵, 而且内存数据库技术仍在发展阶段。因此, 进行内存数据库的研究和探索还是很有意义的。

参考文献

[1]Dagum L, Menon R.IEEE COMPUTATIONAL SCIENCE &ENGINEERING.CA 94043 USA: IEEE COMPUTER SOC, 1998.

[2]S.Rao Kosaraju.LIMITATIONS OF DIJKSTRA’SSEMAPHORE PRIMITIVES AND PETRI NETS[J].ACM SIGOPS Operating Systems Review, 1973, 7 (4) :122-126.

[3]William Gropp, Ewing Lusk, Anthony Skjellum.Using MPI:portable parallel programming with the messagepassing interface[M].The MIT Press, 1999:3-11.

内存数据库系统 第2篇

内存条常见故障及排除方法

内存条有问题，常引起电脑运行不稳定，比如：开机后主机一直报警；系统经常蓝屏、死机、重启等。常见的内存故障及排除方法如下：

1、内存氧化

内存氧化，就会与插槽接触不良，造成开机时主板检测不到内存而报警。一般是主板上内存插槽灰尘多，或是内存金手指氧化，影响内存与插槽接触。

解决办法：

拔下内存，用橡皮仔细擦拭金手指，然后小毛刷清理内存插槽中灰尘，有条件的话，再用吹风机吹一下(注：是专用的吹电脑的吹风机，不时理发店用的吹风机)。

2、内存兼容性。

如果电脑更换内存后，出现电脑运行不稳定，可以先在BIOS中，调整内存参数，如：内存延迟、内存频率等。如果调整后，故障仍旧，则可能内存与主板兼容性差，只有更换内存。如果新增加内存后，电脑出现问题，同样，先修改内存参数，如果不行，说明内存与主板兼容不好，或是新内存与原内存不兼容，需要换内存条。

3、内存条损坏。

如果电脑只有一根内存条，通过修改内存参数，故障仍旧，可能内存条损坏了，更换好的内存条即可。

内存数据库系统 第3篇

海事卫星业务进入高速发展时期, 市场需求驱动市场部推出新的业务。本文针对海事卫星系统面对的挑战, 实时处理的要求, 研究探讨内存数据库 (MDB) 在该系统中的应用, 内存数据库应该如何设计及其实际应用和技术创新。内存数据库把数据全部或者当前工作部分驻留在内存中, 消除了传统磁盘数据库系统中I/O瓶颈, 极大地提高了系统的性能和吞吐量, 从而满足目前和将来系统面临的业务数据挑战。

2内存数据库服务设计实现

2.1系统架构

M DB分为M DB框架和M DB业务库, 系统架构如图1所示。

框架独立于业务逻辑, 增加其复用性, 通过接口能适配任何符合接口的MDB业务库, 并提供动态加载和卸载MDB业务库的功能, 能实现无缝加载和卸载。同时业务库开发也将不再关心MDB基础部分的实现, 能将主要开发放在业务相关的实现上。

2.1.1框架

实现基础的和业务无关的部分, 管理系统资源, 提供接口给MDB业务库。

⊙管理MDB表、打开MDB、关闭MDB。

⊙理与客户端通信的socket、共享内存、信号等。

⊙响应客户端消息处理逻辑。

⊙管理MDB业务库, 支持动态的加载业务库, 卸载业务库等。

⊙为MDB业务库提供基本的数据, 并对数据做初始化, 提供接口给业务库查询和更新这些数据。

⊙提供用户锁和进程锁资源, 提供锁操作接口, 并监控用户锁的超时信息, 在线程退出时自动清除此线程占用的锁。

2.1.2业务库

实现业务相关的部分, 注册支持的消息和业务类型, 接受客户端的应答请求, 对请求包做校验, 响应业务库的业务请求, 并做应答。一个业务库在物理实现上是一个动态库。

2.2索引算法

主流的存储引擎索引算法主要有btree和hash两种。

(1) Hash索引优缺点。优点是检索效率非常高, 索引的检索可以一次定位;缺点是不能使用范围查询, 只能“=”, “IN”和“<=>”查询。

(2) Btree优缺点。优点是适合范围查询, 所有叶节点具有相同的深度, 等于树高h, 其查找节点个数的渐进复杂度为O (logd N) , N为节点数, d为出度;缺点是存储空间过大, 插入删除平衡带来性能的损耗。

Hash索引结构的特殊性, 其检索效率非常高, 索引的检索可以一次定位, Hash索引的查询效率要远高于BTree索引。由于海事卫星运营系统是针对用户来说的, 业务数据基本上围绕用户产生的, 数据比较分散, 用户之间关联不多, 所以选择hash作为存储的索引算法。

2.3日志管理

日志分系统日志、redo日志、undo日志三种。

(1) 系统日志。主要记录系统运行日志、如通信日志、错误日志、接口日志等。

(2) Redo日志。记录DML操作的数据、操作对象、操作方法, 用于在系统恢复过程中, 重做已提交事务。

(3) Undo日志。记录DML操作前的数据, 用于在事务Abort时回退事务。

系统维护全局Redo日志序列, 而不维护Undo日志, 由事务自身维护私有的Redo日志和Undo日志。在事务提交时, 依照事务提交的先后顺序, 同步Redo日志数据到硬盘, 释放Undo日志。

2.4并发管理

并发度的多少一般和锁的类度有关, 所以把锁分等级处理, 不同的操作用不同的锁, 一般DML用记录锁, 这样可以提高并发度。

(1) MDB记录锁类似于行锁, 支持对MDB表中记录的关键字加锁, 防止该关键字相关的记录进行并发操作, 提高程序的准确性和安全性。

(2) 进程锁是控制M DB整个进程的锁, 在MDB作内存数据备份点的时候, 需要加上进程锁, 阻止此时发生的业务交易。

(3) 为了防止上面两种锁造成的死锁, 提供了锁检测工具, 支持对记录锁和进程锁超时情况查询, 并提供解锁服务。

2.5事务处理

事务处理的隔离级别为Read Commited, 即读提交, V为排他锁, S为共享锁, 写的时候为V锁, 读为S锁。

SELEC T的时候无法重复读, 即同一个事务中两次执行同样的查询语句, 若在第一次与第二次查询之间时间段, 其他事务又刚好修改了其查询的数据且提交了, 则两次读到的数据不一致。

事务的ACID属性只能通过限制数据库的同步更改来实现, 从而通过对修改数据加锁来实现。直到事务触发COMMIT或ROLLBACK语句时锁才释放。缺点是后面的事务必须等前面的事务完成才能开始执行, 吞吐量随着等待锁释放的时间增长而递减, MDB通过行级锁来最小化锁竞争。这样修改同一table里其他行的数据没有限制, 而且读数据可以始终没有等待。

事务设计原则是保证事务短小;锁的行越少越好, 时间越短越好。

2.6故障恢复

故障恢复流程如图2所示。

⊙MDB (SLAVE) 运行为恢复模式。

⊙启动MDB开始恢复。MDB在恢复时每次恢复完一批redo日志, redo目录下面对应的redo文件会被移动到back目录。

⊙MDB基础库redo目录下的redo文件全部移到back目录, 同时查看基础库运行的log日志, 当抛出读取下一个redo日志文件不存在的异常时表明MDB已经全部恢复完成。

⊙停止备MDB, 自动将最新的MDB数据写到磁盘文件。

⊙将备MDB产生的恢复后的MDB内存映像文件拷贝到主MDB目录, 启动既完成整个恢复过程。

3海事卫星业务运营系统应用

3.1功能定位

海事卫星业务运营支撑系统, 主要有计费、帐务处理、信用控制、帐务管理四个模块, 这几个模块都有很多数据操作, 有实时的, 有量大的, 而这些数据基本上都是存储在传统数据库里, 严重影响运营支撑系统的业务处理能力。所以会选择部分比较重要的数据放在MDB里面, MDB会给这四个模块提供增删改查操作, MDB与四个模块的交互结构如图3所示。

系统为计费、帐务处理、帐务管理、信用管理模块提供实时的数据操作。计费从MDB中取用户信息, 实时更新帐单到MDB;帐务处理更新周期性费用和一次性费用;帐务管理查询用户实时帐单;信用管理也是查询实时帐单。

(1) 融合计费本身实现了四个方面的融合:客户的融合, 即客户品牌和付费方式的融合;业务的融合, 即实现跨业务、跨产品、跨客户的产品捆绑、交叉优惠, 实现业务经营与计费策略的完整衔接;计费模式的融合, 即将计费提速、OCS实现融合;最后则是计费对象的融合, 即预付费和后付费的融合统一。

(2) 帐务处理是指根据三户资料和订购计划计算出周期性费用以及一次性费用后, 将其和批价费用等费用综合优惠后生成实时话费和帐单的过程。

(3) 帐务管理子系统主要处理用户帐单生成后, 帐单相关的查询、打印、缴费、销帐以及用户预先交纳预存、押金的使用和管理等相关业务功能。

(4) 信控管理子系统实时运行, 检测用户的话单批价、帐户的实时缴费销帐、帐户的信用度调整。当以上信息变动时, 信控管理子系统接受触发话单或工单, 根据帐户的历史欠费、当月实时话费、帐户信用额度、帐户内余额进行计算。根据信控规则进行催缴、开机、提醒等动作。

3.2分析与应用

海事卫星业务运营系统分为BILLING计费系统和CRM系统, BILLING需要实时处理大量的数据, 而CRM一般面向运营人员, 操作量不会太大, 所以BILLING系统需要高效实时的性能。批价是计费系统的重中之重, 需要实时处理大量的话单, 这个过程涉及到查询用户资料, 用户套餐等用户信息, 更新免费资源和累计量。如果用传统的数据库, 则处理比较慢, 很难做到数据的实时更新, 因此用内存数据库来管理这些数据。下面从数据选型和部署方式进行详细分析。

3.2.1数据选型

把最关键的数据放到内存中, 这些数据增删改频次高, 频繁的IO读写, 严重影响性能。三户资料和帐务相关数据, 三户查询量特别的高, 帐户相关数据特别的多。所以这些数据都放入内存, 避免了频繁的IO处理, 提高了效率, 有选择地选取数据, 又节省了内存。

3.2.2部署方式

采用双机热备部署方式, 实现了高可用和负载均衡。双机数据通过日志同步, 外部查询对数据实时性要求不高的操作可以放在备机上, 更新操作放在主机上。

3.3性能指标

海事卫星应用mdb后, 处理能力有很大的提升, 以下是性能测试数据。

主机环境:

测试性能数据:数据插入效率为10w/s;8w/s的数据更新效率;据装载平均加载速度110Mb/s;恢复速度平均每秒7w次事务。

3.4应用效果

采用内存数据库后, 运营数据得到实时的处理, 批价可以实时的更新累计量和帐单, 信控可以直接取得内存数据库中的实时话费累计表中的数据, 完全实现实时预警、停机。对防欺诈、收入保障系统也有相当大的好处, 这样能够充分保证海事卫星运营商的切身利益。

4结束语

内存数据库在海事卫星的应用, 极大地提高海事卫星运营系统的处理能力, 内存数据库, 通过避开磁盘的耗时操作, 内存优化的索引结构快速的日志和恢复, 高并发的事务处理, 达到了高性能的数据管理能力, 低成本的基础上大大提高系统的处理能力。大量的数据操作通过内存数据库集中管理, 也增强了海事卫星运营系统的扩展能, 能够满足海事卫星未来几年的业务发展。

摘要：本文探讨研究了内存数据库的系统架构、索引算法、日志管理、并发管理、事务处理、故障恢复等, 说明了内存数据库如何在海事卫星运营系统中发挥作用。

关键词：内存数据库,索引,事务,海事卫星

参考文献

[1]张晓伟.探讨分布式内存数据库的设计与应用[J].硅谷, 2009 (03)

[2]王慧嫔.基于MMDB技术对电信计费系统研究与实现的探讨[J].科技资讯, 2009 (16)

[3]王金华, 江水, 吴娴, 卢瑶, 龙刚.轻量级内存数据库的研究[J].计算机工程, 2008 (S1)

[4]王珊, 肖艳芹, 刘大为, 覃雄派.内存数据库关键技术研究[J].计算机应用, 2007 (10)

内存数据库系统 第4篇

1。物理内存

a.总数 系统的物理内存的容量，其中一部分内存被硬件占用

b.已缓存是指系统所加载的内容

c.可用表示应用程序能够直接使用的可用物理内存容量

d.空闲表示当前物理内存中新近释放出来的容量，

2。核心内存

a.分页数内核模式的组件位于页面文件的容量(被分页交换到页面文件中的内容)

b.未分页表示内核模式的组件位于物理内存的容量

3。系统

a.提交分别表示当前使用的虚拟内存数，以及系统所有的内存数

内存数据库系统 第5篇

关键词：共享内存,高可用性,数据库,内存数据库,TimesTen

1、引言

目前大型电信IT系统对于高频访问数据多采用‘物理数据库+共享内存’的部署模式, 即将数据库表数据上载至内存中, 并对数据区建立索引来提高访问性能。由于共享内存与数据库无法在一个事务内提交, 数据的完整性和一致性难以得到保障, 此外还存在代码开发量大, 系统开发周期长, 逻辑结构复杂等弊端。

为此, 可考虑在电信IT系统中引入商用内存数据库产品来搭建数据管理单元。这种模式具备系统更易维护、开发周期短、程序开发和移植灵活便捷、数据的安全性和完整性可得到保障等优势。

2、TimesTen内存数据库介绍

TimesTen内存数据库最早起源于1992年HP实验室针对电信网络应用的研究项目, 并在1996年因此创建TimesTen公司并同年发布第一个商业版本 (TimesTen 2.0) 。TimesTen公司于2005年被Oracle公司收购, 随后推出TimesTen 6.0版本。目前, Oracle TimesTen的最新版本为2009年8月份发布的TimesTen 11G版本。

TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中, 它利用标准的SQL接口对完全位于物理内存中的数据存储区进行操作, 并提供了TT Tools、SQL Developer、Oracle Enterprise Manager等GUI工具供用户对TimesTen进行管理。

TimesTen内存数据库在确保系统的高可用性方面, 有两个重要特点:

·可与oracle后台数据库做无缝集成, 数据可以在TimesTen和oracle直接双向流动, 数据的更新内容可以做到实时同步;

·可做成多节点并行提供服务的模式, 数据在多个TimesTen内存数据库之间直接实现实时或者非实时的传输, 进一步提高了系统的扩展性和可靠性。

TimesTen产品包有以下3个组件:

·Oralce TimesTen In-Memory Database (主产品)

·Cache Connect to Oracle (可选件)

用于数据在TimesTen内存数据库与Oracle数据库间复制, 支持‘只读’、‘自动刷新’ (oracle到timesten) 、‘可更新’ (timesten到oracle) 等多种数据同步机制。

·Replication–TimesTen to TimesTen (可选件)

用于数据在多个TimesTen内存数据库间复制, 复制支持‘异步’、‘半同步’、‘完全同步 (Return two safe) ’3种模式。

3、TimesTen的数据持久性以及高可用性

TimesTen作为一个内存数据库, 所管理的数据完全放置在内存中, 那么它的数据持久性如何保持, 并且如何确保高可用性呢?

首先, TimesTen的数据持久性通过物理磁盘上的DataStore文件和Log文件保持。在内存数据库中的每一个操作, 都会先缓存在内存的LogBuffer中, 然后由后台的守护进程异步地同步到磁盘上的Log文件中。TimesTen可定时 (每隔一段时间) 或定量 (脏日志量达到一定值) 触发一次Checkpoint, 将内存中变化的数据增量写到磁盘上的DataStore文件中, 然后清除掉已经同步过的Log文件。当主机掉电或者其它故障情况下, TimesTen可以通过这些文件进行自动恢复。

对于系统的高可用性, 如果是单个节点, TimesTen可以通过设置参数DurableCommits=1来保证不会有任何的数据丢失, 即每次内存数据库的提交都强制性同步到磁盘上 (缺省为异步方式) 。但在这种情况下, 内存数据库写的性能将会受到很大影响。正常情况下, DurableCommits参数默认设置为0, 也就是TimesTen只在时间达到或缓冲区满的情况下才将缓冲区数据写入磁盘, 应用的事务处理不会因为写磁盘而受阻, 这样内存数据库能提供最佳性能。

TimesTen通过Replication机制解决了性能与高可用性无法兼得的矛盾问题。通过Replication, TimesTen在多个内存数据库节点间能保持数据的自动高效同步, 这种方式确保了当一个节点出现故障时数据不会因为未及时写入磁盘而丢失。

多个TimesTen节点之间有Active-Standby Pair, Active-Active, Active-Standby-Disaster Recovery等多种模式可以选择。其中, Active-Standby-Disaster Recovery模式为传统的Active-Standby Pair模式下再外挂上一个灾备中心, 即通过‘生产中心+灾备中心’的方式进行在线容灾。

4、TimesTen内存数据库的典型部署架构

采用TimesTen内存数据库Active-StandbyDisaster Recovery模式搭建的应用系统, 其内存数据库的部署架构如图1所示。从架构图中可以看到, 应用系统的数据管理单元由生产中心以及灾备中心构成, 灾备中心的数据通过Replication代理从生产中心复制而来。

从图1中可以看出, 生产中心由主用TimesTen内存数据库 (Active Master) 、备用TimesTen内存数据库 (Standby Master) 、Oracle数据库组成, 灾备中心由灾备TimesTen内存数据库 (Disaster Master) 和灾备Oracle数据库组成。主用内存数据库上的数据通过TimesTen的Replication代理同步复制到备用内存数据库上, 再由备用内存数据库负责将数据异步复制到Oracle数据库以及灾备内存数据库中。

其中, 主用内存数据库到备用内存数据库的复制方式为完全同步, 以确保数据在主、备内存数据库的一致性, 以保证数据安全性, 内存数据库数据到Oracle数据库、到灾备中心的复制由备用内存数据库负责, 以降低数据复制对主用内存数据库性能的影响。

在图1中, 应用与内存数据库在物理上分开部署, 应用通过C/S连接方式访问内存数据库, 可以确保内存数据库主机CPU不受应用影响。应用更改主用内存数据库上数据时, 数据复制到备用内存数据库节点, 并由备用内存数据库节点复制到灾备中心。在整个架构中, 只有主用内存数据库节点有更新数据的权限。

当主用内存数据库发生故障时, 系统由备用内存数据库接管, 原备用内存数据库变更为主用内存数据库 (该步骤必须在原备用内存数据库中由应用程序自动执行或人工执行存储过程‘call ttRepStateSet (‘active’) ;’更改原备用内存数据库角色为主用) , 数据发生更新时, 仍然由该节点继续同步到灾备中心。当原主用内存数据库恢复时, 它的角色将自动更改为备用内存数据库。

当备用内存数据库发生故障时, 数据在主用内存数据库上发生更新时, 将由主用内存数据库将数据复制到灾备中心内存数据库上。在备用内存数据库恢复之后, 将自动从主用内存数据库追加复制数据。

5、应用案例:利用TimesTen搭建省级电信ABM系统

余额管理中心平台系统 (Account Balance Management, ABM) 作为电信计费域核心业务支撑系统之一, 部署和管理了电信用户的档案、配置、余额、累积量等4类数据, 并向包括在线计费系统 (Online Charging System, OCS) 、离线计费系统 (Hot Billing, HB) 、统一充值系统 (Voucher Center, VC) 等在内的各外围业务支撑系统提供接口统一的数据访问服务。系统在提供高效访问服务的同时, 还必须具备高稳定性, 并确保数据的高安全性。为此, 系统引入TimesTen内存数据库并采用Active-Standby-Disaster Recovery模式搭建数据管理单元, 建立数据生产中心与灾备中心。

余额管理中心平台系统的系统架构如图2所示。

从图2可以看出, 收发应用、业务处理应用以及TUXEDO服务均通过Client/Server方式连接访问Active Master上的数据。Active Master上余额及累积量数据的更新内容通过完全同步的方式同步到Standby Master上, 而后Standby Master将更新内容异步更新到ORACLE数据库中。为减轻Active Master到Standby Master的数据复制压力, 它们的只读数据 (档案、配置数据) 分别从Oracle数据库中通过Cache Connect to Oracle工具进行上载。

生产过程中产生的余额支出、余额来源数据、累积量明细数据以及其它生产日志数据需要通过自开发应用程序从内存数据库中迁移至Oracle数据库中。

档案、配置、余额、累积量等4类数据均由Standby Master复制到容灾备份中心的内存数据库Disaster Master中, 并由后者复制到灾备中心的Oracle数据库中。

该余额管理中心平台系统设计规划承载500万在线计费用户、3000万离线计费用户。系统已于2010年6月在中国电信某省公司部署上线, 已承载超过300万在线计费用户及1800万离线计费用户, 至今运行状况良好。

6、结束语

利用内存数据库开发搭建电信IT系统可极大缩短开发周期, 程序开发和移植也更灵活便捷, 系统也更易维护。但受制于内存数据库主机的内存大小限制, 内存数据库可部署管理的数据容量远比物理数据库要小, 所以实际应用中多采取内存数据库与物理数据库配合共用的方式。

参考文献

[1]Oracle TimesTen Oracle TimesTen in-memory databaserecommen-ded programming practices release 6.0 2011

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

内存数据库系统 第6篇

内存数据库(MMDB:main memory database)是一种现代数据库技术,它在数据规模上无法和传统硬盘数据库相比,但在某些特定专业领域,如:电力和电信网络、金融、集成办公系统等很多实时性要求高的行业中,内存数据库系统发挥的作用已经越来越重要。随着内存价格的不断下降和内存容量的不断增长,尤其是64位操作系统的出现,使内存数据库从规模和技术上都将得到充分的发展和提升。内存数据库的理论研究已经进行了二十多年,但对内存数据库的定义却存在着多种观点,典型的观点有以下几种:

(1)整个数据库全部常驻内存,存取数据时没有I/O操作。

(2)内存不必足够大到容纳整个数据库,但数据被存取时,先进入内存,数据库的存取在内存进行。

(3)数据库常驻磁盘,在事务执行前,将所需要的数据集中调入内存,提交时所有对数据库的修改必须写回磁盘。

(4)数据库常驻磁盘,但内存有很大的缓冲区或高速缓存,因而使数据库的大部分乃至全部驻留内存,通过适当的缓冲区处理以减少内外存I/O操作。

在国内,对内存数据库比较权威的定义如下:

定义:设有数据库系统DBS,DB为DBS中的数据库,DBM(t)为在时刻t,DB在内存的数据集,DBM哿DB。TS为DBS中所有可能事务的集合,AT(t)为在时刻t处于活动状态的事务集,AT(t)哿TS。Dt(T)为事务T在t时刻所操作的数据集,Dt(T)哿DB,若任意时刻t,均有:

坌T∈AT(t),Dt(T)哿DBM(t)

成立,则称DBS为一个内存数据库系统(Main Memory Database System),简写为MMDBS,DB为一个内存数据库,记为MMDB。

对于这个定义,用直观的话说,内存数据库系统就是数据库的“工作版本”常驻内存的数据库系统。

2 索引与数据组织

内存数据库的物理组织是其总体设计目标(使内存和CPU的利用率尽可能高)的实现基础,其存储结构、索引结构、中间数据存储结构都必须考虑内存的直接存取这一特征,本文采用了桶散布Hashing的方式来实现物理数据组织。

创建索引可以大大提高应用的系统性能,可以加快数据检索速度,可以加速表与表之间的连接,可以减少分组和排序的时间。虽然MMDB速度比硬盘数据库(DRDB,Disk Resident Database)快得多,但是为了减少数据访问时的比较次数,最大化的提高MMDB性能,MMDB也都采用了索引技术。索引结构是MMDB使用最广泛的组织方式,索引结构可以分两大类,一类是树结构,一类是Hash结构。B树和B+树是磁盘数据库中广泛使用的索引技术,能最大化的减少I/O,但空间的利用率仅为60%左右,其较低的空间利用率不适合于内存数据库。目前研究的内存数据库索引技术还有T树索引、AVL树索引、SB树索引、CSS树、BD树等树结构索引技术,而Hash的缺点在于它不支持范围索引。各种索引优缺点不同,在不同的情况下使用。

针对移动垃圾短信监控系统的特性,由于所有的数据分析是基于源手机号码,那么也就是说存储数据库记录时,只基于存储源号码的数据分析结果进行存储,不用对号码范围进行检索,也就屏蔽了Hash不支持范围索引的缺点,所以本文采用了Hash+链表的索引结构。内存数据库的索引中并不存储真实的属性值,而仅仅存储指向元组的指针,当需要的时候通过这些指针能够得到属性值。

3 垃圾短信监控系统中链接桶哈希索引的设计

Hash技术在信息系统的数据存储与访问中占有重要的地位,是信息系统中广泛使用的数据存储和访问技术。数据库中广泛使用的哈希索引有链接桶哈希(chained bucket hashing)、可扩展哈希(extendible hashing)、线性哈希(linear hashing),其中链接桶的哈希使用静态结构处理冲突,速度很快,但不适合动态环境。基于等值的比较,哈希技术能够快速的访问数据库,且易于实现,但不支持范围检索。而垃圾短信监控系统数据库不涉及范围的检索,数据的更新非常频繁,因此,系统采用了链接桶哈希索引,并且针对系统的实际情况做了相应的改动。

由于系统中针对每个数据分析模块都建立相应的数据结构,并且所有的数据访问都通过指针来进行,所以系统为内存数据库的链接桶哈希索引建立一个索引空间-即模值空间inthash_t和一个节点空间inthash_node_t。模值空间是Hash索引的入口,该空间不存储任何实际记录数据,仅仅存储一个指向节点链表首地址的指针。节点空间存储具体的记录数据和一个指向下个节点的指针,该指针用来指向一个经哈希函数计算产生冲突的下一节点,用指针方式可形成一个节点冲突链表。

模值空间即Hash索引入口是个散列桶,它的初始大小是一个固定的值。而节点空间是不固定的,每增加一个节点都在内存中申请相应大小的空间,利用指针链接到相应链表中来。

哈希索引入口数据结构如下:

4 垃圾短信监控系统中链接桶哈希的算法

4.1 初始化哈希入口空间

初始化一个哈希入口空间表的算法如下:

输入inthash_t*tptr/*指向一个Hash入口空间的指针*/

int buckets/*用于定义入口空间桶数的参数,取数=2的N次方*/

步骤如下:

这里把tptr->size与参数buckets做比较,当tptr->sizesize左移一位(即把入口空间桶数2),掩码左移一位再加1,位移数减少1。

为入口空间桶分配内存。

4.2 查找记录

查找记录的算法如下:

4.3 插入记录

插入记录的算法如下:

4.4 删除记录

插入记录的算法如下:

4.5 哈希表空间的扩展

当记录数达到桶数的时候,索引空间必须要扩展,这里通过哈希表的重建函数,实现了桶哈希的空间扩展。扩展算法如下:

5 结论

根据移动短信监控系统中内存数据库的特点,设计了用于内存数据库的HASH+链表索引,并应用于内存数据库系统中。基于内存数据库技术实现的移动公司垃圾短信监控平台,满足了系统在性能、业务、灵活、实时方面的要求。

摘要：文章研究了内存数据库管理系统的原理和关键技术,根据移动短信监控系统中内存数据库的特点,设计和实现了一个基于Hash+链表索引的专用型内存数据库系统,用于解决垃圾短信分析系统中海量短信的存取问题。

关键词：垃圾短信系统,内存数据库,HASH索引

参考文献

[1]刘云生.现代数据库技术[M].北京:国防工业出版社,2001:238-314.

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

[3]阳国贵,王升,张火炬,等.内存数据库系统与技术[J].软件学报,1994,5(3):22-28.

[4]Phil Bernstein,Michael Brodie,Stefano Ceri,et al..The Asilomar Reporton Database Research[J].ACMSigmod Recorf,1998,27(4):74-80.

[5]David J DeWitt,Randy H Katz,Frank Olken,et al.I,mplementationtechniques for main memory database systems[C].Proc,ACMSIGMODConf,1984:1-8.

[6]Tobin J.Lehman,Michael J.Carey,A Study of Index Structures for MainMemory Database Management Systems[C].Proceedings of the TwelfthInternational Conference on Very Large databases,Kyoto,August,1986:294-303.

[7]实时数据库技术[EB/OL].http://www.tongji.edu.cn/~yangdy/research.html.杨东援教授个人主页.

内存数据库及其应用综述 第7篇

传统的磁盘数据库(DRDB,Disk-Resident Database)需要频繁访问磁盘来进行数据操作,当数据量大、操作频繁且复杂时,暴露出的问题越来越多[1]。随着内存容量的不断增加,计算机操作系统地址空间得到更大支持,用户对数据库系统实时响应能力的要求不断提高。充分利用内存技术提升数据库性能成为近年来的研究热点。

内存数据库是一种使用内存作为主存储空间的数据库。与传统以磁盘为基础的硬盘数据库相比,内存数据库的最大优势在于可以大大提高数据存取速度。

1 常见内存数据库

1.1 TimesTen

TimesTen是一款基于内存的关系型数据库,具有良好的持久性和可恢复的特性[2]。最初由惠普实验室(Hewlett-Packard labs)于1996年独立开发,2005年被oracle收购。它可以与现有oracle数据库进行对接,与oracle数据库有良好的兼容性,为两种数据库之间的数据迁移提供了很好的支持。此外,TimesTen不仅可以作为独立的数据库使用,也可以作为现有oracle硬盘数据库的内存缓存。TimesTen的加速示意图如图1所示。

其持久性和可恢复性由检查点和事务记录实现,每一次操作对应的事务都会经内存缓存后保存至磁盘的事务log。到达指定时间或出现脏数据后触发检查点,将硬盘备份数据更新为内存中的版本并清除事务记录。当出现断电或故障时,数据库可以通过事务log、检查点记录和硬盘备份的数据恢复数据库内容[3,4]。

1.2 IBM SolidDB

SolidDB是由IBM开发的关系型内存数据库,因其快速存取的性能被广泛使用。其结合内存数据库的高速存取和硬盘数据库大量存取空间的特性。其数据库操作引擎主要包含为存取硬盘而设计的DBE(disk-based engine)和为存取内存设计的MME(main-memory engine)。为了提高内存数据库的存取性能,MME使用了与B+树类似的Vtrie(可变长度字典树)索引和内存索引并发控制,以进一步提高响应速度和并发度[5]。

与TimesTen比,IBM SolidDB不仅可以提供良好的内存数据库存取引擎,也为现有诸多数据库产品提供了数据库二级缓存。并且在sql语句和存储过程支持方面都有更好的兼容性。但是在扩展性上由于没有很好的处理机制(TimesTen使用Cache Grid机制来扩展数据节点),所以扩展性欠佳。

1.3 Redis

Redis是一个基于内存的键值对的开源数据库(非关系型数据库)。目前,可以通过快照(将数据以异步方式从内存存储至硬盘)或AOF格式的日志(记录数据集的修改操作)来保证其持久性。

由于本身是基于内存的数据库,其存取速度快。此外,它还支持丰富的数据结构,包括set、list、hash、string等。其缺点也很明显,如作为内存数据库无法保证其持久性(现有方法性能较差)、内存占用偏大、不提供计算节点扩展(目前仅支持单机使用)等问题。

1.4 Altibase

Altibase完全遵循ACID原则,与现有诸多内存数据库比较,Altinase支持触发器(TimesTen不支持)、存取函数(SolidDB不支持)、PHP驱动(SolidDB不支持)、连接(Nosql不支持)。

1.5 SQLite

SQLite是一款轻量级的关系型数据库。由于依赖较少的外部包(基于C语言标准,且仅调用其中的7个库函数),具有良好的独立性。设计中不存在服务进程,通过其提供的库函数直接存取数据文件,SQLite在安装中不需要服务器配置这一环节。

大部分情况下,其使用硬盘作为主要存储空间,经过配置后可以建立临时的内存数据库。由于缺乏持久化的处理,所以关闭连接后内存数据库就会消失。SQLite提供的主要服务并非内存数据库。另外,与SQLite类似的还有MongoDB,即提供内存数据库的支持,但不提供持久性的维护。

2 内存数据库的基础技术

2.1 并发控制

对于并发控制处理,内存数据库使用的方法大多和硬盘数据库类似。由于内存数据库响应时间快,所以其对应的锁占用时间也较短,因此并发导致的冲突也相对要少很多。关于内存数据库并发控制,文献[6]提出了近似串行的解决方法。即在提交写请求后对整个数据库加锁,在前一个任务存储到硬盘之前允许下一个任务操作,并保证未提交的数据不会被读取。在以读为主的数据库和以更新为主的数据库上,该策略分别为原有策略最大吞吐量的7倍和2倍。

2.2 内存索引

对于内存数据库而言,使用标准数据库的B+树方法进行索引会对其性能产生一定制约。因为基于硬盘的数据库在进行存取时要首先考虑存取次数和存取数据量问题,而这两者在内存数据库中无需特别处理。现行内存数据库中IBM SolidDB提出了专门的内存数据库引擎用以解决此问题。在IBM SolidDB中,使用了可变长度的字典树,其数据结构类似于B+树。与传统B+树索引相比,存储空间的存取操作次数明显增加,但可以降低其操作的时间复杂度,相比于硬盘而言更适合内存操作。此外,使用字典树在进行遍历时,因为处理的主要数据结构为字典树中节点存储的指针数组,相比于B+树的类似于链表的结构,CPU在处理数组时可以减少cache失效的情况。

3 内存数据库常见问题及其解决方法

3.1 持久性问题

对于内存数据库而言,其最明显的问题就是持久性问题。由于数据存储于内存中,所以遇断电、故障很容易丢失数据[7]。此问题对于没有持久性策略的数据库而言尤为突出。现有解决持久性问题的方法主要是使用内存快照保存数据库某一时刻的数据内容(类似于检查点),以及递增的数据库操作修改记录维护数据库修改内容。其中,前者的问题在于快照速度太慢,对于实时性应用不适用;而后者的问题在于数据库操作记录增长太快,简单的数据库操作记录往往会比数据库本身要大很多。

现行内存数据库采用的方案通常结合上述两种策略,定期维护数据库快照,同时在数据库运行时维护数据库操作记录,每一次建立新的数据库快照后都要将数据库操作记录清空。

3.2 容量限制问题

内存数据库的使用将会占用大量的内存空间,给操作系统带来了很大压力。对于普通服务器,如果使用内存数据库将被占用较大内存,进而导致其它进程资源受到限制。在这种情况下,最常见的处理方法是服务器使用swap分区,但会导致数据存取速度大大降低。

对此问题,现有最容易接受的解决方法就是使用内存数据库本身作为硬盘数据库的缓存。通过对内存和硬盘数据库部分数据同步,将部分硬盘数据保存在内存中,从而使存取速度接近内存,存取容量接近硬盘。

3.3 数据恢复问题

由于内存数据库的数据很容易丢失,所以数据恢复非常重要,而内存数据库的数据恢复时间较长,不仅需要更新所有内存数据,还要从磁盘上获取数据。

对于内存数据库,写日志到磁盘是系统的瓶颈,现有解决方法是使用稳定内存,其操作快,并由专门的进程将日志刷新到磁盘。对于没有稳定内存的系统,采用群提交的方式将日志写到一块内存缓冲区,并一次刷新到磁盘,完成批量事务提交。数据恢复时,采用超高带宽恢复机制,重新加载所有内存数据。

4 结语

内存数据库具有高效的存取速度、良好的并行控制和优异的吞吐量。然而,由于缺乏持久性和占用内存容量,一定程度上制约其广泛应用。虽然内存价格普遍降低,但对大型数据库而言,内存数据库成本仍较大,较好的折中方案是使用内存数据库作为硬盘数据库的缓存,降低内存数据库的成本。

摘要：随着互联网的发展,用户对网络系统的访问越来越多,能支持大用户量对网络系统进行并发访问且具有高响应速度特点的内存数据库系统备受关注。综述几种常见的内存数据库,探讨内存数据库常见问题及其解决方法。

关键词：内存数据库,并发访问,响应速度

参考文献

[1]武振宇.内存数据库及其在实时计费系统中的应用[J].电信工程技术与标准化,2012,25(3):62-65.

[2]SCHROEDER M.Philadelphia exchange turns to timesten[J].Securities Industry News,2002.

[3]曹猗宣.内存数据库的研究及其应用[D].北京:北京邮电大学,2011.

[4]易国洪.内存数据库中恢复技术研究[J].科技广场,2007(3):106-109.

[5]LINDSTROM J,RAATIKKA V,RUUTH J,et al.IBM solidDB:in-memory database optimized for extreme speed and availability[J].IEEE Data Eng.Bull.,2013,36(2):14-20.

[6]BLOTT S,KORTH H F.An almost-serial protocol for transaction execution in main-memory database systems[C].Proceedings of The 28th International Conference on Very Large Data Bases.VLDB Endowment,2002:706-717.

内存数据库系统 第8篇

关键词：内存数据库,Timesten,自动数据清理

数据清理是一种清理不再使用的数据的操作。这种清理又可分为根据时间值来清理老数据和清理在一段时间未被使用的数据两种情况。如清理昨天的航班时刻表(数据过时24小时),清理有一段时间未曾登陆的用户信息。

而TimesTen7.0之前版本则面临着这样的挑战:一些TimesTen客户需要在自己的应用中实现数据清理机制,但是在应用层很难实现基于使用的数据清理,当前Cache Connect中的数据清理支持也不够充分。

1 TimesTen对自动数据清理的支持

TimesTen 7.0和去年新发布的TimesTen 11g两个版本均支持2种自动数据清理技术:基于时间的数据清理-根据时间戳来判断基于使用的数据清理-根据LRU算法来判断。

1.1 基于时间的数据清理

基于时间的数据清理需要一个时间戳列,该列的值由应用更新。基于时间的数据清理的策略是为数据指定“LIFETIME”-数据在多少时间之后被清理,指定清理周期“CYCLE”-每隔多少时间对数据是否需要清理进行检测。

LIFETIME可设置为DAY,HOUR,或者MINUTE,“LIFETIME 3 DAYS”不同于“LIFETIME 72 HOURS”。比如:保持3天的航班信息;假设今天是星期三,那么今天的所有数据将在星期六删除(删除一天的数据);保持电话记录72小时;超过72小时的记录将会被删除(删除数据的多少取决于CYCLE)。

基于时间的数据清理示例:创建表T1,当某一行的c1列的值超过8小时时,该行将被清理,清理间隔是30分钟。

LIFETIME:表示多少时间以后该数据需要被清理,CYCLE则表示每隔多长时间需要进行清理检测。

基于时间清理方面,有一些用法技巧。不同的表有着不同的清理策略和属性,这要依赖业务需求。如有需求是保留表1的数据3天,每8小时检测一次,而保留表2的数据30分钟,每5分钟检测一次。我们可以使用基于时间的清理技术实现滑动窗口,也可以人工控制清理进程,比如:避开业务高峰期安排数据清理。

1.2 基于使用的数据清理

基于使用的数据清理是根据LRU算法来判断的,需要2个级别的清理属性:在表级指定清理策略,为数据库指定阀值。如:

其中AgingCycle值表示每隔多长时间进行一次清理检测,如果该数据库的使用次数少于HighUsageThreshold值,清理操作不会进行。

2 总结

数据清理从Replication方面考虑,对于Active-Standby方式,Standby必须是Active的完全复制,Active节点的数据清理操作会复制到Standby,Replication会强制双方遵循同样的清理策略。如果由于错误恢复而切换了节点,清理自动在新的ACTIVE节点打开。对于其他方式的复制技术,清理策略是在本地节点配置,各个节点的数据清理操作互不相关并且不会复制。

从Cache Group考虑,几乎所有的cache group类型都支持数据清理技术,以下情况除外:不支持物化视图的详表的约束清理,AUTOREFRESH cache group不支持基于使用的清理技术。

Oracle Timesten 7.0内存数据库在电信、证券、金融等海量数据存储行业,对性能要求高的系统中已经得到较为广泛的应用,了解并掌握它的自动数据清理机制,对更高效地使用这种数据库技术是大有好处的。

参考文献

[1]凯特.Oracle9i&10g编程艺术:深入数据库体系结构[M].北京:人民邮电出版社,2006

[2]Loney K.Oracle Database 10g完全参考手册[M].北京:清华大学出版社.2006

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

[4]易国洪.内存数据库中恢复技术研究[J].科技广场,2007,10(3):106.

内存数据库系统 第9篇

内存数据库 (MMDB, Main Memory DataBase) 是一种将数据完全加载到内存并在内存中实现对数据进行管理的数据库。MMDB对数据库的体系结构进行重新设计, 没有采用传统的磁盘数据管理, 对数据组织结构、索引技术、并行操作等方面进行了相应改进, 有效地解决了基于磁盘的数据库中CPU和磁盘I/O之间的主要矛盾, 和传统基于磁盘的数据库相比, 数据读写速度高出几个数量级, 能够极大地提高应用的性能。MMDB具备基于磁盘数据库的所有特性, 如数据库的定义、存储、维护等数据的持久化管理, 数据增删查改及完整性检查等操作, 事务调度与并发控制, 数据存取的控制和安全性检验, 数据的可靠性恢复机制。

索引影响着数据库的执行效率, 同样, 索引结构在很大程度上决定访问内存数据库的效率等各方面的性能。最常见的B+树由于受节点远大于Cache Line和节点中需存储大量的指针数据等因素的影响, 其Cache访问性能较差。针对此种情况, 一些学者提出了Cache敏感的索引树结构, 比较常见的有CSS树、CSB+树和T树。Cache访问性能是影响MMDB性能的重要因素之一, 而在共享Cache多核处理器条件下, 如果只采用单线程模式执行索引访问, 势必不能充分发挥CMP的并行计算资源;而传统的多线程执行方式, 即每个索引访问线程都需要执行自顶向下的索引遍历, 则会由于CSB+-Trees的根节点层及其子节点层中的节点被重复访问的概率要远大于其它节点层中的节点, 导致索引访问时的时间局部性和空间局部性较差, 而且底层节点数据更容易将项层节点数据替换出共享Cache, 造成共享Cache访问冲突。同时, 由于CSB+树节点较小树高较大, 更降低了线程访问索引数据时的局部性。因此, 以传统的多线程执行方式访问索引, 线程的Cache访问性能不佳, 影响了索引访问的性能。

随着集成电路CMOS制造工艺的持续提高, 单个门电路的尺寸都在不断变小, 基于半导体的微电子技术的物理极限问题成为一个重要的设计所关心的问题。物理极限的影响造成了散热及数据同步问题。对于更复杂、处理能力更强的处理器的需求促使处理器设计人员利用各种各样的可行方案提高处理器的性能。处理器主频、内存访问速度和I/O速度发展不同步已经成为很大的瓶颈, 单纯依靠提高处理器主频来提升整个系统的性能已经不可行, 并行计算技术成为解决之道。线程级并行TLP计算技术对于很多应用场合都是合适的, 它通过利用多个独立的CPU来提高系统的性能。时至今日, 集成电路技术的发展及减少系统占用面积的要求最终促使了多核处理器的出现。多核多线程处理器是通过支持单片多处理器 (CMP) 和同时多线程 (SMT) 的组合来实现的。多核多线程处理器由多个简单的同时多线程处理器核构成, 它提供了一种更加简单有效的方法去提高集成度。它不同于超标量处理器通过硬件来提取指令级的并行, 是通过编译器的支持, 多核多线程处理器可以提供一种线程级的并行。由于它由多个简单的同时多线程处理器, 所以它就可以拥有单片多处理器主频高、设计和验证时间短的优势, 又拥有同时多线程资源利用率高的优势, 从而大大提高程序的运行效率。目前, 越来越多的芯片生产商和研究机构都将注意力放在了多核多线程处理器的研究上。正是因为多核与多线程技术的大量使用, 使得处理器处理能力能跟上时代发展。

2、相关研究[1]

索引影响着数据库的执行效率, 同样, 索引结构在很大程度上决定访问内存数据库的效率等各方面的性能。由于等值查询最为常用, 所以缓存敏感的索引结构通常用来加速查询的速度。以下是常见的3种缓存敏感索引结构。

T树:T树在较早的时候提出, 改善了B+树浪费内存空间的问题, 由于高度过大, 没有做缓存优化, T树的缓存性能还不如B+树。

CSS树:它是Array索引的一种改进, 通过连续存储方式, 去除了节点和数据项的指针, 提高了对缓存的利用率。但树的连续存储方式限制了其动态更新的能力, 因此, CSS树比较适合于数据相对静态的OLAP领域。

C S B+树:它是在B+树的基础上对缓存做优化, 只在节点头部保存了一个指向下层节点组的指针。同时, 兄弟节点之间建立组的概念并连续存储, 通过指针和偏移量定位子节点。这样的设计提高了缓存的利用率, 减少了查询过程中缓存失效的次数。然而, CSB+树的不足在于节点大小都控制在一个缓存块左右, 一般为64Byte和128Byte, 当索引项数很大时, CSB+树的深度很大, 在查询路径上会带来更多的TLB失效问题。

3、相关工作

3.1 基于CMP的CSB+-Trees访问性能优化

基于CMP进行优化, 充分利用多核处理器的并发能力, 需要对原有的索引进行并发改进。首先, 改进索引结构, 将单路查询转为多路查询, 每一路查询用独立的线程处理。然后, 分解每个查询或更新任务, 如并行处理二分查找过程等。最后, 对于批量查找或者更新的任务, 将任务分组, 并行处理每个任务组。

任务池是MSI编程模型的基本组成部分, 同一个任务池中的多个任务可以由不同的线程并行执行。多个任务池可以相互连接, 以描述流水线或其他拓扑结构的任务池依赖关系。如一个包含3个任务池的流水线结构.当任务池1中的子任务执行完成以后, 得到的中间结果便会传给任务池2, 并由任务池2执行再产生中间结果, 如此类推, 直到最后一个任务池执行完任务并输出最终结果, 由此把任务变成流水线式地执行.在此过程中, MSI中的线程调度器将根据各个任务池的负载情况动态调度每个任务池将CSB+树中的节点划分为多个工作集后, 使得基于流水线式多线程执行模式的索引访问时, 每个操作对应的索引访问线程所需处理的索引数据少于传统多线程方式, 减少了底层索引数据将上层索引数据替换出Cache的机率, 从而降低了共享Cache访问冲突, 改善了索引访问时的时间局部性和空间局部性。

执行同一操作的索引访问线程之间, 由于线程执行的运算较少, 索引访问线程l将索引访问线程2将要访问的数据读入最低一级Cache后, 在索引访问线程2访问这些Cache Line之前, 它们被替换出Cache的机率相对较低, 提高了执行相同操作线程间的数据共享。

3.2 基于流水线的CSB+-Trees多线程访问模块

基于流水线式多线程执行模式的C S B+树多线程访问模块, 该模块可用于需要访问索引的查询对应的Q E P执行。该模块与QEP中其它节点的接口为键值缓存, QEP中的投影选择节点为该访问模块提供查找索引的键值即可以基于CSB+-Trees的索引嵌套循环连接为例。QEP中的投影.选择节点将表A中元组的连接列生成键值存入键值缓存 (Key Buffer) qa。其中的CSB+树多线程访问模块对应于QEP中的Key Join和TID Join节点。该模块内部组织成流水线执行模式, 并根据CSB+-Trees的树结构层次设置流水线中的操作。将CSB+树中的节点按照树结构层次分成若干个线程工作集, CSB+-Trees的根节点及其子节点划为工作集WorAgetl, 第三层节点和叶节点层组成工作集WorkSet2。流水线则设置两个操作:Opcratorl和Operator2, Operatod和Operator2对应的索引访问线程分别负责访问WorkSetl和WorkSet2。CSBT-MAM执行时, 流水线中Operatorl对应的索引访问线程访问键值缓存获取键值, 以键值为参数搜索WorkSetl中的节点, 然后将节点指针连同键值存入指针缓存 (Pointer Buffer) 中;Operator2对应的索引访问线程即要从指针缓存中获取键值和节点指针访问余下的索引节点, 也需要获得表B的Tuple ID (T/D) 直接访问表B, 并将结果放入输出缓存 (Output Buffer) 。其中, 所有缓存均采用Parallel Buffer结构, 使得C S B T-M A M的适应性更强, 即使投影-选择操作同样采用多线程执行模式, CSBT-MAM也不会因内存访问而成为整个QEP执行的性能瓶颈。

4、结语

在多核环境下, 存储介质的访问延迟和分支预测错误的延迟在索引的查询和更新所消耗时间中仍占有较大的比重, 有效地减少这些延迟, 对提高索引的整体性能有着重要的作用。增强索引操作的并发性是利用多核处理器特性提高索引性能的重要手段.主要可以从改进索引结构、分解单个查询或更新任务、将批量查询或者更新任务分组等方面入手。

参考文献

[1]Rao Jun, Rosa Kenneth A.Cache conscious indexing for de-cisionsupport in main memory.Proceedings of the 25th VLDB Conference.Edinburgh, Scotland, UK, 1999:78-89.

[2]欧阳炜昊, 李灿辉, 钟山.内存数据库索引技术研究[J].科技创新导报, 2010, 29:25.