精华内容
下载资源
问答
  • 内存中的数据库
    千次阅读
    2021-07-29 02:52:28

    内存数据库,顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。

    中文名

    内存数据库

    外文名

    main memory database定    义

    将数据放在内存直接操作的数据库

    下    设

    最大特点

    “主拷贝”常驻内存

    内存数据库数据库简介

    编辑

    语音

    内存数据库抛弃了磁盘数据管理的传统方式,基于全部数据都在内存中重新设计了体系结构,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,所以数据处理速度比传统数据库的数据处理速度要快很多,一般都在10倍以上。内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存,即活动事务只与实时内存数据库的内存拷贝打交道。

    定义:设有数据库系统DBS,DB为DBS中的数据库,DBM(t)为在时刻t,DB在内存的数据集,DBM(t)属于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为一个内存数据库系统,简称为MMDBS;DB为一个内存数据库,简称为MMDB。

    常见的例子有MySQL的MEMORY存储引擎、eXtremeDB、TT、FastDB、SQLite、Microsoft SQL Server Compact等

    内存数据库关键技术

    编辑

    语音

    MMDB除了具有一般数据库的特征外,又具有自己的特殊性质,其关键技术的实现具有特殊性。

    MMDB关键技术有:⑴数据结构;⑵MMDB索引技术;⑶查询处理与优化;⑷事务管理;⑸并发控制;⑹数据恢复。

    MMDB不同于DRDB,DRDB技术在内存数据库中不再适用,要对这些关键技术进行新的研究。

    存储性能要求

    在许多的数据库应用系统中,尤其在电话程控交换领域,对数据的访问性能有很高的要求。这类应用一般都有很高的事务量,又要求有很低的事务响应延迟,而且对数据库的可靠性有很高的要求,例如一个电话交换的应用,每秒钟会对数据库有数千个查询或者更新请求,每个请求要求有低于50毫秒的响应延迟,并且在一年中数据库只能有数分钟的停机时间。MMDB系统能够满足这些数据库应用的要求,但是这需要MMDB系统的各个部件在实现方式和策略上,为应用做最大的优化。

    存储方案

    MMDB中的存储模型比DRDB更加灵活。在传统的MMDB中,为了考虑对内存空间的利用,在系统中专门开辟一块空间来存放记录中各个属性的值,同时,将记录中属性值用指针来替换,指针实际指向存储在堆中的属性值。这种存储方案,在使用初期确实节省了大量的内存空间。尤其在记录中有大量重复值的情况下。并且由于记录中各个字段只存放4个字节长(32位环境下)的指针,因此记录可以很好的支持变长记录的存储,不需要再像DRDB系统中那样,在记录头部存放偏移量来支持变长字段的存储。但是这种存储方案没有很好的考虑到对处理器缓存的利用。通过指针间接访问数据,几乎相当于在内存空间中的随机访问,严重影响了缓存的利用率。尤其在64位的计算环境不断普及,内存的容量理论上可以达到无限,同时内存的价格在不断下降,但是内存的访问速度仍然没有达到处理器的速度的情况下。因此。在传统MMDB系统中,这种利用指针来节省内存空间,却忽视缓存作用的存储模式,在现在的应用环境下,反而有点得不偿失。

    可以说,先进的数据库应用程序越来越注重对内存的访问效率,高性能的数据库系统因而必须最大限度的利用处理器缓存,将可能被用到的数据缓存在多层次的缓存中。数据放置的位置对于缓存的利用优化尤其重要。选择好的数据存放方案,改进数据分布的空间局部性,能够提高对缓存的利用率,提升性能。目前新的数据存储方案的设计思路集中于对记录内部各个属性值的存储布局做调整,能够按照需求访问记录中的部分属性,从而消除不必要的内存访问所带来的内存延迟。因此,在本文中,提出一种在MMDB系统中使用的数据存储方法。它仍然在记录中存放实际的值,但是为缓存的利用做了优化。

    内存数据库数据加载

    编辑

    语音

    电信的二次批价和实时累账是计费系统中的两个必备功能。所谓二次批价是相对于一次批价来说的。一次批价是按照国家标准资费来进行价格计算,比如: 全球通每分钟本地通话为0.4元,在一次批价完成后,会根据这个用户的套餐进行再一次的计算。以北京全球通用户接听4分钟的电话为例,一次批价完成后,这条话单的价格是1.6元,如果这个用户参加了10元包月接听套餐,那么在二次批价后,这次通话的费用就为0元。一次批价是用于各大运营商之间结算的,而二次批价是针对用户个人的。

    实时累账是将用户从每月1号到目前为止的所有费用累加起来,也就是用户目前可以通过10086查到截止到前一天的实时话费。累账值可以帮助用户控制高额话费或是供用户即时查询消费信息。

    二次批价和实时累账过程涉及用户资料、用户套餐等与用户相关的信息,电信支撑系统在开始批价时必须加载这些数据。稍大一点的省级运营商的这些数据就会超过1000万条,计费处理模型也由于套餐的组合、产品的组合以及不同的优惠规则变得相当复杂,加载这部分数据对系统而言是一笔不小的开销,这就使得现在的计费处理速度比较慢,而且很难做到对数据的实时更新。内存数据库的引入在一定程度上解决了这个问题。

    在计费二次批价过程中数据量最大的是详单数据,这部分数据不用放在内存数据库中,每处理完一个话单文件或达到设定的提交记录数时直接操作磁盘数据库,不会影响系统性能。最急切的是将用户资料、套餐、营业套餐和计费套餐对应关系数据、计费套餐模型数据及用户累计数据放到内存数据库中,这部分数据查询操作远比数据新增和更新操作要频繁。除了这些数据外,当然还有应用需要的其他数据也都可以加载到内存数据库。

    在采用内存数据库后,用户通过营业部或客户查询实时话费的时候完全可以做到实时,比目前只能提供查询到前一天的实时话费在业务上有了质的飞跃。因为系统在处理这部分数据时查询流程和以前的完全一样,但系统省去了以往内存中的数据和磁盘数据库数据同步的环节,所以就能做到了实时查询。对于信控来说也同样,以往系统在累完账后要按照一定周期刷新信控数据,这就存在一个时间差,不能够完全做到实时。

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

    另外,在采用内存数据库后,整体提高了系统批价、累账的处理速度,大大缓解访问磁盘数据库的压力,提高数据查询、修改、删除的效率,也为后付费和预付费的融合提供了可能。

    内存数据库数据同步

    编辑

    语音

    电信营业数据和计费系统中的数据总是在不断的变化中,这就涉及内存数据库中的数据和磁盘数据库数据的同步问题(为了描述清楚,这里的磁盘数据库以Oracle DB为例来说明)。数据同步包括两部分: 从内存数据库到Oracle DB数据同步和从Oracle DB到内存数据库的同步。

    Oracle DB到内存数据库同步

    这部分数据同步采用增量表的方式,营业系统或CRM新增或更新的数据将生成到Oracle的增量表中,计费后台程序先到这些增量表中查询数据。如果能在这些增量表中查到数据就把这些数据更新到内存数据库对应表中,如果查不到,就直接从内存数据库中直接查询,从而保证了数据的完整性和实时性。由于增量表的数据量一般会很小,所以这部分操作不会影响系统的性能。

    内存数据库到Oracle DB同步

    由于Oracle的计费后台批价、累账数据几乎都加载到了内存数据库中,所以Oracle数据库对应的数据表将主要用于对内存数据库的数据备份。

    用户最新的实时话费等信息都保存在内存数据库中,实时话费查询将直接连接到内存数据库中查询,保证用户得到最新的费用信息。信控也直接从内存数据库查询数据,因此对Oracle中的这部分数据已经没有实时性的要求。这时内存数据库到Oracle的同步可以由应用程序生成文件,定时地往Oracle数据库中同步备份,或者采用Oracle存储过程在系统相对空闲时间段进行数据导入就可以了。

    内存数据库与传统数据库的异同

    传统的数据库系统是关系型数据库,开发这种数据库的目的,是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性,但很难顾及有关数据及其处理的定时限制,不能满足工业生产管理实时应用的需要,因为实时事务要求系统能较准确地预报事务的运行时间。

    对磁盘数据库而言,由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间与估算的最坏情况执行时间相差很大,如果将整个数据库或其主要的“工作”部分放入内存,使每个事务在执行过程中没有I/O,则为系统较准确估算和安排事务的运行时间,使之具有较好的动态可预报性提供了有力的支持,同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。

    内存数据库所处理的数据通常是“短暂”的,即有一定的有效时间,过时则有新的数据产生,而当前的决策推导变成无效。所以,实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据,其性能目标是高的系统吞吐量和低的代价,处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。

    在实际应用中这两种数据库常常结合使用,而不是以内存数据库替代传统数据库。

    而内存数据库也分全内存计算和热内存计算。全内存计算,即数据需要全部装载到内存中进行计算,对硬件要求高,譬如QlikView等产品。热内存计算,部分数据加载到内存中即可以进行计算,硬盘和内存会有数据交换来计算未加载的数据,譬如Yonghong Z-Suite。

    内存数据库技术特点

    编辑

    语音

    (1)采用复杂的数据模型表示数据结构,数据冗余小,易扩充,实现了数据共享。

    (2)具有较高的数据和程序独立性,数据库的独立性有物理独立性和逻辑独立性。

    (3)内存数据库为用户提供了方便的用户接口。

    (4)内存数据库提供4个方面的数据控制功能,分别是并发控制、恢复、完整性和安全性。数据库中各个应用程序所使用的数据由数据库统一规定,按照一定的数据模型组织和建立,由系统统一管理和集中控制。

    (5)增加了系统的灵活性。[1]

    内存数据库存储问题

    编辑

    语音

    要解决持久性问题,内存数据库也有相应的解决方案。这其中包括在集群里保存额外的数据副本,然后对数据库进行横向扩展,让系统能够在运行中不断将更新数据复制到一个或多个备用系统当中。

    一些数据库系统还会定期将数据复制到磁盘系统,就是为了应对上述突然断电或系统宕机的情况。当然这时候就要在额外的负载和数据可恢复性方面做出权衡。

    由于内存数据库的风险比传统OLTP数据库要大,所以要对它所支撑的应用系统有一个更清楚的认识。目前从整体来看,传统的OLTP应用系统往往会避免使用内存数据库技术,它更多地应用在特定的数据类型或者分析应用(包括批处理报表系统)当中,这些系统的数据远没有OLTP系统重要。

    另一方面也是出于成本预算的考虑,DRAM相比于传统磁盘甚至闪存来说都是更昂贵的。[2]

    内存数据库分类

    编辑

    语音

    存数据库和磁盘数据库

    MMDB与DRDB之间主要区别在于MMDB的主数据库常驻内存,体系结构设计的优化目标是提高内存和CPU使用效率[6,24]。与DRDB相比,MMDB的优点如下:

    完成同样的功能,所需机器指令大大降低;

    事务处理无需I/O,极大提高了系统性能;

    不再需要缓冲区管理器,消除了磁盘和内存之间数据拷贝开销;

    在数据组织与管理中,广泛使用指针,简化了内存管理,降低了空间开销[3]

    参考资料

    1.

    内存数据库资源中心(白皮书、成功案例、方案手册、视频讲座)

    .SAP内存数据库官方网站[引用日期2013-04-02]

    2.

    解读内存数据库的存储需求

    .TechTarget数据库[引用日期2015-09-24]

    3.

    内存数据库的设计与实现

    .中国知网[引用日期2017-02-23]

    更多相关内容
  • 一、内存数据库:  在SQLite,数据库通常是存储在磁盘文件的。然而在有些情况下,我们可以让数据库始终驻留在内存。常用的一种方式是在调用sqlite3_open()的时候,数据库文件名参数传递":memory:",如:  ...
  • 一、内存数据库:  在SQLite,数据库通常是存储在磁盘文件的。然而在有些情况下,我们可以让数据库始终驻留在内存。最常用的一种方式是在调用sqlite3_open()的时候,数据库文件名参数传递”:memory:”,如: ...
  • 内存数据库及技术选型

    千次阅读 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资料
    
    
    【精彩推荐】
    
    展开全文
  • 内存数据库究竟是如何发挥内存优势的?

    万次阅读 多人点赞 2022-05-09 12:55:57
    内存数据库

    前言

        与以磁盘存储为主的普通数据库相比,内存数据库的数据访问速度可以高出几个数量级,能大幅提高运算性能,更适合高并发、低延时的业务场景。
        不过,当前大部分内存数据库仍然采用 SQL 模型,而 SQL 缺乏一些必要的数据类型和运算,不能充分利用内存的特征实现某些高性能算法。仅仅是把外存的数据和运算简单地搬进内存,固然也能获得比外存好得多的性能,但还没有充分利用内存特征,也就不能获得极致的性能。
        下面我们来看看,有哪些适合内存特征的算法和存储机制,可以进一步提升内存数据库计算速度。

    一、指针式复用

    1、指针

        我们知道,内存可以通过地址(指针)来访问。但 SQL 没有用内存指针表示的数据对象,在返回结果集时,通常要把数据复制一份,形成一个新的数据表。这样不仅多消耗 CPU 时间(用于复制数据)而且还会占用更多昂贵的内存空间(用于存储复制的数据),降低内存使用率。

    2、RDD

        除了 SQL 型的内存数据库外,Spark 中的 RDD 也有这个问题,而且情况更严重。为了保持 RDD 的 immutable 特性,Spark 在每个计算步骤后都会复制出新的 RDD,造成内存和 CPU 的大量浪费。所以,即使耗用了巨大资源,Spark 也仍然做不到高性能。相比之下,SQL 型的内存数据库通常还会优化,在 SQL 语句中的计算会尽量使用内存地址,通常要比 Spark 的性能更好。
        但是,受到理论限制,实现 SQL 的逻辑时,返回的结果集就必须复制了。如果涉及多步骤的过程运算,要多次在上一步的结果集(临时表)基础上进一步计算,SQL 的劣势就会很明显了。

    3、返回指针

        事实上,如果没有改变数据结构,我们可以直接用原数据的地址形成结果集,不需要复制数据本身,仅仅多保存一个地址(指针),同时减少 CPU 和内存的消耗。
        SPL 扩展了 SQL 的数据类型,支持这种指针式复用机制。比如,对订单表按照订单日期(odate)范围过滤后,分别求出订单金额(amount1)大于 1000 和运货费(amount2)大于 1000 的订单,再计算出两者的交集、并集和差集,最后将差集按照客户号(cid)排序。SPL 代码大致是这样:

    在这里插入图片描述

        以上代码中有好几个步骤,有的中间结果也被用了多次,但由于使用的都是订单表记录的指针,所以内存占用增加的很少,也避免了记录复制的耗时。

    二、外键预关联

    1、外键关联

        外键关联是指用一个表(事实表)的非主键字段,去关联另一个表(维表)的主键。比如订单表中的客户号和产品号分别关联客户表、产品表的主键。现实运算中这种关联可能多达七八个甚至十几个表,还可能出现多层的关联。SQL 数据库通常使用 HASH JOIN 算法来做内存连接,需要计算和比对 HASH 值,过程中还会占用内存来存储中间结果,关联表很多时计算性能就会急剧下降。

    2、指针引用

        其实,我们也可以利用内存指针引用机制事先做好关联。在系统初始化阶段,把事实表中的关联字段值转换为对应维表记录的指针。因为维表的关联字段是主键,所以关联记录唯一,将外键值转换成记录指针不会引起错误。在后续计算中,需要引用维表字段时,可以用指针直接引用,无需计算和比对 HASH 值,也不需要再存储中间结果,从而获得更优的性能。SQL 没有记录指针这种数据类型,也就无法实现预关联了。

    3、预关联

        SPL 则从原理上支持并实现了这种预关联机制。例如,完成订单表和客户表、产品表预关联的代码大致是这样:

    A1、A2 加载客户表和产品表。

    A3:加载订单表,将其中的客户号 cid、产品号 pid 转换为对应维表记录的指针。

    A4:将完成预关联的订单表存入全局变量,供后续计算使用。

    系统运行时,按照产品供应商过滤订单,再按客户所在城市分组汇总的代码大致是下面这样:

    在这里插入图片描述

    订单表中的 pid 已经转换为产品表记录的指针,所以可以直接用“.”操作符引用产品表记录。 不仅书写更简单,而且运算性能也快得多。

    只是两、三个表关联时,预关联和 HASH JOIN 的差别还不是非常明显。这是因为关联并不是最终目的,之后还会有其它很多运算,关联本身运算消耗时间的占比相对不大。但如果关联情况比较复杂,涉及的表很多,以及有多层的时候(比如订单关联产品,产品关联供应商,供应商关联城市,城市关联国家等等),预关联的性能优势会更明显。

    三、序号定位

    1、序号

        与外存相比,内存的另一个重要特征是支持高速的随机访问,可以快速从内存表中按指定序号(也就是位置)取出数据。在做查找计算时,如果被查找的值正好是目标值在内存表中的序号,或者很容易通过被查找值计算出目标值的序号,我们就可以用序号直接取目标记录。这种方法不需要进行任何比对就能直接取出查找结果,性能不仅远远好于遍历查找,也好于使用索引的查找算法。

    2、索引

        但是,SQL 以无序集合为基础,不能按序号取成员,只能用序号去查找。如果没有索引就只能遍历查找,会非常慢。即使有索引也要计算 HASH 值或用二分法查找,速度也比不上直接定位。而且,建立索引也会占用昂贵的内存。如果数据表中没有序号还要先排序再硬造个序号时,性能就会更差。

    3、序号定位

        SPL 以有序集合为基础,提供序号定位功能。比如订单表中的订单号是从 1 开始的自然数。在查找订单号 i 时,直接取订单表中的第 i 条记录就行了。再比如数据表 T 从 2000 年到 2022 年每天存储一条数据,现在需要查询指定日期的记录。日期虽然不是目标值的序号,但是我们可以先算出指定日期距离起始日期的天数。这就是目标值的序号,然后再用序号取 T 表记录就可以了。对表 T 用序号定位查找 2022 年 4 月 20 日记录的代码,大致是下面这样:

    A
    1=date(2022,12,31)-date(1999,12,31)
    2=T_orginal.align@b(to(A1),dt-date(1999,12,31))
    3=env(T,A5)
    4=T(date(2021,4,20)-date(1999,12,31))

    A1:计算出 2000 年到 2022 年总天数是 8401 天。

    A2:用原始的 T 表记录计算出距离起始日期的天数,再和 to(A1)这个自然数集合 [1,2,3,…,8401] 对齐,空缺的日期会用 null 补齐。align 的 @b 选项表示对齐时将使用二分法来查找位置,这样完成对齐动作也会更快一点。

    A3:计算好的结果,放到全局变量 T 中。

    A4:要查找 2021 年 4 月 20 日记录,求出这个日期和起始日期距离 7781 天,直接取出 T 表中第 7781 条记录就可以了。

    A1 到 A3 是对齐计算,用于处理空缺的日期,可以放在系统初始化阶段。在查找计算时,用 A4 中的序号定位代码就能得到查找结果,实际查找的日期可以作为参数传入。

    四、集群维表

    1、集群

        当数据量太大,超出单机内存时,就要使用集群来加载这些数据。许多内存数据库也支持分布式计算,通常是将数据分成多段,分别加载到集群不同分机的内存中。

    2、JOIN

        JOIN 是分布式计算的一个麻烦任务,会涉及多个分机之间的数据传输。严重的时候,传输造成的延迟会抵消集群分摊计算量得到的好处,会出现集群变大反而性能并不能提升的现象。

    3、分布式数据库

        SQL 体系下的分布式数据库,通常是将单机 HASH JOIN 方法扩展到集群上。每个分机根据 HASH 值将本机数据分发到其他分机,确保相关联的数据在同一分机上。然后再在各个分机上做单机连接。但是,HASH 方法在运气不好的时候,可能会造成数据分配的严重不均衡,需要借助外存来缓存这些分发到的数据,否则可能因为内存溢出而导致系统崩溃。但是,内存数据库的主要特征就是将数据加载到内存中计算,出现外存缓存会严重拖慢计算性能。

    4、外键关联

        实际上,外键关联的事实表和维表有很大区别。事实表一般都比较大,要用各个分机内存分段加载才能装的下。正好事实表也比较适合分段,每个分段的数据都相互独立,分机之间不需要相互访问。而维表记录则会被随机访问,事实表的任何一个分段都可能关联全部维表记录。我们可以利用事实表和维表的区别,对集群的外键关联提速。

        如果维表比较小,则将维表全量数据复制到所有分机内存中。这样,每个分机中的事实表分段和全量维表就可以继续完成预关联,完全避免了关联过程中的网络传输。

    如果维表也很大,单机内存放不下,只能在各分机内存中分段加载。这时,没有一个分机上有全量的维表,外键关联计算就无法避免网络传输了。不过传输内容并不算很大,只涉及事实表的外键和维表关联记录的字段,事实表其它字段不需要传输,计算可以直接完成,过程中也不会产生缓存数据。

        SPL 从原理上区分维表和事实表,针对维表较小和维表较大两种情况,分别提供了维表复制机制和分段维表机制,实现了上述算法,能显著提高集群情况下外键关联的计算性能。

    五、回顾与总结

        内存数据库的计算体系,必须充分利用内存的特征才能获得极致性能。从数据计算的角度来看,内存主要优点有:支持指针引用、支持高速随机访问、并发读取能力强。内存的缺点是:成本高昂、扩容有上限。

        而 SQL 计算体系中缺乏一些必要的数据类型和运算,比如:缺少记录指针类型,不支持有序运算,JOIN 定义过于笼统,不区分 JOIN 类型等,从原理上就不能充分利用内存的上述特征实现某些高速算法。基于 SQL 的内存数据库,通常只是简单的照搬外存数据结构和运算,会出现各种问题。比如:记录式复制过多消耗 CPU 和内存;查找和 JOIN 性能没有达到极致。再比如集群方面:内存利用率过低;大量网络传输导致分机数量增加但性能反而下降;多机 JOIN 出现外存缓存等等。

        开源数据计算引擎 SPL 扩展了数据类型和运算定义,可以充分利用内存的特征,从而实现多种高性能算法,让性能达到极致。其中,指针式复用利用内存特有的指针引用机制,节省了内存空间,而且速度更快。预关联同样利用指针引用机制,在初始化阶段完成很耗时的外键关联,后续计算中直接使用关联好的结果,计算速度显著提高。序号定位利用有序性,充分发挥内存高速随机访问的优势,不用做任何计算和比对,直接用序号读取记录,性能好于 HASH 索引等查找算法。集群维表有效避免或减少了网络传输、避免了外存缓存,备胎式容错在保证高可用性的前提下,有效提高了集群内存利用率。

    七、SPL

    欢迎对SPL有兴趣的加小助手(VX号:SPL-helper),进SPL技术交流群

    展开全文
  • 内存数据库就是将数据放在内存直接操作的数据库,它利用内存的读写速度比磁盘快、内存是随机访问而磁盘是顺序访问这两个特点,将数据保存在内存,在内存模仿建立表结构和索引结构并针对内存特性进行优化,...
  • 常用内存数据库介绍

    万次阅读 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

    展开全文
  • 内存数据库列表

    千次阅读 2021-11-19 07:35:26
    当然,我们只能在不需要持久化数据或为了更快地执行测试的应用和场景使用内存数据库。它们通常作为嵌入式数据库运行,这意味着它们在进程开始时创建并在进程结束时被丢弃,这对于测试来说非常舒适,因为您不需要...
  • 易语言内存数据库模块源码例程程序调用API函数实现内存的数据库应用。点评:易语言内存数据库模块源码数据库的格式是自定义的。 三叶自学网
  • 内存数据库 传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称作磁盘数据库(DRDB: Disk-Resident Database).磁盘数据库因为磁头机械运动及系统调用因素导致速度降低,后来逐渐增加内存作用,有两种技术:...
  • Delphi使用SQLite3内存数据库

    热门讨论 2014-11-11 16:22:58
    Delphi使用SQLite3,包括本地数据库和内存数据库,本地数据库加载到内存,内存数据库备份到本地,使用sqlite simple delphi包装类。
  • SQLite:内存数据库

    千次阅读 2022-04-28 09:42:43
    一、内存数据库: 在SQLite,数据库通常是存储在磁盘文件的。然而在有些情况下,我们可以让数据库始终驻留在内存。最常用的一种方式是在调用sqlite3_open()的时候,数据库文件名参数传递”:memory:”,如: ...
  • 常用内存数据库比较

    2011-09-14 14:35:00
    JAVA常用开源内存数据库比较。让你能很轻松地在众多内存数据库中做出最好选择!
  • 【摘要】 本文提出了一种通过引入内存数据库层,建立两层多分区分布式数据库架构。此方案用于解决海量高并发系统的数据存储和访问问题,尤其适用于电子商务等数据模型复杂且业务复杂的互联网站。 这些年互联网站...
  • 主要介绍SQLite 内存数据库的使用方法, 需要的朋友可以参考下
  • 基础概念: 1、内存数据库标识":memory... 2、打开内存数据库,将文件数据库附加到内存数据库; 3、通过文件数据库表创建内存数据库表; 4、解除文件数据库附加到内存数据库。 二、将内存数据库保存到文件数据...
  • 一款非常优秀的内存数据库——lmdb

    千次阅读 2020-09-18 13:36:23
    lmdb是一款开源的高效快速的内存映射数据库,C语言编写,基于B+树索引,支持MVCC事务处理,是一个嵌入到进程的数据库,不需要单独的数据库进程,在代码使用lmdb的接口即可方便地实现读写lmdb数据库。 github:...
  • Redis的简单稳定主要体现在以下几个方面: ·Redis使用单线程模型。...·Redis的所有数据都是存放在内存中的,这也是其运行速度快的重要原因。 ·Redis是用C语言实现的(C语言编写的程序距离操作系统更近
  • 也许有人迷惑关系型数据库和非关系型数据库区别,其实非关系型数据库就是Nosql,所谓Nosql,就是(Not Only SQL),这个问题等价于关系型数据库和Nosql区别。 Nosql简介 Redis,Memchche,MongoDb的区别 1. 本质:...
  • 内存数据库创新:在内存缓存,压缩,列存储,纵向扩展和横向扩展。Exadata 内存数据库云服务器,利用内存 PQ 进行高性能分析,12c 内存数据库规划,12 内存全局临时表,12c 针对非结构化数据处理的内存改进,12c ...
  • 选用王珊老师数据库原理概论第五版
  • 最近公司准备把内存数据库和数据库换成国产的数蚕数据库。老大让我来测试一下性能。周末正好加个小班小试了一下。 环境准备: 官方提供的包括的linux和windows平台专业版各一套。我这里测试是windows平台使用...
  • Ignite内存关系数据库

    千次阅读 2019-04-20 14:31:37
    Ignite关系型数据库特性...基于内存查询:可以把热点数据抽取到ignite,实现基于内存的查询,这样避免redis对查询key的组合带来的内存浪费 ignite支持key,value键值对查询, ignite支持原生JAVA api,sql语法查询 ...
  • 常用内存数据库

    千次阅读 2014-12-04 06:10:58
    4.1.2 哪些场合适合使用其他的关系型数据库管理系统(RDBMS) · 客户端/服务器程序 如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以...
  • nosql数据库与内存数据库

    千次阅读 2015-09-29 11:27:45
    NoSQL数据库没有标准的查询语言(SQL),许多NoSQL数据库都有REST式的数据接口或者查询API。 使用场景: 1、数据模型比较简单; 2、需要灵活性更强的IT系统; 3、对数据库性能要求较高; 4
  • Qt之内存数据库

    千次阅读 2019-11-12 19:25:44
    内存数据库,顾名思义就是将数据放在内存直接操作的数据库。相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存相比从磁盘上访问能够极大地提高应用的性能。所以在有大量数据交互时使用内存...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,247,516
精华内容 499,006
关键字:

内存中的数据库