内存数据库
内存数据库介绍
常用内存数据库介绍（一）博客分类：内存数据库数据结构Oracle企业应用网络应用设计模式（注：部分资料直接来源于Internet）1. 内存数据库简介1.1 概念一、什么是内存数据库传统的数据库管理系统把所有数据都放在磁盘上进行管理，所以称做磁盘数据库（DRDB:Disk-Resident Database）。
磁盘数据库需要频繁地访问磁盘来进行数据的操作，由于对磁盘读写数据的操作一方面要进行磁头的机械移动，另一方面受到系统调用（通常通过CPU中断完成，受到CPU时钟周期的制约）时间的影响，当数据量很大，操作频繁且复杂时，就会暴露出很多问题。
近年来，内存容量不断提高，价格不断下跌，操作系统已经可以支持更大的地址空间（计算机进入了64位时代），同时对数据库系统实时响应能力要求日益提高，充分利用内存技术提升数据库性能成为一个热点。
在数据库技术中，目前主要有两种方法来使用大量的内存。
一种是在传统的数据库中，增大缓冲池，将一个事务所涉及的数据都放在缓冲池中，组织成相应的数据结构来进行查询和更新处理，也就是常说的共享内存技术，这种方法优化的主要目标是最小化磁盘访问。
另一种就是内存数据库(MMDB:Main Memory Database，也叫主存数据库)技术，就是干脆重新设计一种数据库管理系统，对查询处理、并发控制与恢复的算法和数据结构进行重新设计，以更有效地使用CPU周期和内存，这种技术近乎把整个数据库放进内存中，因而会产生一些根本性的变化。
两种技术的区别如下表：内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上，更重要的是，从根本上抛弃了磁盘数据管理的许多传统方式，基于全部数据都在内存中管理进行了新的体系结构的设计，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，从而使数据处理速度一般比传统数据库的数据处理速度快很多，一般都在10倍以上，理想情况甚至可以达到1000倍。
而使用共享内存技术的实时系统和使用内存数据库相比有很多不足，由于优化的目标仍然集中在最小化磁盘访问上，很难满足完整的数据库管理的要求，设计的非标准化和软件的专用性造成可伸缩性、可用性和系统的效率都非常低，对于快速部署和简化维护都是不利的。
关系数据库、内存数据库、实时数据库的简单比较
关系数据库、内存数据库、实时数据库的简单比较很多情况下，用户会将实时数据库与关系数据库混为一谈，实际上，这两类产品的设计理念及应用场合是完全不同的。
内存数据库就是将数据放在内存中直接操作的数据库，它利用内存的读写速度比磁盘快、内存是随机访问而磁盘是顺序访问这两个特点，将数据保存在内存中，在内存中模仿建立表结构和索引结构并针对内存特性进行优化，相比从磁盘上访问，内存数据库能够提高应用的性能。
而实时数据库不但利用了内存的特性，而且考虑到工控行业的应用特性，将关系数据库的表结构和表关系简化，以进行性能的优化，并针对工控行业的数据特性，对数据进行压缩处理。
关系数据库、实时数据库与内存数据库相比，有如下差别：从以上的表格可以看出，内存数据库与关系数据库相比，速度快10-20倍左右，且具有与关系数据库类似的完整表结构，因此在电信业处理大量实时事务业务时经常用到，它也可以应用在工控行业，比如，在很多电力行业SCADA软件中，都包含了一个小型的内存数据库系统（但不是真正意义上的内存数据库），但是，在超大型SCADA软件中，它仍不能满足需求，因为它性能比实时数据库慢10倍，且不能解决历史数据存贮的问题，还存在因为掉电导致大量数据丢失的风险。
以上的比较，指标并不全面，也并不是说，实时数据库一定比关系数据库和内存数据库好，只能说，需要针对不同应用的不同需求，做出综合决策，选择最适合自己需要的数据库产品。
最后，列举一些典型的内存数据库产品：■ Oracle TimesTenOracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。
Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。
■ AltibaseAltibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。
内存数据库(sqllite)使用介绍
内存数据库(sqllite)使用介绍数据库的发展数据库技术的发展，已经成为先进信息技术的重要组成部分，是现代计算机信息系统和计算机应用系统的基础和核心。
数据库技术最初产生于20世纪60年代中期，根据数据模型的发展，可以划分为三个阶段：第一代的网状、层次数据库系统；第二代的关系数据库系统；第三代的以面向对象模型为主要特征的数据库系统。
第一代数据库的代表是1969年IBM公司研制的层次模型的数据库管理系统IMS和70年代美国数据库系统语言协商CODASYL下属数据库任务组DBTG提议的网状模型。
层次数据库的数据模型是有根的定向有序树，网状模型对应的是有向图。
这两种数据库奠定了现代数据库发展的基础。
这两种数据库具有如下共同点：1.支持三级模式（外模式、模式、内模式）。
保证数据库系统具有数据与程序的物理独立性和一定的逻辑独立性；2.用存取路径来表示数据之间的联系；3.有独立的数据定义语言；4.导航式的数据操纵语言第二代数据库的主要特征是支持关系数据模型（数据结构、关系操作、数据完整性）。
关系模型具有以下特点：1.关系模型的概念单一，实体和实体之间的连系用关系来表示；2.以关系数学为基础；3.数据的物理存储和存取路径对用户不透明；4.关系数据库语言是非过程化的。
第三代数据库产生于80年代，随着科学技术的不断进步，各个行业领域对数据库技术提出了更多的需求，关系型数据库已经不能完全满足需求，于是产生了第三代数据库。
主要有以下特征：1.支持数据管理、对象管理和知识管理；2.保持和继承了第二代数据库系统的技术；3.对其它系统开放，支持数据库语言标准，支持标准网络协议，有良好的可移植性、可连接性、可扩展性和互操作性等。
第三代数据库支持多种数据模型（比如关系模型和面向对象的模型），并和诸多新技术相结合（比如分布处理技术、并行计算技术、人工智能技术、多媒体技术、模糊技术），广泛应用于多个领域（商业管理、GIS、计划统计等），由此也衍生出多种新的数据库技术。
内存数据库 原理
内存数据库原理内存数据库（In-Memory Database，IMDB）是一种将数据存储在主存储器中的数据库管理系统。
相较于传统磁盘存储的数据库，内存数据库能够提供更快的数据访问速度和更低的延迟。
本文将详细介绍内存数据库的原理。
内存数据库的主要原理是将数据存储在计算机的主存储器中，而不是存储在磁盘上。
这种存储方式带来了两个主要的优势：快速的数据访问速度和低延迟。
相较于读取磁盘的时间，访问主存的时间非常短，因此内存数据库可以实现更快的数据读取和写入操作。
此外，内存数据库还可以充分利用计算机主存储器的多核性能，实现并行处理和高并发访问。
内存数据库的实现有两个主要方面：数据存储和数据管理。
数据存储是指将数据存储在主存储器中的过程，而数据管理则是指对存储在内存中的数据进行管理和操作的过程。
在数据存储方面，内存数据库使用多种技术来优化数据的存储和访问性能。
首先，内存数据库使用了高效的数据结构，如哈希表、红黑树等，来存储和组织数据。
这些数据结构可以提供快速的数据查找和访问操作。
此外，内存数据库还使用了压缩算法来减小数据的存储空间，以提高数据的高效利用率。
压缩算法可以根据数据的特性和存储需求，对数据进行压缩和解压缩操作，从而减小数据的存储空间，提高数据的读写性能。
在数据管理方面，内存数据库采用了一些策略来管理和优化数据的操作。
首先，内存数据库采用了基于内存的索引结构，如B+树、哈希表等，来加速数据的查找和访问操作。
这些索引结构可以提供快速的数据访问和查询，从而减少数据库的访问延迟。
此外，内存数据库还使用了事务管理机制来保证数据的一致性和完整性。
事务管理机制可以对数据的读写操作进行原子性、一致性、隔离性和持久性的管理，从而保证数据的安全性和可靠性。
内存数据库还采用了一系列的技术来提高数据库的性能和可扩展性。
首先，内存数据库使用了预取和延迟写入技术来优化数据的访问效率。
预取技术可以在数据被访问之前将其提前加载到主存储器中，从而减少数据的读取延迟。
内存数据库的使用场景
内存数据库的使用场景
内存数据库是将数据存储在内存中的数据库系统，相比传统的磁盘数据库，它具有更高的性能和响应速度。
以下是一些内存数据库的使用场景：
1. 实时数据分析：内存数据库能够快速加载和处理大量数据，适用于实时数据分析场景，例如在线广告投放、实时风险分析等。
2. 缓存：内存数据库可以用作缓存层，将常用的数据存储在内存中，以提高访问速度和响应性能。
这对于高并发的应用程序和Web服务非常有用。
3. 实时数据处理：内存数据库对于需要快速处理和响应实时数据的应用程序非常适用，例如股票交易系统、实时订单处理等。
4. 临时数据存储：内存数据库可以用于临时存储计算过程中的中间数据，以提高计算性能。
这对于大数据处理和复杂计算任务非常有用。
5. 互动游戏：内存数据库能够处理高并发的游戏交互数据，例如玩家位置、角色状态等，保证游戏的流畅性和实时性。
总之，内存数据库适用于需要高性能和实时响应的场景，特别是对数据访问速度和响应时间有较高要求的应用程序。
但需要注意的是，由于内存数据库将数据存储在内存中，数据的持久性和容错能力相对较弱，不适用于需要长期存储和大容量数据的应用。
oc内存数据库uu
内存数据库
内存数据库，顾名思义就是将数据放在内存中直接操作的数据库。
相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。
同时，内存数据库抛弃了磁盘数据管理的传统方式，基于全部数据都在内存中重新设计了体系结构，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，所以数据处理速度比传统数据库的数据处理速度要快很多，一般都在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;0B为一个内存数据库，简称为MMDB。
特点
数据存储在内存中，导入快，修改快，查询快.如果不预先备份到硬盘中，关机就会丢失.。
内存数据库 关键技术
内存数据库关键技术
内存数据库的关键技术包括：
1. 内存管理：内存数据库主要使用内存作为数据存储介质，需要有效管理内存的分配和释放，以提高数据读写的性能。
内存管理技术包括内存分配算法、缓存管理、内存回收等。
2. 数据存储和索引：内存数据库需要设计高效的数据存储结构和索引结构，以快速访问和查询数据。
常见的数据存储结构包括哈希表、B+树等，索引结构包括B+树索引、哈希索引等。
3. 数据一致性和事务处理：内存数据库需要保证数据的一致性和事务的原子性、一致性、隔离性和持久性（ACID特性）。
事务处理技术包括并发控制、锁机制、日志记录和恢复等。
4. 数据压缩和压缩算法：由于内存存储空间有限，内存数据库需要使用数据压缩技术来减少数据占用的内存空间。
常见的数据压缩算法包括LZ77、LZ78、LZW等。
5. 并发控制：内存数据库需要支持多线程或多进程的并发访问和操作，需要采用合适的并发控制技术来保证数据的一致性和并发性能。
常见的并发控制技术包括锁机制、MVCC（多版本并发控制）等。
6. 高可用和容错性：内存数据库需要具备高可用性和容错性，以保证系统的稳定性和可靠性。
常见的高可用和容错技术包括主从复制、
故障恢复、数据备份和恢复等。
7. 数据持久化：内存数据库需要提供数据持久化的能力，以避免系统故障或断电等导致数据丢失。
常见的数据持久化技术包括日志记录和恢复、快照和冷备份等。
8. 分布式架构：对于大规模数据和高并发访问的场景，内存数据库需要支持分布式架构，以实现数据的水平扩展和负载均衡。
常见的分布式架构技术包括分片和分区、一致性哈希等。
内存数据库
• 内存数据库是通过将系统的常用数据库表中的数据全部映射到主机共享内存， 并且在数据库表上的关键字段上建立内存索引的方式，来提高系统对关键数 据的实时访问性能。应用程序在访问这些数据库表时，通过调用内存数据库 API 接口来使用共享内存中的数据，而不是直接访问物理数据库表中的数据， 这样，极大的提高了系统的实时性能。内存数据库通过同步更新接口来完成 与物理数据库的数据更新，保证内存数据库与物理数据库中数据的一致性。
• 采用内存技术管理和访问数据，加快数据处理速度。 • 系统中，对系统的实时性能要求非常高。而使用传统的数据库访问技术对数
据大量访问的性能比较低，不能满足高效处理的要求，因此需要在系统中采 用内存数据库技数据库：选型
• 内存数据管理，与应用能够紧密集成，运行效率很高，数据完整性和数据同 步性能也能够满足系统要求，对系统性能提高有非常大的帮助，但内存数据 管理在系统故障时的切换速度较慢。
• 我们对ORACLE的TimesTen进行了初步的测试，TT基本能够满足系统的要求， 但使用TT，需要对应用进行大规模改动，集成商认为对系统有较大的风险。
• 内存数据库选型还需进一步的测试和验证。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
内存数据库实时交易系统的催化剂现在，支持实时应用程序（如证券交易系统）的基础架构软件已经面市。
内存数据库（IMDB）是这种基础架构的核心部分。
与IMDB 所替代的各种定制产品不同，基于IMDB技术的商用产品不仅仅具有高性能，还增加了消息处理接口、符合行业标准的API、事务处理、容错故障切换和恢复、事件发布和与后台RDBMS的连接。
今天，精简的开发团队有足够的能力处理应用程序级的更改。
他们已不再需要在“应用程序底层”编写代码，而且与当今经过证实的可选商用方案相比，这也不再是一个审慎的策略。
内存数据库实时交易系统的催化剂现在，支持实时应用程序（如证券交易系统）的基础架构软件已经面市。
内存数据库（IMDB）是这种基础架构的核心部分。
与IMDB 所替代的各种定制产品不同，基于IMDB技术的商用产品不仅仅具有高性能，还增加了消息处理接口、符合行业标准的API、事务处理、容错故障切换和恢复、事件发布和与后台RDBMS的连接。
今天，精简的开发团队有足够的能力处理应用程序级的更改。
他们已不再需要在“应用程序底层”编写代码，而且与当今经过证实的可选商用方案相比，这也不再是一个审慎的策略。
引言：对速度的需求永无止境对于证券交易系统来说，持续的熊市并未减少交易处理量。
当然，货币交易量大大减少了，这是因为美国市场在采用十进制最小报价单位之后平均价差变小了。
但系统依旧忙于买卖盘传递、对盘和跟踪交易订单。
事实上，纳斯达克报告的统计数据表明当前的股票交易量与2000年底股市动荡时期的交易量大致持平（参见图1）。
造成这种现象的原因是交易策略和习惯发生了某些重大改变，包括对冲基金的迅猛普及和程式交易的惊人增长。
很多投资者采取短期买进卖出策略，这反映了股市的不稳定性。
交易执行的速度和交易价格成为了最重要的问题。
因此，处理投资者业务的交易系统的速度和质量也成为了最重要的方面。
自给自足的困境直到目前，支持这种高要求应用程序的商用基础架构软件仍未出现，这使得项目团队不得不在“应用程序底层”进行软件开发，以确保在不损失可靠性的前提下实现高性能。
通常把对时间要求高的数据集结到内存中待命，以避免RDBMS所固有的延迟——即使速度最快的RDBMS也存在延迟。
数据存储在内存中有助于提高定价、买卖盘传递、对盘、持仓量跟踪、交易商提醒、程式交易和风险分析等功能。
一个公司是否具有竞争力取决于其能否在这些关键功能上与市场同步发展。
如果没有最佳性能，交易策略将被忽视，价格改进也将难以进行。
交易公司感到必须开发内存数据管理技术的原因并不难理解。
因为市场上没有此类商用产品可供选择，而且几年前，盈利的交易所能很容易地为这类开发和维护筹集到资金。
但尽管如此，这仍是一项富有挑战性的工作，远远不同于应用程序开发。
基础架构不但要能运行，而且它还必须绝对可靠，决不能丢失一项交易。
因此，这些实施在功能方面比较简单，并被紧密结合到应用系统中，以最大限度地降低复杂性。
它们确实起作用，但无法轻松快速地加以修改，且成本很高。
“花费更少，做得更多”的时代本世纪初以来发生的变化使证券行业产生了巨变。
经济衰退和十进制报价方式的采用共同破坏了以价差为基础的商业模式。
新的法规、新的交易策略和新的交易执行场等这些其他方面的变化都促使交易系统不断完善。
这要求精简的开发团队在紧迫的时间内重建应用程序和基础架构。
对于多数公司来说，这两者难以取得平衡。
风险很高，因为证券交易经济学指出，出于规模经济和自然进化的原因，整合的趋势是形成那种提供最低交易成本、最多服务选择和最有可能改进价格的公司。
金融公司已无力再承受构建基础架构软件的重担了，其具有基本特性和自行开发的技术的系统也不再具有竞争力。
如今的交易操作要求得更多——可伸缩性、绝对可靠性、用于灾难恢复的同步备份站点、预交易分析、事件驱动的提醒、实时持仓量跟踪。
这些都是决定竞争力的基本问题。
商用内存数据库（IMDB ）产品及其所附带的功能可明显减少完成这些项目的风险和时间。
开发人员能够专注于重组其应用程序逻辑，并利用专门为实时、高可靠性系统构建的基础架构软件。
IMDB 产品支持通用的行业标准接口，能实现更简易的集成和未来的可伸缩性。
现在，精简的开发团队极有可能顺利完成任务。
针对实时应用程序的基础架构软件 上面描述的困境并不仅限于资本市场的应用程序。
其他行业，如电信、运输与物流和工厂自动化等行业也存在对性能要求极高的应用程序，这些系统也要求开发支持性的基础架构软件。
根本问题是基础架构软件一直以来都是针对“企业”这个广大的市场进行商用化的。
企业软件的目标是满足尽可能多的公司和应用程序的需要。
而高要求的应用程序，如证券交易系统则不是这些产品的侧重点。
随着时间的推移，供应商在其产品中加入了过多的旨在扩大适用性的功能，因而这个缺口不可避免地扩大了。
现在，RDBMS 和应用服务器产品就是这种状况。
这些产品在大型经纪和证券交易公司的前台办公交易基础架构中罕有应用（参见图2）。
突出重点理想的支持交易系统的商用基础架构软件应包括RDBMS 的核心部分（用于数据管理）和应用服务器（用于集成和容错）——侧重于最大限度地提高性能和可用性并且使开发人员只需专注于编写业务逻辑。
此外，这种基础架构还应该适用于流行的和新兴的硬件平台——从运行Unix 、Linux 或Windows的多处理器系统到新的构建模块刀片式服务器配置。
内存数据库是应企业对实时基础架构软件的需求而开发的核心技术。
实时基础架构软件需要的很多功能都涉及数据管理功能，或者是对该功能的扩展。
接下来本文分析了内存数据库的属性和应用程序，阐述了附加功能的发展趋势，随着时间的推移，这将形成一个基本完整的实时基础架构软件的解决方案。
内存数据库（IMDB）过去十年间计算机架构的重要改进促进了内存数据库技术的崛起。
CPU性能（按电路密集度测量）平均每一年半提高一倍。
内存芯片的容量也平均每一年半增加一倍，而价格下跌一倍。
现在，1GB 的服务器物理内存约为400美元。
相对较小、具有32GB标准内存的服务器的处理能力超过100GB。
十年前，具有这样内存容量的计算机很少有甚至不存在，而且其价格很少有几家企业能够承担得起（参见图3）。
磁盘性能的提高则缓慢得多。
因此，CPU和磁盘之间的性能差距明显增大。
对多数计算机用户来说，这已不是什么新闻。
众所周知，数据管理软件（如RDBMS）试图在内存中存储尽可能多的数据，以避免磁盘访问所造成的性能损失。
多数人没有认识到的是，传统的RDBMS产品已成功解决了他们迫切要求解决的磁盘瓶颈问题。
随着时间的推移，RDBMS产品已变得相当成熟，它们能够预测哪些数据应在内存保存最长时间，以及何时应将新数据从磁盘取到内存中。
这些算法的正确率一般在75%以上，因此基本不存在由于应用系统等待磁盘I/O而造成的性能损失。
并且，如果数据库规模足够小，能整个存入内存，那么RDBMS也能让你这样做。
软件研究人员解决了这个难题。
20世纪90年代，他们发明了新的数据库系统设计方法，着重于使必要的CPU消耗量最少。
由于硬件系统会具有大量的内存，因此他们设计了这些具有常驻内存数据的架构，从而不必采用旨在解决磁盘瓶颈、但消耗CPU资源的逻辑。
依靠常驻于内存的数据，这些研究人员就能够重新设计数据和索引结构以进一步减少必需的处理。
这些设计仍然使用磁盘，但仅仅是为了在出现系统故障时提供数据持久性和数据恢复，犹如先前使用磁带机为磁盘进行备份一样。
内存数据库技术的最终使执行标准数据库操作时所需的CPU资源极大地减少了——与完全高速缓存的RDBMS相比要少得多。
实际的差异完全取决于所做的工作。
速度提高在读取操作（如参考数据查询）方面表现得最明显。
写入操作可能需要将一些变化记录到磁盘上以确保可恢复性，所以磁盘操作会在某种程度上降低写入操作的速度。
实际中，应用程序很少只执行读取操作或只执行写入操作，而是两者都会执行。
例如，处理交易订单包括读取、更新和插入多项操作。
就相同应用程序而言，IMDB的执行速度通常比使用高速缓存的RDBMS快10倍（或换言之，消耗的CPU资源是后者的1/10）。
确切地说，虽然与几年前相比IMDB现在能够访问的内存数据量增大了许多，但它在数据库容量方面仍然无法与RDBMS相提并论。
因此如果适于使用IMDB，那么在多数情况下也将存在后台办公RDBMS，用于为IMDB提供参考数据和/或接收来自IMDB的完成的交易（参见图4）。
直到20世纪90年代末，才出现了基于内存数据库技术的商用产品，并且直到最近，这些产品才达到了用户可以使用、功能完善的水平，这使它们有可能被广泛使用。
随着计算技术的发展，软件架构也必然会发展。
然而，令人惊讶的是，直到现在，大型行业如资本市场和电信业仍然不会去购买商用解决方案，并且只有经济衰退和结构剧变才会迫使公司去评估是自己构建还是购买。
似乎技术的自给自足形成了一种自己构建的思维方式。
将IMDB与RDBMS比较是有指导意义的，但对于大型交易系统，这种比较是没有任何意义的。
如前文所述，这类系统中已采用定制的高速缓存和内存数据结构。
如果它们实施得合适，那么它们应能运行得很好，虽然只是在有限的环境下（主要是读取操作，或少量更新）。
与定制的内存解决方案相比，应用系统开发是商用IMDB产品有突出优势的方面。
和RDBMS一样，IMDB产品提供标准的编程接口，将应用程序代码与IMDB的工作相分离。
因此，众多开发人员将借助IMDB迅速提高效率。
定制的内存解决方案很少包含一个将应用程序彼此分离，或将应用程序代码与内存逻辑相分离的编程层。
应用程序和数据结构倾向于紧密结合，这使得以后在需要添加特性时它们很难被分开。
而使用IMDB产品的应用程序则能够在不影响其他应用程序的情况下轻松修改和添加新功能。
这样的灵活程度对于当今不断变化的证券行业来说是无价的。
数据完整性和功能丰富是IMDB产品另外的主要优点。
开发只读内存高速缓存是一回事，而开发具有多用户锁定、写日志、恢复和对更改备份以提高可用性的读写交易系统则完全是另一回事。
事实上，IMDB产品的成本可能会少于脆弱的定制实施发生数个交易丢失造成的损失。
更广阔的远景完整的实时交易系统基础架构不仅仅提供数据管理功能。
理想情况是，开发人员应当仅需要编写交易应用程序的业务逻辑，基础架构负责其他所有工作。
对于多数应用程序而言，这意味着要集成消息传递中间件、交易计划和执行、与后台办公RDBMS的透明连接、向外发布数据（用于交易商提醒、程式交易或实时数据快照）以及自动进行故障切换和恢复以确保没有数据或消息丢失。
拥有设计良好的IMDB技术基础后，再苛刻的要求也能够达到。
在不久的将来，金融公司将不会再为了支持他们的业务应用系统而在“应用程序底层”编写代码。