-
2019-09-29 16:57:31
-
内存数据库
传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称作磁盘数据库(DRDB: Disk-Resident Database).磁盘数据库因为磁头机械运动及系统调用因素导致速度降低,后来逐渐增加内存作用,有两种技术:共享内存技术、内存数据库。
内存数据库(Main Memory Database),又称为主存数据库,按历史发展分成三个阶段1:
-
雏形期(20世纪60年代末-80年代初)
1969年,IBM开发出最早的数据库管理系统:基于层次模型的数据库管理系统IMS。同时,基于内存的数据管理,退出了IMS/VS Fast Path,同时支持内存驻留和磁盘驻留数据。
与此同时,网状数据库、关系数据库等各种数据库技术逐渐成型。
-
技术理论成熟期(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主存数据库。
-
产品发展期和市场成长期
随着互联网发展、内存硬件、半导体技术发展,使得主存数据库的技术可行性逐渐成熟。
1994年,美国OSE公司推出第一个商业化的、可时机使用的主存数据库产品Polyhedra;
1998年,德国Software AG推出Tamino Database;
1999年,日本UBIT会社开发出XDB主存数据库;韩国Altibase推出Altibase;
2000年,奥地利的Quilogic公司推出SQL-IMDB;
2001年,美国的McObject推出eXtremeDB;加拿大Empress公司推出Express DB;
-
-
常见的内存数据库类型2
- 关系型内存数据库
- 键值对内存数据库
- 传统数据库的内存数据库引擎
-
常见的内存数据库
-
eXtremeDB
eXtremeDB是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库,只有50k到130k的开销,速度为微秒级。
eXtreme DB完全驻留在主内存中,不使用文件系统,讲内存扩展到磁盘,把磁盘当作虚拟内存来用,数据管理量在32位下能达到20G。
-
Oracle TimesTen
Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库。
Oracle还有一款Oracle Berkeley DB
-
SolidDB
Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能为一体。
-
Altibase
适用于通信、网上银行、证券交易、实时应用、嵌入式系统领域。
目前占据80%以上内存数据库市场。
-
SQLite
SQLite是一个小型的C程序库,实现了独立的、可嵌入的、零配置的SQL数据库引擎。
-
-
磁盘上的数据库
-
分布式文件系统上的数据库
-
分布式数据库(Distributed Data Base)5
分布式数据库系统通常使用较小的计算机系统,每台计算机可单独放在一个地方,每台计算机中都可能有DBMS的一份完整拷贝副本,或者部分拷贝副本,并且具有自己局部的数据库,位于不同地点的许多计算机通过网络互相连接,共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
-
分布式数据库简史
始于20世纪70年代中期;
1979年,美国CCA在DEC计算机上实现第一个分布式数据库系统SDD-1;
20世纪90年代,分布式数据库系统普遍进入商品化应用阶段。
-
分布式数据库系统(Distributed Database System)6
分布式数据库系统(DDBS)包含:分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。
-
分布式数据库系统的分类7
-
References
更多相关内容 -
-
常用内存数据库介绍
2018-07-09 23:18:551. 内存数据库简介 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 name License Description Adaptive Server Enterprise (ASE) 15.5 Proprietary enterprise database from Sybase)[4] Apache Derby Apache License 2.0 Java RDBMS Altibase Proprietary has in-memory and disk table; HYBRID DBMS BlackRay GNU General Public Licence (GPLv2) and BSD License CSQL GNU General Public Licence or proprietary Datablitz Proprietary DBMS Eloquera Proprietary In-memory, In-memory:persist modes eXtremeDB commercial product DBMS, also check out its open source PERST dbms. FleetDB MIT NOSQL db with Writing to an append-only log to provide durability. H2 Mozilla Public License or Eclipse Public License has a memory-only mode HSQLDB BSD license has a memory-only mode IBM TM1 Proprietary in-memory BI and data analysis InfoZoom Proprietary in-memory BI and data analysis KDB Proprietary DBMS, also supports disk based data membase Apache License NoSQL, hybrid MicroStrategy in-memory BI for MicroStrategy 9 MonetDB MonetDB License MySQL GNU General Public License or proprietary has a cluster server which uses a main-memory storage engine Oracle Berkeley DB Sleepycat License can be configured to run in memory only Panorama for Windows and Macintosh, both single user and server versions ParAccel Proprietary in-memory, columnar, relational, ACID-compliant; disk-based mode as well Polyhedra IMDB Proprietary relational, supports High-Availability; acquired in 2001 by ENEA QlikView BI-tool developed by QlikTech RDM Embedded Proprietary including hybrid RDM Server Proprietary including hybrid Redis BSD NoSQL solidDB by IBM including hybrid, HSB-based HA, Shared memory, embedded, XA, etc. SAP HANA database Proprietary Database engine of the SAP In-Memory Appliance (SAP HANA) produced by SAP AG SQLite Public domain hybrid, 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 Vertipaq Proprietary Microsoft PowerPivot and Microsoft Analysis Services in-memory BI engine VoltDB GNU General Public License v3 in-memory TREX search engine in the SAP NetWeaver integrated technology platform produced by SAP AG Xcelerix by Frontex commercial product -
内存数据库及技术选型
2021-08-24 00:32:27点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料依靠内存来存储数据的数据库管理系统,也称为内存数据库,成为了解决高并发、低...点击上方“朱小厮的博客”,选择“设为星标”
后台回复"书",获取
后台回复“k8s”,可领取k8s资料
依靠内存来存储数据的数据库管理系统,也称为内存数据库,成为了解决高并发、低时延数据管理需求的技术路线。近年来,随着动态随机存储器(DRAM)容量的上升和单位价格的下降,使大量数据在内存中的存储和处理成为可能,Redis、Memcached等内存数据库管理软件逐渐成熟,应用范围越来越广。
未来几年,随着非易失性存储器件(NVM)逐步投入商用,新硬件将会给内存数据库带来更大的发展机遇。
本白皮书阐述了内存数据库的概念,梳理了内存数据库的发展历史和核心属性,分析了在电商、直播和电信行业的典型应用场景,并对主流的内存数据库进行了介绍和对比,从技术和管理两个角度提出了产品选型和硬件选型建议,并总结了内存数据库的发展趋势:
内存数据库又称主存数据库(In-memory或main memory database),是一种主要依靠内存来存储数据的数据库管理系统。
在数据库技术中,有一类内存优化技术,是在传统的磁盘数据库中,增加内存缓冲池,也就是常说的共享内存技术,其主要目的是最小化磁盘访问。
而内存数据库技术,几乎把整个数据库放进了内存中,相较于传统数据库使用的磁盘读写机制,内存具备更极致的读写速度,性能会比传统的磁盘数据库有数量级的提升。因此内存数据库通常被用于对性能要求较高的场景中。
1.内存技术的成熟
内存器件的容量密度在快速上升。最早期的内存和今天常见的内存条不同,是直接焊接在主板上的内存芯片,容量普遍在64KB以下。
1982年之后,随着80286芯片的推出,开始出现30线(Pin)256KB的SIMM内存条,被认为是内存领域的开山鼻祖;
在80年代末,386和486时代的PC向16位发展,出现了72线的SIMM内存,单条容量可达512KB-2MB;90年代初,EDODRAM开始盛行,单条容量在4MB-16MB;
在1995年,计算机系统进入图形界面时代,内存技术也发生了重要变革,支持64位的SDRAM成为一代经典,在性能上有极大提升,容量也达到了64MB;
随后的十几年,内存容量开始稳定地遵循摩尔定律翻倍,持续到2019年,DDR3内存的容量已经可以达到16GB。
内存器件的单位价格也在逐年快速下降。从1970年代至今,内存每兆字节的价格下降了近9个数量级,根据2019年最新的统计数据,平均花费3-5美元就可以购买到1GB的内存。内存容量的持续上涨以及价格的下降,使大量数据在内存中进行存储和操作成为可能。
2.内存技术的瓶颈与突破
过去几十年,计算机系统的存储体系结构被设计成如图2的金字塔形模型。这样的存储结构利用局部性原理尽量将热数据存储在靠近CPU的地方。在传统模式中,内存数据库的所有数据都保存在DRAM介质中。
虽然DRAM的价格已经大幅下降,但在海量数据存储的需求下,内存的成本依然是很大的问题;另外由于DRAM属于易失性介质,掉电后所有数据都会丢失,需要额外考虑数据持久化的方案,会极大的限制内存数据库的性能和使用场景。
针对DRAM现存的一些硬件瓶颈,业界已经研发出了持久型内存(PM,Persistent Memory),学术名为存储级内存(SCM,Storage ClassMemory),和DRAM一样,都是安装在机器主板的内存槽接口中。
参考图2,DDRDRAM及以上的易失性存储CPU可以通过load/store指令直接访问,而NANDSSD及以下的非易失性存储CPU无法直接访问,需要先加载到易失性存储中,可以看出DRAM与SSD之间存在巨大的性能鸿沟,在访问时延上出现了跳变。
而持久型内存位于DRAM与SSD之间,以load/store指令的方式访问并支持数据的持久化,也填补了DRAM与SSD在时延上存在的鸿沟。相比DRAM,持久型内存在性能上处于劣势,但容量和价格均占据优势;相比NANDSSD,持久型内存在性能上处于优势,但容量和价值处于劣势。
3.内存数据库的发展历程
内存数据库的发展主要经历了雏形期、理论成熟期、市场成长期及高速发展期四个阶段。
4.内存数据库的优势与挑战
内存数据库在提供高性能读写能力的同时,也存在由于器件导致的数据易失问题,需要在应用中引起注意。
1).优势:高性能读写
由于省去了磁盘I/O的开销,在数据访问的时延上内存型数据库可以达到传统关系型数据库无法达到的微秒级别,单机内存数据库的QPS也可以达到10万以上,配合上用户态协议栈、内存大页等技术之后,更是可以轻松达到几十万QPS的量级,这是传统的关系型数据库很难做到的。
2).挑战:内存数据易失
内存数据库当前主要使用DRAM作为存储介质,DRAM属于掉电易失性介质,为了保证数据的可靠性,内存数据库需要考虑持久化方案。现阶段主流的键值对内存数据库对于持久化的支持较为薄弱,持久化性能也不如传统数据库。
内存型数据库中克服掉电易失性来保障数据可靠性的方法主要是以下两种:
一是每次操作都进行数据持久化,这种方式势必会大幅降低内存数据库的性能;
二是按照一定的策略进行操作的持久化,这样可以达到一定程度的优化和缓解,但极端情况下数据丢失的情况仍不可避免。
现阶段新型的非易失性存储器件已经发布但尚未规模化商用。相信解决了存储易失性的难题后,内存数据库会具备更多的应用。
5.内存数据库的分类
主流的内存数据库可分为键值对内存数据库、关系型内存数据库以及其他数据库,用户可根据自身的业务需求选择适合自己的内存数据库类型。
1).键值对内存数据库
键值对(KV, Key-Value)内存数据库指的是一种以键值对为主要存储结构的内存数据库。键值对内存数据库通常按键进行数据存取操作,值通常支持各种数据类型,使用键值存储的数据模型相对简单,更适合要求性能高、计算简单的一些场景。键值对内存数据库的典型代表为 Redis、Memcached 和 Aerospike。
2).关系型内存数据库
关系型内存数据库是一种基于数据关系模型的内存数据库。关系型内存数据库将传统的关系型数据库表搬到内存中,支持通过 SQL语句的方式实现对内存数据的访问,在实现复杂分析功能的同时,提升数据访问速度。关系型内存数据库的典型代表软件为 Oracle TimesTen、SAP HANA、MemSQL 和 SQLite。
3).其他类型的内存数据库
除键值对内存数据库、关系型内存数据库之外,其他比较小众的内存数据库称为其他内存数据库,比如图内存数据库 RedisGraph 等。
6.内存数据库产品现状
DB-Engines Ranking 是公认较权威的数据库排行,我们选取了其中最为活跃的 10 款典型内存数据库进行对比。开源产品中,Redis 和 Memcached 是最受欢迎的两款键值对内存数据库;而 SQLite 是最受欢迎的关系型内存数据库。表中大部分的关系型内存数据库为商用数据库,其中热度最高的是 SAP HANA。
早在 1995 年就发布第一版的Oracle TimesTen 仍然在榜上活跃;2014 年新发布 Apache Ignite 兼容键值和关系型数据结构,热度正稳步攀升。事务支持方面,大部分的关系型内存数据库称可以支持 ACID,但都需要在性能上作出妥协。
7.内存数据库选型建议
技术服务于业务,内存数据库的选型应首先遵循业务场景的需求。业务特性决定了数据的应用特性,包括数据量、并发度、读写特性、一致性、响应时间、操作复杂度、业务连续性等要求,对应数据库的一致性、容错性、扩展性、安全性等技术要求。在做内存数据库的选型前,建议先梳理业务需求并进行量化;再将核心数据应用特性映射成数据库技术要求;最后按筛选出的技术要求进行选型。
1).技术因素
按照技术要求进行内存数据库选型时,可主要考察业务的性能、一致性要求和 SQL 兼容性三个因素。
业务是否有很高的性能要求?一般有高并发、低时延读写要求的业务,如游戏实时排行、直播粉丝关注等,建议选择内存数据库。
业务数据是否要求强一致性?如果业务对数据的可靠性和一致性要求较高、需要 ACID 级别的事务支持,则建议使用 MySQL 等传统的关系型数据库。但需要注意的是,强一致性的要求会对数据库的性能造成一定的影响;如果需要兼具高性能和强一致性,则需要在应用架构层面进行优化,单靠数据库的能力还无法实现。
数据处理是否要求 SQL 兼容性?在高性能要求的场景下,业务中如果数据结构固定、有复杂的关联计算要求,或是需要 SQL 语法支持的情况,建议使用关系型内存数据库;对于数据结构多变、扩展性要求高、数据模型和操作简单的场景,建议使用键值对内存数据库。
除了这三条考察指标,还可以结合数据容量、成本、扩展性、可维护性等需求进行综合考量。
2).非技术因素
上述选型方法主要考量的是技术因素,除此以外还可以结合实际情况,引入一些其他维度的考量,进行综合评估,最终挑选出适合的产品。包括但不限于以下维度:
1)生态成熟度。指数据库产品的状态,包括各种配套工具、技术架构成熟度、代码质量、开发模式、社区建设、商业支持服务、版权协议等;
2)应用架构适配度。指应用架构对数据库架构的兼容性、以及适配改造友好度,包括技术架构适配、开发语言适配等;
3)团队适应度。指开发团队、维护团队对数据库的熟悉程度、偏好程度、学习成本以及配套运维工具等。
想知道更多?扫描下面的二维码关注我后台回复"技术",加入技术群后台回复“k8s”,可领取k8s资料 【精彩推荐】
-
磁盘数据库 vs 内存数据库
2021-06-06 00:57:29内存数据库全部数据存储在内存中,具备更极致的读写性能在数据库发展早期,由于硬件性能的局限,数据库系统通常采用基于磁盘的设计,数据在内存中进行相应处理并以磁盘块 为单位存储在磁盘上。而内...内存数据库
全部数据存储在内存中,具备更极致的读写性能
在数据库发展早期,由于硬件性能的局限,数据库系统通常采用基于磁盘的设计,数据在内存中进行相应处理并以磁盘块 为单位存储在磁盘上。而内存数据库(IMDB)是一种将全部数据存储在内存中,无需进行磁盘I/O即可对数据进行增删查 改,具备高读写性能的数据库。其设计理念最早可以追溯到IBM于1976年推出的 IMS/VS Fast Path 数据库,它体现了数 据分层的思想,将活跃数据放在物理内存中进行访问和管理。随着互联网的发展,用户对数据量、操作频率和响应速度有 了越来越高的要求,而磁盘数据库面对多并发、高频率的访问时暴露出越来越多的问题;同时内存的容量不断增加,单价 越来越低,计算机操作系统地址空间得到更大的支持,把全部数据放到内存中具备了可实现性。各商业、开源的内存数据 库纷纷问世,内存数据库进入了高速发展的阶段。随着未来非易失内存NVM(实现内存存储的所有数据在电流关掉后也 不会消失)的发展与成熟,内存数据库的应用范围将会得到进一步的跃升。
数据持久化
通过事务日志和检查点机制,满足“高性能+持久性”双需求
由于现阶段NVM尚未达到应用水平,而存储在DRAM中的数据在重启后则会丢失,不能满足用户持久存储数据的要求。因此,内存数据库需要考虑数据的持久化问题。当前主要的方法包括日志机制 (Log) 和检查点机制 (Checkpoint)。日志 即将每一次数据的更新操作(增删查改)记录在 Log Records文件中并写入磁盘;检查点即采用一定策略,周期性地将内 存中的数据同步到磁盘里。两种持久化方式都可以单独使用,但在实践中通常采用两者结合的方案。检查点可以配合相关 日志进行数据库的恢复,二者的结合可以减少检查点对正常事务的影响,减轻系统恢复的开销并缩减日志文件的大小,实 现恢复速度的大幅提升。
磁盘数据库 vs 内存数据库
在安全和性能方面各有优劣,往往搭配处理冷热数据
内存数据库具有“实时性能、IT架构/数据结构简单、灵活扩展”的优点,在对读写性能有极致要求的场景有着广泛地应用, 例如电信计费、嵌入式控制系统、呼叫中心应用程序和电商秒杀平台等。但由于内存本身特性,以其为架构中心的产品在 “数据持久性、容量限制、成本控制”方面较传统的磁盘数据库不具备相对优势。对数据遗失容忍度较低的企业还需要考 虑相应的数据持久化方案。另外非易失内存(NVM)及其适配架构、产品还并不成熟。因此许多企业为满足多重约束, 现阶段主要采取“磁盘数据库+内存数据库”配套使用的解决方案,分别处理冷热数据。
互联互通社区
互联互通社区专注于IT互联网交流与学习,旨在打造最具价值的IT互联网智库中心,关注公众号:互联互通社区,每日获取最新报告并附带专题内容辅助学习。
方案咨询、架构设计、数字化转型、中台建设、前沿技术培训与交流,合作请+微信:hulianhutongshequ
-
内存数据库系统,NVDIMM和数据持久性
2021-01-19 17:31:26随着从通信设备到航空装备和工业控制器等技术中对数据管理需求的不断增长,以及受到这些设备中不断增加的板...设计师经常采用的内存数据库系统(IMDS)是在主存中存储记录,因此可以消除许多延时源,比如通过硬连线接进 -
关系数据库、内存数据库、Nosql区别与联系
2018-07-10 11:28:45也许有人迷惑关系型数据库和非关系型数据库区别,其实非关系型数据库就是Nosql,所谓Nosql,就是(Not Only SQL),这个问题等价于关系型数据库和Nosql区别。 Nosql简介 Redis,Memchche,MongoDb的区别 1. 本质:... -
基于内存数据库的分布式数据库架构
2018-05-27 08:24:51【摘要】 本文提出了一种通过引入内存数据库层,建立两层多分区分布式数据库架构。此方案用于解决海量高并发系统的数据存储和访问问题,尤其适用于电子商务等数据模型复杂且业务复杂的互联网站。 这些年互联网站... -
嵌入式系统/ARM技术中的内存数据库系统,NVDIMM和数据持久性
2020-10-19 18:24:18随着从通信设备到航空装备和工业控制器等技术中对数据管理需求的不断增长,以及受到这些设备中不断增加的板...设计师经常采用的内存数据库系统(IMDS)是在主存中存储记录,因此可以消除许多延时源,比如通过硬连线接进 -
基于GPU的内存数据库索引技术研究
2014-06-15 17:36:16由于内存数据库具有比基于磁盘的数据库更高的查询响应速度和并发度,其被广泛应用于银行、证券交易所和在线购物等数据量庞大并且实时性要求高的商业领域。索引能够有效降低数据的搜索空间、提高内存数据库的查询效率... -
常用内存数据库三
2014-12-04 06:10:584.1.2 哪些场合适合使用其他的关系型数据库管理系统(RDBMS) · 客户端/服务器程序 如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以... -
内存数据库与磁盘数据库
2018-09-02 10:26:341、磁盘数据库需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)... 内存数据库数据处理速度比传统... -
主流内存数据库对比
2016-10-09 19:58:15原文地址:http://blog.csdn.net/nanfeiyannan/article/details/9003009 名称 ...开源或商业 ...不开源,商业使用付费 ...1. 符合RDBMS标准的独立内存数据库服务。 2.支持S -
Altibase 内存数据库
2010-04-22 15:30:25内存数据库 ,提速时代 第一代 : 用户定制的内存数据库 通过应用程序来管理内存和数据.;(主要目的: 提高性能) 不支持SQL语句, 不提供本地存储, 没有数据库恢复技术; 性能好但很难维护不能复用; 应用在实时领域,... -
nosql数据库与内存数据库
2015-09-29 11:27:45NoSQL数据库没有标准的查询语言(SQL),许多NoSQL数据库都有REST式的数据接口或者查询API。 使用场景: 1、数据模型比较简单; 2、需要灵活性更强的IT系统; 3、对数据库性能要求较高; 4 -
内存数据库技术选型
2017-08-27 12:37:24最近一段时间研究了内存数据库,总结了一下,分享给大家。我们先从应用场景说起。 一. 内存数据库的应用场景 数据缓存:将经常使用的数据存放在内存中,全局共享,减少和数据库之间的交互频率,提升数据访问速度... -
内存数据库FastDB和SQLite性能测评
2019-07-11 16:34:28一、引言 在很多项目中,经常会碰到这样的需求,需要对大量数据进行快速存储、...针对这些情形,我们通常需要选择高性能的数据库产品,而且通常需要使用内存数据库,顾名思义,内存数据库指的是所有的数据访问控... -
重磅: 内存数据库现状和选型(附白皮书下载)
2019-07-09 00:00:00今天,我们通过DB Engines Ranking公认比较权威的数据库排行,对公认最为活跃的10款典型内存数据库进行对比。10款典型数据库简单对比在开源产品中,Redis... -
分布式内存数据库Geode开源了,12306就在用
2015-06-24 20:22:08Geode是分布式内存数据库, 帮助12306解决了几亿中国人订票的问题,经受了世界上最强悍的考验。现在已经开源。 根据Geode项目主页介绍来看,Geode项目开发始于2002年,开始是商业产品GemFire,在2015年4月发布其开源... -
LokiJS:性能优先的 JavaScript 内存数据库
2018-06-06 10:33:50LokiJS 是纯 JavaScript 实现的内存数据库,面向文档,支持 Node.js,浏览器和 Cordova。LokiJS 坚持的信条就是性能永远是第一考虑因素。LokiJS 是:浏览器的 NoSQL 数据库,包括同步和持久化特性一个 Redis 类型的 ... -
H-Store:一种分布式内存数据库管理系统
2016-10-04 19:53:19本文主要是从学术而非商业数据库实践的角度来介绍分布式DBMS H-Store。H-Store是由Brown,MIT,CMU联合开发并在MIT的实验室成功部署实现的。H-Store的研究者对外界公布的关于H-Store的论文主要是以下两篇:The end ... -
基于PostgreSQL的内存计算引擎,来自Lenovo的设计开发经验
2021-02-25 15:31:01身处大数据时代,在数据库领域,我们要分析处理的数据越来越多,我们分析处理数据的速度也要越来越快,但是传统数据库基于磁盘的计算模型,...目前很多商业数据库已经拥有了内存计算功能,如SAPHANA、DB2BLU、Oracle12C -
主流内存数据库对比报告
2014-01-14 16:26:11内存数据库不是个新鲜的概念,但随着内存价格的下降、企业需求的增长,IT厂商纷纷进入该市场,甲骨文、微软、SAP、IBM等知名厂商加入其中。除此之外,McObject、ALTIBASE等... -
内存数据库的产品演化
2016-09-12 21:35:58内存数据库产品是把数据放在内存中,实现高效读写,目前是传统的关系型数据库的有效补充。在此我以产品演化的视角简单总结一下我所理解的内存数据库发展历史,目的是理解内存数据库产品的发展趋势,不恰当的地方请... -
【转】基于内存数据库的分布式数据库架构
2015-01-18 01:50:49【转】基于内存数据库的分布式数据库架构 【摘要】 本文提出了一种通过引入内存数据库层,建立两层多分区分布式数据库架构。此方案用于解决海量高并发系统的数据存储和访问问题,尤其适用于电子商务等数据...