内存数据库

内存数据库实时交易系统的催化剂现在，支持实时应用程序（如证券交易系统）的基础架构软件已经面市。

内存数据库（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技术基础后，再苛刻的要求也能够达到。

在不久的将来，金融公司将不会再为了支持他们的业务应用系统而在“应用程序底层”编写代码。