内存数据库(或IMDB)可以是一个独立的数据库管理系统(DBMS)，如Oracle的TimesTen，或者从属于DBMS的一个特殊数据库，如SAP Sybase Adaptive Server Enterprise (ASE)。
IMDB的目标是通过使用计算机内存实现数据存储来提高吞吐量和降低延迟。这与使用磁盘存储的传统数据库管理系统不同。由于内部优化算法更简单，而且执行的CPU指令较少，所以内存内数据的速度比基于磁盘的数据库快。访问内存数据可以提高响应速度。对于一些响应时间要求较高的应用程序，如交易、电信和国防系统，一般都会使用IMDB。由于IMDB的这种特性，这些数据库使用内存要多于磁盘数据库产品。
Oracle TimesTen和Sybase ASE-IMDB是一种使用过程外主内存的数据库。它们实现了SQL的完整支持，也支持一些特殊语言、安全性和数据库管理。这两种数据库都支持通过SQL访问数据。它们都具有一些磁盘数据库产品的特性。因此，使用这些产品缓存SQL后台持久化数据库的SQL请求就很简单。
TimesTen、ASE-IMDB及现有的所有商业内存数据库都基于所谓的基于行的关系存储模型。这些产品很适合OLTP应用程序使用。
Oracle TimesTen内存数据库是什么？
Oracle TimesTen是一个全新设计的内存数据库。它使用基于行的关系模型(表、列、数据类型、索引等)实现数据存储，并使用SQL作为访问语言。它提供了许多API，并且支持Oracle PL/SQL。应用程序的访问方式与其他关系数据库完全相同。TimesTen与传统数据库的主要区别在于它的性能要远远高于传统数据库。虽然TimesTen完全运行在内存中，但是它也能够在磁盘中创建数据库副本，支持数据库重启和恢复。通过检查点和事务日志，这种副本能够保持更新，因此能够从任何故障事故中恢复。TimesTen支持一种用于实现高可用性的复制机制。它的Cache Connect功能可以作为后台Oracle数据库数据子集的高速缓存。在这种情况中，它就成为Oracle数据库的内存数据库缓存。
在C/S模式中，客户端API库通常使用TCP/IP(但是有时也会使用UNIX域套接字或本地共享内存连接)与TimesTen服务器进程交换请求和响应，以执行实际的数据库访问。这正是在TimesTen数据库主机之外运行应用程序的常用模式。除了网络回程所造成的延迟，各个数据库访问造成的代码增加、环境切换等问题也会对性能造成影响。
只有当应用程序和TimesTen运行在同一台主机上时，才会使用直接模式。在这种模式下，数据管理器API库基本上就是充当TimesTen数据库引擎的作用。API调用是进程内函数调用，而TimesTen数据库(共享内存片段)会映射到应用程序的地址空间。这样可以消除数据库访问路径的切换竞争，实现最高的性能和最低的延迟，从而保持稳定的输出。
TimesTen数据库也经常采用混合模式的并发访问，即不同的应用程序进程/线程会通过直接模式和客户端/服务器模式并发访问数据库。单个数据库可以支持最高2000个用户连接。如果TimesTen具有一个实例(管理多个TimesTen数据库)，那么用户连接数限制为2500。
这两种模式在API层只有极少的差别，所以在一般的应用程序代码中，不需要知道或关心所使用的模式——它实际上只是一个在编译时或运行时的配置选择。
直接模式是TimesTen的特殊特性之一。大多数TimesTen生产部署都采用独立或直接模式。然而，在一些情况下也会使用客户端/服务器模式。
TimesTen缓存不能通过一般的关系工具访问。如果应用程序拥有以数据库为中心的数据访问方式——即，使用SQL和JDBS访问数据，那么TimesTen是最佳的选择。然而，TimesTen本身不支持与非Oracle数据库进行互操作，所以应用程序代码必须自行管理TimesTen与Sybase或其他数据库的数据传输。
TimesTen的内存结构
TimesTen内存结构比Oracle数据库简单很多。与Oracle不同，TimesTen并没有数据库缓冲区、保存池或丢弃池的概念。传统数据库系统都会通过使用一些减少磁盘I/O的策略。这种设计策略源于磁盘I/O对数据库性能的影响。相反，内存数据库从一开始就不存在磁盘I/O问题。它们的最高优化目标就是减少内存和CPU需求。
TimesTen目前支持两种索引方式：散列索引和T树索引。散列索引仅支持全键-值查找，但是速度非常快，而且执行过程与底层表的数量无关(只要它们的大小合适并且忽略小型表的硬件L1/L2/L3缓存效果)。这些索引具有很高的读取扩展性和很好的并发性。T树索引的读取效率很高，但是散列索引效率不高。如果支持范围查找，那么它们会更灵活。但是，其中有一个弱点是在繁重写操作时并发性较差，因为每个索引修改都必须锁住整个索引。然而，在低延迟条件下，T树索引的写性能非常好。
TimesTen的应用
TimesTen的主要价值在于响应时间，而吞吐量和高可用性则是第二位。TimesTen一般更利于OLTP风格的工作负载，因为这些负载要求极低且极稳定的响应时间。此外，同样重要的是冗余性。通常，一个数据库服务器上会运行多个应用程序。在这些应用程序服务器上使用TimesTen可以减少数据库的负载，因此能够减少网络延迟和磁盘I/O。
例如，有一些交易系统会在网页上显示价格信息。如果不使用TimesTen，那么应用程序服务器就需要不停地从磁盘数据库查询价格信息。在达到每秒100,000次的查询水平时，数据库性能就会急剧下降。TimesTen与应用层关系密切，而典型的DBMS则具有更广泛的用途。在实时响应与适度容量方面，使用TimesTen具有任何经典DBMS无法实现的压倒性优势。在一些数据快速变化的领域，如交易和销售数据管理，TimesTen极有明显的优势，因为数据是实时传输的，而计算也必须以接近实时的速度完成，并且只对执行引擎产生很小的影响。另一些应用领域包括电信、国防和情报等机构。
Sybase ASE内存数据库结构
ASE在它的15.5版本中加入了自己的内存数据库(IMDB)。ASE-IMDB可以追溯到Sybase的Real Analytics Platform (RAP)，但这是ASE第一次以IMDB产品出现。
与TimesTen类似，ASE-IMDB也是高性能数据库，它完全整合到Sybase ASE平台中。这一点与TimesTen相反，因为后者是一个完全独立的数据库。ASE-IMDB可以读写同一个Sybase ASE中其他的数据库，并且可以接收其他ASE或非ASE数据库的数据。ASE-IMDB还使用复制技术接收来自所有这些数据源的数据。
ASE经典数据库是专门面向那些严格遵守ACID(原子性、一致性、隔离性、持久性)事务语义的应用程序。这些ACID属性以提前写事务日志、定位持久化存储(例如，磁盘)等手段实现。在这个方面，ASE-IMDB允许在低响应时间和高吞吐量的数据交换中放宽持久性和原子性要求。这一点与TimesTen相反，后者完全遵守ACID。
要运行ASE-IMDB，您必须拥有足够的缓存，才能够将整个数据库运行在内存中。一旦创建了这个专用的缓存，它就成为IMDB的设备载体，数据库就能够在这些内存设备上创建。ASE-IMDB是基于一个可用的模板数据库创建的。模板数据库是一个经典的ASE数据库。启动的ASE-IMDB会继承模板数据库的所有对象和数据。创建ASE-IMDB的典型语法是：
| create inmemory database ASEIMDB use ASEIMDB_template as template on ASEIMDB_data01='4000M' log on ASEIMDB_log01='1000M' with durability = no_recovery |
这种方法很简洁，数据库管理员都能够更容易地掌握。注意，在上面的语法中，它显示引用了一个模板数据库——这里是ASEIMDB_template 。此外，持久性必须设置为no recovery，这意味着ASE-IMDB数据库不可恢复。因此，ASE-IMDB的所有内容在ASE服务器重启或意外关闭时都会丢失，因为这种方式不使用持久化存储。另一方面，它允许Sybase优化事务日志(它完全在内存中进行);由于在ASE 重启时，IMDB完全不需要从事务日志恢复，所以您可以获得更优的事务可扩展性和更高的性能。
ASE-IMDB的索引算法没有任何变化。换而言之，数据库运行在内存中时，其消耗的存储空间不会有任何变化。在处理大容量数据时，需要增加大量的内存，才能够支撑内存内运行。由于您可以将常规的ASE数据库转储和加载到ASE-IMDB中，所以您可以使用ASE经典数据库的现有索引，从而实现全面兼容性。
ASE-IMDB的应用
如果已经在使用ASE，那么只需要获得授权就可以使用ASE-IMDB。ASE-IMDB主要面向写密集型应用程序，其中数据持久化是第二位考虑特性。我认为，应用程序必须清晰规定IMDB是否支持可恢复性。有一些应用程序并不需要恢复支持。这些应用程序可以部署ASE-IMDB以提高性能。
由于ASE-IMDB可以完全整合在混合结构的经典服务器中，它完全支持ASE本身的SQL语法、安全性和加密。电子商务、购物车、特殊交易系统及清理数据后提交到经典数据库的分段/中间数据库，都是适合使用ASE-IMDB的例子。此外，它还能够通过一些普通复制方法从其他数据源接收数据，这使得ASE-IMDB成为一些有快速响应需求公司的首选工具。ASE-IMDB快速复制到其他数据库的功能仍在开发中。然而，如果您的应用程序迫切需要恢复功能，那么ASE-IMDB可能不适合这个要求。
来源：oschina
链接：https://my.oschina.net/u/138694/blog/61536