精华内容
下载资源
问答
  • 内存数据库

    2018-03-15 09:39:48
    实现词法分析和语法分析的内存小容量数据库,主要用于学习编译原理
  • 而随着这些年硬件的发展,现在服务器拥有几百G内存并不罕见,此外由于NUMA架构的成熟,也消除了多CPU访问内存的瓶颈问题,因此内存数据库得以出现。内存的学名叫做RandomAccessMemory(RAM),因此如其特性一样,是...
  • 一、内存数据库:  在SQLite中,数据库通常是存储在磁盘文件中的。然而在有些情况下,我们可以让数据库始终驻留在内存中。最常用的一种方式是在调用sqlite3_open()的时候,数据库文件名参数传递”:memory:”,如: ...
  • 一、内存数据库:  在SQLite中,数据库通常是存储在磁盘文件中的。然而在有些情况下,我们可以让数据库始终驻留在内存中。常用的一种方式是在调用sqlite3_open()的时候,数据库文件名参数传递":memory:",如:  ...
  • Windows内存数据库extremeDB入门经典,这是当下讲解extremeDB比较全的文档了
  • 自制内存数据库C#

    2018-01-31 15:51:23
    所有数据库都保存到内存中,可以做大型游戏数据库,效率相当高,可以存储复杂数据
  • NULL 博文链接:https://qindongliang.iteye.com/blog/2136239
  • 一、内存数据库:  在SQLite中,数据库通常是存储在磁盘文件中的。然而在有些情况下,我们可以让数据库始终驻留在内存中。最常用的一种方式是在调用sqlite3_open()的时候,数据库文件名参数传递”:memory:”,如: ...
  • 本篇文章主要介绍了springboot整合H2内存数据库实现单元测试与数据库无关性,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
  • Delphi内存数据库

    2016-03-18 12:17:23
    在内存中创建数据库,然后在创建表及编辑操作。 将内存数据库保存到文件中
  • 问数据库的需求,将数据库核心数据驻留在内存中,可以使用内存数据库来满足需求。Hash 索引是数据库系统中广泛使用的索引技术之一, 它能够快速地访问数据,易于设计和实现。该文根据内存数据库的特点,为电信网管...
  • 本文首先介绍了嵌入式内存数据库技术现状,然后简单介绍了内存数据库技术的特点等并提出了一个适用于3G平台的嵌入式内存数据库引擎,随着计算机技术的高速发展和人们对信息处理速度不断增长的需求,大容量的内存...
  • H2 Database(H2内存数据库)

    千次下载 热门讨论 2013-08-15 23:55:53
    H2就不做很多介绍了。资源包内容列表是我进行H2预研是收集的H2资料,应该是最全面的的了: ...10、H2内存数据库h2部署操作手册.docx 11、H2内存数据库安装与维护.doc 12、H2数据库基础知识.docx 13、H2数据库使用.doc
  • Delphi使用SQLite3内存数据库

    热门讨论 2014-11-11 16:22:58
    Delphi使用SQLite3,包括本地数据库和内存数据库,本地数据库加载到内存,内存数据库备份到本地,使用sqlite simple delphi包装类。
  • 微软SQL Server 2014提供了众多激动人心的新功能,但其中最让人期待的特性之一就是代号为” Hekaton”的内存数据库了,内存数据库特性并不是SQL Server的替代,而是适应时代的补充,现在SQL Server具备了将数据表...
  • 内存数据库白皮书.rar

    2019-08-22 10:59:42
    内存数据库白皮书.rar,是学习数据库与大数据的最好学习资料
  • MySql_内存数据库

    2013-06-30 21:07:40
    MySql的内存数据库的信息 数据库基本操作
  • SQL SERVER内存数据库

    2017-03-02 14:22:23
    详细描述了SQL SERVER内存数据库的各种特性和限制,并列举了典型的实例
  • 相信大家对内存数据库的 概念并不陌生,之前园子里也有多位大牛介绍过SQL内存数据库的创建方法,我曾仔细 拜读过,有了大致了解,不过仍有很多细节不清晰,比如:  (1)内存数据库是把整个数据库放到内存中的吗?...
  • 高性能内存数据库Redis(基础篇)
  • 常用内存数据库的比较

    热门讨论 2011-08-10 08:40:23
    什么是内存数据库,常用内存数据库,SQLite最佳试用场合,哪些场合适合使用其他的关系型数据库,内存数据库之比较,性能测试
  • 常用内存数据库介绍

    万次阅读 2018-07-09 23:18:55
    1. 内存数据库简介 1.1 概念 一、什么是内存数据库 传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database)。磁盘数据库需要频繁地访问磁盘来进行数据的操作,...

    1. 内存数据库简介

    1.1 概念

    一、什么是内存数据库

    传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database)。磁盘数据库需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)时间的影响,当数据量很大,操作频繁且复杂时,就会暴露出很多问题。

    近年来,内存容量不断提高,价格不断下跌,操作系统已经可以支持更大的地址空间(计算机进入了64位时代),同时对数据库系统实时响应能力要求日益提高,充分利用内存技术提升数据库性能成为一个热点。

    在数据库技术中,目前主要有两种方法来使用大量的内存。一种是在传统的数据库中,增大缓冲池,将一个事务所涉及的数据都放在缓冲池中,组织成相应的数据结构来进行查询和更新处理,也就是常说的共享内存技术,这种方法优化的主要目标是最小化磁盘访问。另一种就是内存数据库(MMDB:Main Memory Database,也叫主存数据库)技术,就是干脆重新设计一种数据库管理系统,对查询处理、并发控制与恢复的算法和数据结构进行重新设计,以更有效地使用CPU周期和内存,这种技术近乎把整个数据库放进内存中,因而会产生一些根本性的变化。两种技术的区别如下表:

    内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上,更重要的是,从根本上抛弃了磁盘数据管理的许多传统方式,基于全部数据都在内存中管理进行了新的体系结构的设计,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,从而使数据处理速度一般比传统数据库的数据处理速度快很多,一般都在10倍以上,理想情况甚至可以达到1000倍。

      而使用共享内存技术的实时系统和使用内存数据库相比有很多不足,由于优化的目标仍然集中在最小化磁盘访问上,很难满足完整的数据库管理的要求,设计的非标准化和软件的专用性造成可伸缩性、可用性和系统的效率都非常低,对于快速部署和简化维护都是不利的。

    2. 内存数据库历史和发展

    一、雏形期
    从上个世纪60年代末到80年代初。在这个时期中,出现了主存数据库的雏形。1969年IBM公司研制了世界上最早的数据库管理系统——基于层次模型的数据库管理系统IMS,并作为商品化软件投入市场。在设计IMS时,IBM考虑到基于内存的数据管理方法,相应推出了IMS/VS Fast Path。Fast Path是一个支持内存驻留数据的商业化数据库,但它同时也可以很好地支持磁盘驻留数据。在这个产品中体现了主存数据库的主要设计思想,也就是将需要频繁访问,要求高响应速度的数据直接存放在物理内存中访问和管理。在这个阶段中,包括网状数据库、关系数据库等其他各种数据库技术也都逐渐成型。
    二、技术理论成熟期
    1984年,D J DeWitt等人发表了《主存数据库系统的实现技术》一文。第一次提出了Main Memory Database(主存数据库)的概念。预言当时异常昂贵的计算机主存价格一定会下降,用户有可能将大容量的数据库全部保存在主存中,提出了AVL树、哈希算法、主存数据库恢复机制等主存数据库技术的关键理论,为主存数据库的发展指出了明确的方向 。
    1984年,D J DeWitt等人提出使用非易逝内存或预提交和成组提交技术作为主存数据库的提交处理方案,使用指针实现主存数据库的存取访问。
    1985年,IBM推出了IBM 370上运行的OBE主存数据库
    1986年,RB Hagman提出了使用检查点技术实现主存数据库的恢复机制。威斯康星大学提出了按区双向锁定模式解决主存数据库中的并发控制问题。并设计出MM-DBMS主存数据库。贝尔实验室推出了DALI主存数据库模型。
    1987年,ACM SIGMOD会议中提出了以堆文件(HEAP FILE)作为主存数据库的数据存储结构。Southern Methodist大学设计出MARS主存数据库模型。
    1988年普林斯顿大学设计出TPK主存数据库。
    1990年普林斯顿大学又设计出System M主存数据库。
    三、产品发展期和市场成长期
    随着互联网的发展,越来越多的网络应用系统需要能够支持大用户量并发访问、高响应速度的的数据库系统,主存数据库市场成熟
    半导体技术快速发展,半导体内存大规模生产,动态随机存取存储器(DRAM)的容量越来越大,而价格越来越低,这无疑为计算机内存的不断扩大提供了硬件基础,使得主存数据库的技术可行性逐步成熟
    1994年美国OSE公司推出了第一个商业化的,开始实际应用的主存数据库产品Polyhedra
    1998年德国SoftwareAG推出了Tamino Database。
    1999年日本UBIT会社开发出XDB主存数据库产品。韩国Altibase推出Altibase
    2000年奥地利的QuiLogic公司推出了SQL-IMDB
    2001年美国McObject推出eXtremeDB。加拿大Empress公司推出EmpressDB


    四、几种主存技术应用的比较
    第一代:用户定制的主存数据库。通过应用程序来管理内存和数据;不支持SQL语句, 不提供本地存储, 没有数据库恢复技术;性能好但很难维护和在别的应用中不能使用;应用在实时领域比如工厂自动化生产。
    第二代:简单功能的内存数据库。能够快速处理简单的查询;支持部分的 SQL语句和简单的恢复技术;主要目的是能够快速处理大量事务;针对简单事务处理领域,尤其是交换机, 移动通信等。
    第三代:通用的主存数据库。针对传统的商业关系型数据库领域,能够提供更高的性能、通用性以及稳定性;提供不同的接口来处理复杂的SQL语句和满足不同的应用领域;可以应用在计费、电子商务、在线安全领域,几乎包括磁盘数据库的所有应用领域。
    五、目前几种常见的通用内存数据库
    eXtremeDB:eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库,只有50K到130K的开销,速度达到微秒级。eXtremeDB完全驻留在主内存中,不使用文件系统(包括内存盘)。eXtremeDB采用了新的磁盘融合技术,将内存拓展到磁盘,将磁盘当做虚拟内存来用,实时性能保持微秒级的同时,数据管理量在32BIT下能达到20G。
    Oracle TimesTen:Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库,它为应用程序提供了实时企业和行业(例如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中,它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。
    SolidDB:Solid Information Technology 成立于 1992 年,全球总部位于加州Cupertino,
    Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能紧密地融为一体。

    ALTIBASE公司从1999年就一直致力于内存数据库软件和其应用的开发,提供高性能和高可用性的软件解决方案。特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。目前占据80%以上内存数据库市场,可以说是当今数据库软件技术的领导者。目前Altibase在国内成功案例也比较多,尤其是在电信行业,已经得到了广泛认可.

    4. 常用内存数据库

    4.1 SQLite

    SQLite是一个小型的C程序库,实现了独立的,可嵌入的,零配置的SQL数据库引擎。特性包括:

    • 事务操作是原子,一致,孤立,并且持久的(ACID),即使在系统崩溃和电源故障之后。
    • 零配置——不需要安装和管理。
    • 实现了绝大多数SQL92标准。
    • 整个数据库存储在一个单一的文件中。
    • 数据库文件可以在不同字节序的机器之间自由地共享。
    • 支持最大可达2T的数据库。 (241 字节)
    • 字符串和BLOB类型的大小最大可达 2G 字节(231字节)。
    • 小的代码: 完整配置的少于250KB,忽略一些可选特性的少于150KB。
    • 在大多数常见操作上比流行的客户/服务器数据库引擎更快
    • 简单,易于使用的API
    • 内建TCL绑定 另外提供可用于许多其他语言的绑定。
    • 具有良好注释的源代码,95%经过测试。
    • 独立:没有外部依赖。
    • 源代码位于公共域。 可用于任何用途。

    SQLite发行版包含一个独立的命令行访问程序(sqlite),可用于管理SQLite数据库,并适合作为一个如何使用SQLite库的例子。

    License: SQLite使用Public domain授权(注),对于个人使用和商业使用都是免费的。

    技术上的优点和特性
    SQLite是一个轻量级、跨平台的关系型数据库。


    ◇轻量级

    先说它的第一个特色:轻量级。想必SQLite的作者很看重这个特性,连它的Logo都是用的“羽毛”,来显摆它的轻飘飘。SQLite和C/S模式的数据库软件不同,它是进程内的数据库引擎,因此不存在数据库的客户端和服务器。使用SQLite一般只需要带上它的一个动态库,就可以享受它的全部功能。而且那个动态库的尺寸也挺小,以版本3.6.11为例,Windows下487KB、Linux下347KB。

    ◇ 绿色软件

    SQLite的另外一个特点是绿色:它的核心引擎本身不依赖第三方的软件,使用它也不需要“安装”。所以在部署的时候能够省去不少麻烦。

    ◇单一文件

    所谓的“单一文件”,就是数据库中所有的信息(比如表、视图、触发器、等)都包含在一个文件内。这个文件可以copy到其它目录或其它机器上,也照用不误。

    ★技术上的缺点和不足

    ◇并发访问的锁机制
    SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操作独占,从而导致其它读写操作阻塞或出错。

    SQL标准支持不全
    在它的官方网站上,具体列举了不支持哪些SQL92标准。我个人感觉比较不爽的是不支持外键约束。

    ◇网络文件系统(以下简称NFS)
    有时候需要访问其它机器上的SQLite数据库文件,就会把数据库文件放置到网络共享目录上。这时候你就要小心了。当SQLite文件放置于NFS时,在并发读写的情况下可能会出问题(比如数据损坏)。原因据说是由于某些NFS的文件锁实现上有Bug。

    ★编程语言接口
    SQLite支持很多种语言的编程接口。这对于我这种喜欢混用多种编程语言的人来说,是很爽的。下面我大概介绍一下。

    ◇C/C++
    由于SQLite本身是C写的,它自带的API也是C接口的。所以C/C++用起来最直接了。假如你不喜欢面向过程的C API风格,可以另外找个C++的包装库。想重新发明轮子的同学,也可以自己包装一个。
    ◇Java
    如果要用Java访问SQLite,可以通过SQLite的JDBC驱动,或者通过专门的SQLite包装库。我个人建议走JDBC方式,万一将来要换数据库,代码就不用大改。
    ◇Python
    pysqlite是Python操作SQLite的首选。从Python 2.5开始,它已经被整合到Python的标准库中。看来Python社区还是蛮喜欢SQLite嘛。
    ◇.Net
    对于喜欢.Net的同学,可以通过SQLite的ADO.NET驱动来访问。
    ◇Ruby
    Ruby可以通过SQLite-Ruby操作SQLite数据库,不过我没用过。
    ◇Perl
    在CPAN上有DBD::SQLite,不过我也没用过。

    ★一些非技术的参考因素

    需要根据“如何选择开源项目”里面提到的几个参考因素,再评估一下。
    ◇授权协议(License)
    SQLite使用的是Public Domain协议,这是最爽一种,可以放心大胆地用。
    ◇用户的普及程度
    最近这几年,使用SQLite的人越来越多。包括一些大公司也开始把它整合到产品中(比如Google的Gears、Apple的Safari、Adobe的AIR)。
    ◇开发的活跃程度
    如果到SQLite的Change Log上大致了解一下,可以看出最近5年基本上每1-2个月都会有更新。说明开发的活跃度还是非常高的。

    SQLite不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化:

    • 易于管理
    • 易于使用
    • 易于嵌入其他大型程序
    • 易于维护和配置

    许多人喜欢SQLite因为它的小巧和快速. 但是这些特性只是它的部分优点, 使用者还会发现SQLite是非常稳定的. 出色的稳定性源于它的简单, 越简单就越不容易出错. 除了上述的简单、小巧和稳定性外, 最重要的在于SQLite力争做到简单化.

    简单化在一个数据库引擎中可以说是一个优点, 但也可能是个缺点, 主要决定于你想要做什么. 为了达到简单化, SQLite省略了一些人们认为比较有用的特性, 例如高并发性、 严格的存取控制、丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展, 超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性, 那么SQLite也许就不适合你了. SQLite没有打算作为一个企业级的数据库引擎, 也并不打算和Oracle或者PostgreSQL竞争.

    仅凭经验来说SQLite适用于以下场合: 当你更看中简单的管理、使用和维护数据库, 而不是那些企业级数据库提供的不计其数的复杂功能的时候,使用SQLite是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择.

    4.1.1 SQLite最佳试用场合

    · 网站

    作为数据库引擎SQLite适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说, 如果一个网站的点击率少于100000次/天的话, SQLite是可以正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证明, 即使是10倍的上述流量的情况下SQLite依然可以正常运行.

    · 嵌入式设备和应用软件

    因为SQLite数据库几乎不需要管理, 因此对于那些无人值守运行或无人工技术支持的设备或服务, SQLite是一个很好的选择. SQLite能很好的适用于手机, PDA, 机顶盒, 以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序.

    · 应用程序文件格式

    SQLite作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数,并且标记一个显式本地事务的起始点(BEGIN TRANSACTION)来保证以独占的方式得到文件的内容. 文件保存将执行一个提交(COMMIT)同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的.

    数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码.

    · 替代某些特别的文件格式

    许多程序使用fopen(), fread(), 或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择.

    · 内部的或临时的数据库

    对于那些有大量的数据需要用不同的方式筛选分类的程序, 相对于编写同样功能的代码, 如果你把数据读入一个内存中的SQLite数据库, 然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据, 通常会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性, 因为添加新的列或索引不用重写任何查询语句.

    · 命令行数据集分析工具

    有经验的SQL用户可以使用SQLite命令行程序去分析各种混杂的数据集. 原是数据可以从CSV(逗号分隔值文件)文件中导入, 然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果.

    当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite的好处是: SQLite的部署更为简单并且结果数据库是一个单独的文件, 你可以把它存储在软盘或者优盘或者直接通过email发给同事.

    · 在Demo或测试版的时候作为企业级数据库的替代品

    如果你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite数据库引擎静态的连接到客户端程序当中,从而内嵌SQLite作为混合的数据库支持. 这样客户端程序就可以使用SQLite数据库文件做独立的测试或者验证.

    · 数据库教学

    因为SQLite的安装和使用非常的简单(安装过程几乎忽略不计, 只需要拷贝SQLite源代码或sqlite.exe可执行文件到目标主机, 然后直接运行就可以) 所以它非常适合用来讲解SQL语句. 同学们可以非常简单的创建他们喜欢的数据库, 然后通过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统(RDBMS)的高层次的学生, 按照模块化设计且拥有很好的注释和文档的SQLite源代码, 将为他们打下良好的基础. 这并不是说SQLite就是如何实现其他数据库引擎的精确模型, 但是很适合学生们了解SQLite是如何快速工作的, 从而掌握其他数据库系统的设计实现原则.

    · 试验SQL语言的扩展

    SQLite简单且模块化的设计使得它可以成为一个用来测试数据库语言特性或新想法的优秀的原型平台

    4.1.2 哪些场合适合使用其他的关系型数据库管理系统(RDBMS)

    · 客户端/服务器程序

    如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以通过网络文件系统工作, 但是因为和大多数网络文件系统都存在延时, 因此执行效率不会很高. 此外大多数网络文件系统在实现文件逻辑锁的方面都存在着bug(包括Unix 和windows). 如果文件锁没有正常的工作, 就可能出现在同一时间两个或更多的客户端程序更改同一个数据库的同一部分, 从而导致数据库出错. 因为这些问题是文件系统执行的时候本质上存在的bug, 因此SQLite没有办法避免它们.

    好的经验告诉我们, 应该避免在许多计算机需要通过一个网络文件系统同时访问同一个数据库的情况下使用SQLite.

    · 高流量网站

    SQLite通常情况下用作一个网站的后台数据库可以很好的工作. 但是如果你的网站的访问量大到你开始考虑采取分布式的数据库部署, 那么你应当毫不犹豫的考虑用一个企业级的客户端/服务器数据库来替代SQLite.

    · 超大的数据集

    当你在SQLite中开始一个事务处理的时候(事务处理会在任何写操作发生之前产生, 而不是必须要显示的调用BEGIN…COMMIT), 数据库引擎将不得不分配一小块脏页(文件缓冲页面)来帮助它自己管理回滚操作. 每1MB的数据库文件SQLite需要256字节. 对于小型的数据库这些空间不算什么, 但是当数据库增长到数十亿字节的时候, 缓冲页面的尺寸就会相当的大了. 如果你需要存储或修改几十GB的数据, 你应该考虑用其他的数据库引擎.

    · 高并发访问

    SQLite对于整个数据库文件进行读取/写入锁定. 这意味着如果任何进程读取了数据库中的某一部分, 其他所有进程都不能再对该数据库的任何部分进行写入操作. 同样的, 如果任何一个进程在对数据库进行写入操作, 其他所有进程都不能再读取该数据库的任何部分. 对于大多数情况这不算是什么问题. 在这些情况下每个程序使用数据库的时间都很短暂, 并且不会独占, 这样锁定至多会存在十几毫秒. 但是如果有些程序需要高并发, 那么这些程序就需要寻找其他的解决方案了.

    方面

    具体要求

    必要条件

    详细描述

    License

    是否收费

    免费使用

    是否开源

    开源

    是否有技术支持

    主要是社区支持,如果需要专业支持需要购买

    商业目的的分发版本是否仍要收费

    免费

    其他

    性能

    数据容量支持100000条以上记录

    支持

    并发查询处理能力

    SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操作独占,从而导致其它读写操作阻塞或出错。

    查询速度

    修改速度

    平台支持

    32/64位

    全部支持

    Linux/window/UNIX/mobile

    支持Linux/Mac OS/Windows

    运行方式支持

    支持嵌入式

    支持

    支持独立运行

    不支持

    连接方式支持

    支持ODBC

    默认不支持,必须通过第三方的ODBC驱动

    支持JDBC

    默认不支持,必须通过第三方的JDBC驱动

    支持内存访问

    通过c接口(专用API)

    支持网络访问

    不支持

    SQL支持

    支持SQL

    支持

    支持Index,Trigger,

    Constrains,Views

    支持,有资料说其不支持外键约束。

    管理界面

    支持管理界面

    支持CLI

    管理界面友好程度

    较差

    4.2 Altibase

    Altibase™内存数据库管理系统(DBMS),内存数据管理系统的最新技术,是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。Altibase提供极限性能、容错能力和事务管理的方便性,特别是在通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度的发挥数据库服务系统的潜力,使用Altibase能大大增强您公司的数据服务器的处理能力。

    Altibase™内存DBMS为需要容错服务的系统提供实时数据库复制的功能。采用Altibase数据库复制的系统可以实现高性能、高可用性、数据库一致性、负载平衡和系统可伸缩性。如果您希望您的业务能够实现最大的成功,请在您的事务优先的系统中使用我们的Altibase数据库复制解决方案。

    资料比较少,且需要商业License,没有详细去研究

    4.3 Oracle 内存数据库系列 Berkeley DB 和 TimesTen

    Oracle是最重要的商业数据库产品提供商,它也有内存数据库的产品系列:主要就是Oracle Berkeley DB 和 Times Ten.前者是只支持嵌入式内存数据,后者是独立的内存优化数据库。

    4.3.1 Oracle Berkeley DB

    Oracle Berkeley DB是Oracle 收购了开源数据库厂商后推出的产品,其前身是Berkeley DB。它有开源版本,但且对于开源软件免费。商业版本是要付费。

    Oracle Berkeley DB 系列的可嵌入开源数据库为开发人员提供了无需管理的快速、可靠的本地持久性。Oracle Berkeley DB 系列通常部署为“前沿”数据库,为不需要 SQL 的应用程序用例提供很高的性能、可靠性、可伸缩性以及可用性。

    Oracle Berkeley DB 产品系列

    Berkeley DB — 事务处理式存储引擎,用于基本键/值数据结构中的非类型化数据 — 新增!版本 4.7 现已推出

    — 针对 Java 环境优化的纯 Java 版 Berkeley DB — 新增!版本 3.3

    Berkeley DB XML — 原生 XML 数据库,可基于 XQuery 访问容器中存储的文档,并根据其内容进行索引 — 新增!版本 2.4 现已推出

    4.3.2 Oracle TimesTen

    Oracle 内存数据库 TimesTen 是一个针对内存进行了优化的关系数据库,它为应用程序提供了当今实时企业和行业(如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。Oracle 内存数据库 TimesTen 作为独立或嵌入式数据库部署在应用层中,利用标准的 SQL 接口对完全位于物理内存中的数据库进行操作。它也可以用作 Oracle 数据库的内存中数据库缓存,以改进用户应用程序的响应时间和吞吐量。

    4.4 eXtremeDB

    eXtremeDB内存式实时数据库是为实时系统及嵌入式系统而特别设计的数据库。与同类产品不同,eXtremeDB不是通过 对企业数据库面向实时嵌入式应用进行剪裁而来;而是总结了30年来McObject公司在编译器、实时编程、数据管理、内核级驱 动软件等领域的经验,面向实时嵌入式应用从头开发的最新实时数据管理技术。

    eXtremeDB满足了您对实时数据库的一切期待:高级数据定义语言、并行访问、基于交易及灵活的索引… …等等。不仅如此,出乎您的意外,eXtremeDB在紧凑的引擎中还提供诸如事件触发、目标历史等等功能。

    eXtremeDB嵌入式数据库满足更多的实时开发的要求。

    · 最快的内存数据库。

    · 极小尺寸和极小的内存消耗

    · 多种索引支持

    · 高可用性-组合选项

    · 非常灵活的数据存储: 内存式,磁盘式或混合式

    · 多种应用接口: 两种 SQL, 两种更快的原始接口

    · 几乎牢不可破 -

    又一个商业内存数据库产品,这个特点是实时数据库,号称最快。

    4.5 H2 Database

    h2是Thomas Mueller提供的一个开源的、纯java实现的关系数据库,官方网站:http://www.h2database.com/html/main.html

    它的主要特性是:

    • 非常速的数据库引擎
    • 开源、免费数据库
    • 支持 JDBC和ODBC API,支持SQL
    • 支持嵌入式,服务器和集群模式。支持内存数据库。
    • 提供基于浏览器的管理控制台
    • 整个应用本身只有1MB左右。

    其他特性还包括

    • 基于磁盘或内存的数据库、表,支持只读数据库、临时表。
    • 两段式事务支持
    • 支持多个连接。表级别的锁。
    • 基于成本的优化,为复杂查询使用遗传算法,零管理。
    • 滚动的、可修改的result set支持。支持大结果集、外部结果排序。
    • 加密数据库(AES或XTEA),SHA-256密码加密。

    性能比较(摘自h2database网站)

    嵌入模式下H2的性能比较

    Test Case

    Unit

    H2

    HSQLDB

    Derby

    Simple: Init

    ms

    610

    657

    3187

    Simple: Query (random)

    ms

    297

    312

    1828

    Simple: Query (sequential)

    ms

    203

    266

    1766

    Simple: Update (random)

    ms

    1078

    1484

    22031

    Simple: Delete (sequential)

    ms

    234

    281

    7407

    Simple: Memory Usage

    MB

    6

    7

    11

    BenchA: Init

    ms

    859

    438

    4047

    BenchA: Transactions

    ms

    5266

    2875

    17500

    BenchA: Memory Usage

    MB

    9

    14

    10

    BenchB: Init

    ms

    4016

    2687

    16875

    BenchB: Transactions

    ms

    2609

    3282

    4250

    BenchB: Memory Usage

    MB

    9

    10

    8

    BenchC: Init

    ms

    891

    594

    5766

    BenchC: Transactions

    ms

    4359

    75438

    11718

    BenchC: Memory Usage

    MB

    9

    18

    9

    Executed statements

    #

    594255

    594255

    594255

    Total time

    ms

    20422

    88314

    96375

    Statements per second

    #

    29098

    6728

    6166

    .Net使用H2
    • 嵌入式应用。有一个项目在为.Net使用H2,使用CLI重新编译H2。还没有深入关注。
    • ODBC。但性能一般。

    4.5 其他内存数据库

    包括Derby, HSQLDB等.

    ——————————————————————————————————————————————————————-

    In-memory database in wikipedia: (http://en.wikipedia.org/wiki/In-memory_database)

    Products

    Product nameLicenseDescription
    Adaptive Server Enterprise (ASE) 15.5Proprietaryenterprise database from Sybase)[4]
    Apache DerbyApache License 2.0Java RDBMS
    AltibaseProprietaryhas in-memory and disk table; HYBRID DBMS
    BlackRayGNU General Public Licence (GPLv2) and BSD License
    CSQLGNU General Public Licence or proprietary
    DatablitzProprietaryDBMS
    EloqueraProprietaryIn-memory, In-memory:persist modes
    eXtremeDBcommercial productDBMS, also check out its open source PERST dbms.
    FleetDBMITNOSQL db with Writing to an append-only log to provide durability.
    H2Mozilla Public License or Eclipse Public Licensehas a memory-only mode
    HSQLDBBSD licensehas a memory-only mode
    IBM TM1Proprietaryin-memory BI and data analysis
    InfoZoomProprietaryin-memory BI and data analysis
    KDBProprietaryDBMS, also supports disk based data
    membaseApache LicenseNoSQL, hybrid
    MicroStrategy in-memory BI for MicroStrategy 9
    MonetDBMonetDB License
    MySQLGNU General Public License or proprietaryhas a cluster server which uses a main-memory storage engine
    Oracle Berkeley DBSleepycat Licensecan be configured to run in memory only
    Panorama for Windows and Macintosh, both single user and server versions
    ParAccelProprietaryin-memory, columnar, relational, ACID-compliant; disk-based mode as well
    Polyhedra IMDBProprietaryrelational, supports High-Availability; acquired in 2001 by ENEA
    QlikView BI-tool developed by QlikTech
    RDM EmbeddedProprietaryincluding hybrid
    RDM ServerProprietaryincluding hybrid
    RedisBSDNoSQL
    solidDB by IBM including hybrid, HSB-based HA, Shared memory, embedded, XA, etc.
    SAP HANA databaseProprietaryDatabase engine of the SAP In-Memory Appliance (SAP HANA) produced by SAP AG
    SQLitePublic domainhybrid, RAM and disk dbs can be used together
    Starcounter in-memory object relational dbms
    TimesTen by Oracle in memory only or as a cache for Oracle Database
    VertipaqProprietaryMicrosoft PowerPivot and Microsoft Analysis Services in-memory BI engine
    VoltDBGNU General Public License v3in-memory
    TREX search engine in the SAP NetWeaver integrated technology platform produced by SAP AG
    Xcelerix by Frontex commercial product

    展开全文
  • 1.系统在不断实时地访问数据库时,一秒钟对同一个表操作几千,几万次以上,导致数据表死锁或则处理太慢; 2.对数据实时计算,而且数据量很大时,比如电信系统的电信的二次批价和实时累账 3. 需实时统计数据,监控...
  • 常用内存数据库比较

    2011-09-14 14:35:00
    JAVA常用开源内存数据库比较。让你能很轻松地在众多内存数据库中做出最好选择!
  • 内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用,关注性能,作用类似于缓存,并不注重数据完整性和数据一致性。基于键值型的...

    内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用,关注性能,作用类似于缓存,并不注重数据完整性和数据一致性。基于键值型的内存数据库比关系型更加易于使用,性能和可扩展性更好,因此在应用上比关系型的内存数据库使用更多。本文首先比较FastDB、Memcached和Redis主流内存数据库的功能特性,再从性能上比较H2、Memcached和Redis三种内存数据库,希望大家能够根据自己业务需求的具体特点,选择合适的开源产品。

    主流内存数据库功能比较
    FastDB
    FastDb是高效的关系型内存数据库系统,具备实时能力及便利的C++接口。FastDB针对应用程序通过控制读访问模式作了优化。通过降低数据传输的开销和非常有效的锁机制提供了高速的查询。对每一个使用数据库的应用数据库文件被影射到虚拟内存空间中。因此查询在应用的上下文中执行而不需要切换上下文以及数据传输。fastdb中并发访问数据库的同步机制通过原子指令实现,几乎不增加查询的开销。

        FastDB的特点包括如下方面:
    

    1、FastDB不支持client-server架构因而所有使用FastDB的应用程序必须运行在同一主机上;

    2、fastdb假定整个数据库存在于RAM中,并且依据这个假定优化了查询算法和接口。

    3、fastdb没有数据库缓冲管理开销,不需要在数据库文件和缓冲池之间传输数据。

    4、整个fastdb的搜索算法和结构是建立在假定所有的数据都存在于内存中的,因此数据换出的效率不会很高。

    5、Fastdb支持事务、在线备份以及系统崩溃后的自动恢复。

    6、fastdb是一个面向应用的数据库,数据库表通过应用程序的类信息来构造。

        FastDB不能支持Java API接口,这使得在本应用下不适合使用FastDB。
    

    Memcached
    Memcached是一种基于Key-Value开源缓存服务器系统,主要用做数据库的数据高速缓冲,并不能完全称为数据库。

        memcached的API使用三十二位元的循环冗余校验(CRC-32)计算键值后,将资料分散在不同的机器上。当表格满了以后,接下来新增的资料会以LRU机制替换掉。由于    memcached通常只是当作缓存系统使用,所以使用memcached的应用程式在写回较慢的系统时(像是后端的数据库)需要额外的程序更新memcached内的资料。
    
        memcached具有多种语言的客户端开发包,包括:Perl、PHP、JAVA、C、Python、Ruby、C#。
    

    Redis
    Redis是一个高性能的key-value数据库。redis的出现,很大程度补偿了memcached这类keyvalue存储的不足,在部分场合可以对关系数据库起到很好的补充作用。它提供了C++、Java、Python,Ruby,Erlang,PHP客户端。

    小结
    由于不支持Java客户端,因此FastDB并不合适。在Memcached和Redis的比较上,分为性能和功能两个方面。

        关于性能方面的详细内容建议继续阅读后面的内容,我对H2、Memcached和Redis亲自从读写删三方面进行了性能测试。
    
        因此从内存数据库功能特性方面综合来看,推荐使用Redis。
    

    主流内存数据库性能比较
    测试目的
    本次性能测试选择目前成熟度和使用度都比较高的内存数据库,通过读写的性能测试比较这些主流数据库中的性能优劣。在性能测试过程中同时记录各个产品的稳定性。

        比较的内存数据库包括Memcached、Redis、H2。
    

    测试方法
    性能测试主要包括对内存数据库读、写、删除的测试。

        使用单个线程将一定量的记录插入内存数据库,记录插入时间,每条记录的数据大小相同;然后在进行一定量的读操作,记录读出时间;最后将这些数据删除,记录时间。
    

    根据读写效率综合评估内存数据库性能。

        具体的测试数据量为:
    

    1、插入10000条数据,记录时间;

    2、读取上述10000条数据,记录时间;

    3、将上述10000条数据逐条删除,记录时间。

    测试环境
    本次测试共需要使用一台联系服务器,配置如下:

    CPU:Intel® Xeon® CPU E7-4830 @ 2.13GHz,共32个CPU,每个CPU8核;

    内存:物理内存8G,交换分区9G;

    磁盘:物理磁盘250G;

    网卡:单网卡,带宽上限1000Mbps,全双工

        在该服务器上搭建中标云平台,并创建虚拟机,三种内存数据库均部署在该虚拟机中,虚拟机配置为:
    

    CPU:Intel® Xeon® CPU E7-4830 @ 2.13GHz,共2个CPU,每个CPU8核;

    内存:物理内存1G,交换分区5G;

    磁盘:物理磁盘50G;

    网卡:单网卡,带宽上限1000Mbps,全双工

        测试应用部署在一台普通台式机中,台式机配置为:
    

    CPU:Intel® Xeon® CPU E7-4830 @ 2.13GHz,共2个CPU,每个CPU2核;

    内存:物理内存1G,交换分区2G;

    磁盘:物理磁盘64G;

    网卡:单网卡,带宽上限1000Mbps(共享),全双工

        台式机和服务器采用普通内部局域网连接。
    

    内存数据库部署
    Memcached
    Memcached的安装前先安装依赖的libevent库,步骤如下:

    tar -zxvf libevent-2.0.12.stable.tar.gz

    cd libevent-2.0.12.stable

    ./configure –prefix=/usr/libevent

    make

    make install

        安装的memcached需要从源码编译安装,步骤如下:
    

    tar -zxvf memcached-1.4.15.tar.gz

    cd ./memcached-1.4.15

    ./configure –with-libevent=/usr/libevent

    make

    make install

    Redis
    Redis的安装也是从源码开始,将Redis源码压缩包拷贝到/usr/local/目录下,安装步骤如下:

    tar -zxvf redis-2.6.14.tar.gz

    cd ./redis-2.6.14

    make

        开启Redis服务器和Redis自带的客户端访问工具如下:
    

    src/redis-server

    src/redis-cli

    H2
    H2的安装较为简单,直接使用unzip命令进行解压即可。

        解压之后进入bin目录,并修改h2.sh文件中的Java命令启动的主类和选项为:
    

    org.h2.tools.Server -tcpAllowOthers -webAllowOthers

        然后执行脚本h2.sh即可启动数据库。H2提供本地命令行控制台,启动方式为:
    

    java -cp *.jar org.h2.tools.Shell

        一般来说,使用图形化的Web界面更为方便。
    

    测试结果
    Memcached的测试结果如下:

    Benchmark result has listed as follow:

    Set Data spent time (ms): 344

    Get Data spent time (ms): 8297

    Delete Data spent time (ms): 187

        Redis的测试结果如下:
    

    Benchmark result has listed as follow:

    Set Data spent time (ms): 5594

    Get Data spent time (ms): 6312

    Delete Data spent time (ms): 3969

        H2的测试结果如下:
    

    Benchmark result has listed as follow:

    Set Data spent time (ms): 14609

    Get Data spent time (ms): 14859

    Delete Data spent time (ms): 10469

    结果分析
    从结果来看,Memcached的性能最好,Redis其次,而H2的性能则最差。细节方面,Redis的读性能要略好于Memcached。

        在执行本次测试之前并没有对各个软件进行优化,因为测试数据总量10000条,每条不到1KB,总共不过10MB,而且单个线程,所以默认配置应该都是足够的,因此测试结果能够反映各自的性能情况。
    
        产生这个结果的原因主要是三种软件的功能丰富程度不同,以及使用内存的情况不同。H2作为关系型数据库,具有持久存储功能,因此还是大量使用了磁盘,而且H2也要考虑数据完整性和原子性等关系数据库的关键特性;而Redis采用Key-Value范型,不能达到关系型数据库那样的可靠性,实现的特性少,可以更加关注性能,但是为了防止数据丢失,支持持久存储机制;而同样是Key-Value方式的Memcached则不支持持久存储,纯内存软件。
    
        还有一项与性能无关的情况需要指出,在编写测试应用的时候,Memcached操作的代码量最少,其次为Redis,H2所需代码最多。
    

    结论
    综合上述功能特性的分析和性能测试结果分析,对于内存数据库的选型结论如下:

    1、如果无特殊要求,则Memcached综合性能最好,编程最方便,推荐使用;

    2、如果读操作很多,而且需要内存数据库提供持久存储以避免重启之后数据丢失,则推荐使用Redis。

        在性能方面,可以参考资料[6]中的比较。最终的比较结果表明,在小文件和大文件的读写性能上,Redis都要胜过Memcached,特别是在大文件读写方面,memcached性能不高。
    
        在功能方面,可以参考资料[7]中的分析。该分析中指出Redis对Memcached的最大的补充是对持久化的支持,这使得在机器重启或者升级时数据不至于丢失。
    
        我的测试代码采用Java开发,开发环境为Eclipse 3.7,如果需要我的全部测试代码,可以在评论里留下邮箱,我会发过去。
    

    参考资料
    [1] Memcached Build from Source.http://code.google.com/p/memcached/wiki/NewInstallFromSource.

    [2] Configure Memcached.http://code.google.com/p/memcached/wiki/NewConfiguringServer.

    [3] Redis Document.http://redis.io/documentation.

    [4] Jedis 2.0 API.http://www.jarvana.com/jarvana/view/redis/clients/jedis/2.0.0/jedis-2.0.0-javadoc.jar!/index.html.

    [5] H2 Database Engine Version 1.3.172 (2013-5-25).http://www.h2database.com/html/main.html.

    [6] Memcache and Redis Performance Compare.http://timyang.net/data/mcdb-tt-redis/.

    [7] Memcache and Redis Functional Analysis.http://www.oschina.net/news/26691/memcached-timeout.

    展开全文
  • 内存数据库(MMDB:MainMemoryDatabase,也叫主存数据库)[1],就是将数据全部或者大部分放在内存中进行操作的数据库管理系统,对查询处理、并发控制与恢复的算法和数据结构进行重新设计,以更有效地使用CPU周期和内存...
  • 一款非常优秀的内存数据库——lmdb

    千次阅读 2020-09-18 13:36:23
    lmdb是一款开源的高效快速的内存映射数据库,C语言编写,基于B+树索引,支持MVCC事务处理,是一个嵌入到进程的数据库,不需要单独的数据库进程,在代码中使用lmdb的接口即可方便地实现读写lmdb数据库。 github:...

    lmdb是一款开源的高效快速的内存映射数据库,C语言编写,基于B+树索引,支持MVCC事务处理,是一个嵌入到进程的数据库,不需要单独的数据库进程,在代码中使用lmdb的接口即可方便地实现读写lmdb数据库。

    与几年前我曾经使用过的BerkelyDB有些小关系,这个数据库可支持多进程/线程的读写,

    github:https://github.com/LMDB/lmdb.git

    文档及注意事项,详见:http://www.lmdb.tech/doc/index.html

    下载并编译、安装

    git clone https://github.com/LMDB/lmdb.git
    cd lmdb/libraries/liblmdb
    make
    sudo make install

    示例代码,main.cpp:

    #include <iostream>
    #include <string>
    #include <chrono>
    
    #include "lmdb.h"
    
    
    using namespace std;
    
    int main(int argc, char* argv[]){
    
        int res;
        MDB_env *env;
        MDB_dbi dbi;
        MDB_val key, data;
        MDB_txn *txn;
        MDB_cursor *cursor;
    
        //init lmdb
        cout<<"lmdb version:"<<mdb_version(0, 0, 0)<<endl;
        res = mdb_env_create(&env);
        if(res){
            cout<<"mdb_env_create error,error:"<<mdb_strerror(res)<<endl;
            return -1;
        }
    
        res = mdb_env_open(env, "./lmdb_test", 0, 0644);
        if(res){
            cout<<"mdb_env_open error,detail:"<< mdb_strerror(res)<<endl;
            return -1;
        }
    
        res = mdb_txn_begin(env, NULL, 0, &txn);
        if(res){
            cout<<"mdb_txn_begin error,detail:"<< mdb_strerror(res)<<endl;
            return -1;
        }
    
        res = mdb_dbi_open(txn, NULL, 0, &dbi);
        if(res){
            cout<<"mdb_dbi_open error,detail:"<< mdb_strerror(res)<<endl;
            return -1;
        }
    
        do{
            //write data to lmdb
            for(int i=0;i<10;++i){
                MDB_val key, data;
                int value=i*i;
                key.mv_size =sizeof(i);
                key.mv_data =(void*)&i;
    
                data.mv_size = sizeof(value);
                data.mv_data = (void*)&value;
    
                res = mdb_put(txn, dbi, &key, &data, 0);
            }
    
            res = mdb_txn_commit(txn);
            if (res) {
                cerr<<"mdb_txn_commit:"<< res<<":"<< mdb_strerror(res)<<endl;
                break;
            }
    
            res = mdb_txn_begin(env, NULL, MDB_RDONLY, &txn);
            res = mdb_cursor_open(txn, dbi, &cursor);
    
            //read data from lmdb
            while ((res = mdb_cursor_get(cursor, &key, &data, MDB_NEXT)) == 0) {
                int r_key=*(int *)key.mv_data;
                int r_value=*(int *)data.mv_data;
                cout<<"<"<<r_key<<","<<r_value<<">"<<endl;
            }
    
            mdb_cursor_close(cursor);
            mdb_txn_abort(txn);
        }while(0);
    
        //free
        mdb_dbi_close(env, dbi);
        mdb_env_close(env);
        return 0;
    }
    
    

    编译代码:

    g++ -Wall -g main.cpp -o main -llmdb

    在main程序所在目录,创建数据库目录testdb, 执行main程序(如果遇到找不到lmdb.so的错误, export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib):

    ./main
    

    输出:

    以上示例代码简单展示了lmdb库的用法,更详细的api使用请参考lmdb官方文档。

    展开全文
  • 内存数据库 传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称作磁盘数据库(DRDB: Disk-Resident Database).磁盘数据库因为磁头机械运动及系统调用因素导致速度降低,后来逐渐增加内存作用,有两种技术:...
    • 内存数据库

      传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称作磁盘数据库(DRDB: Disk-Resident Database).磁盘数据库因为磁头机械运动及系统调用因素导致速度降低,后来逐渐增加内存作用,有两种技术:共享内存技术、内存数据库。

      内存数据库(Main Memory Database),又称为主存数据库,按历史发展分成三个阶段1

      1. 雏形期(20世纪60年代末-80年代初)

        1969年,IBM开发出最早的数据库管理系统:基于层次模型的数据库管理系统IMS。同时,基于内存的数据管理,退出了IMS/VS Fast Path,同时支持内存驻留和磁盘驻留数据。

        与此同时,网状数据库、关系数据库等各种数据库技术逐渐成型。

      2. 技术理论成熟期(1984)

        1984年,D.J.DeWitt发表《主存数据库系统的实现技术》一文,首次提出主存数据库(Main Memory Database)概念,提出AVL树、哈希算法、主存数据库恢复机制等主存数据库技术的关键理论,为主存数据库的发展指出了明确的方向。

        1985年,IBM退出在IBM370上运行的OBE主存数据库;

        1986年,RB.Hagman提出使用检查点技术实现主存数据库的恢复机制,威斯康星大学提出了按区双向锁定模式解决主存数据库中的并发控制问题。并设计出MM-DBMS主存数据库。贝尔实验室退出DALI主存数据库模型。

        1987年,ACM SIGMOD会议中提出了以堆文件(HE AP FILE)作为主存数据库的数据存储结构。Southern Methodist大学设计出MARS主存数据库模型。

        1988年,普林斯顿大学设计出TPK主存数据库;

        1990年普林斯顿大学设计出System M主存数据库。

      3. 产品发展期和市场成长期

        随着互联网发展、内存硬件、半导体技术发展,使得主存数据库的技术可行性逐渐成熟。

        1994年,美国OSE公司推出第一个商业化的、可时机使用的主存数据库产品Polyhedra;

        1998年,德国Software AG推出Tamino Database;

        1999年,日本UBIT会社开发出XDB主存数据库;韩国Altibase推出Altibase;

        2000年,奥地利的Quilogic公司推出SQL-IMDB;

        2001年,美国的McObject推出eXtremeDB;加拿大Empress公司推出Express DB;

    • 常见的内存数据库类型2

      1. 关系型内存数据库
      2. 键值对内存数据库
      3. 传统数据库的内存数据库引擎
    • 常见的内存数据库

      1. eXtremeDB

        eXtremeDB是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库,只有50k到130k的开销,速度为微秒级。

        eXtreme DB完全驻留在主内存中,不使用文件系统,讲内存扩展到磁盘,把磁盘当作虚拟内存来用,数据管理量在32位下能达到20G。

      2. Oracle TimesTen

        Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库。

        Oracle还有一款Oracle Berkeley DB

      3. SolidDB

        Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能为一体。

      4. Altibase

        适用于通信、网上银行、证券交易、实时应用、嵌入式系统领域。

        目前占据80%以上内存数据库市场。

      5. SQLite

        SQLite是一个小型的C程序库,实现了独立的、可嵌入的、零配置的SQL数据库引擎。

    • 磁盘上的数据库

      磁盘数据库与内存数据库对应,是一种将数据存储在磁盘上的数据管理系统。核心知识在于数据的物理读写过程34

    • 分布式文件系统上的数据库

    • 分布式数据库(Distributed Data Base)5

      分布式数据库系统通常使用较小的计算机系统,每台计算机可单独放在一个地方,每台计算机中都可能有DBMS的一份完整拷贝副本,或者部分拷贝副本,并且具有自己局部的数据库,位于不同地点的许多计算机通过网络互相连接,共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。

    • 分布式数据库简史

      始于20世纪70年代中期;

      1979年,美国CCA在DEC计算机上实现第一个分布式数据库系统SDD-1;

      20世纪90年代,分布式数据库系统普遍进入商品化应用阶段。

    • 分布式数据库系统(Distributed Database System)6

      分布式数据库系统(DDBS)包含:分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。

    • 分布式数据库系统的分类7

      1. 同构同质型DDBS

        各个场地都采用同一类型的数据模型(譬如都是关系型),并且是同一型号的DBMS

      2. 同构异质型DDBS

        各个场地采用同一类型的数据模型,但是DBMS的型号不同,譬如DB2、Oracle、Sybase、SQL Server

      3. 异构型DDBS

        各个场地的数据模型的型号不同,甚至类型也不同。

    • References


    1. 常用内存数据库介绍 ↩︎

    2. 内存数据库技术选型 ↩︎

    3. 0. 磁盘读写与数据库的关系 ↩︎

    4. 深入理解数据库磁盘存储(Disk Storage) ↩︎

    5. 百度百科:分布式数据库 ↩︎

    6. 百度百科:分布式数据库系统 ↩︎

    7. 分布式数据库概述 ↩︎

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,051,270
精华内容 420,508
关键字:

内存数据库