Oracle 的内存数据库 TimesTen
Oracle 的内存数据库 TimesTen 从某种角度上来看，也是一种 Cache 机制，是磁盘数据库的 'Cache'，通过物理内存中的数据存储区的直接操作，减少了到磁盘间的 I/O 交互。TimesTen 中的这个 Ten 据说就是指速度能达到基于磁盘的 RDBMS 10倍，从去年开始在国内市场也有很多活动，逐渐吸引了很多技术人员的注意。实际上，这个产品也是有一定潜在市场的。
TimeTen 资料大全：http://lindows.javaeye.com/blog/459615
TimesTen 与基于磁盘的 RDBMS 架构的比较
这个示意图引用自 Oracle TimesTen In-Memory Database Introduction，下载该文档请到官方网站。
这个数据库 的 License 报价并不贵，List 价格是 $12K/CPU，对于响应速度要求比较高，可靠性要求不是非常非常高(安装 TimesTen 的系统内存可靠性会比你的 SAN 存储系统可靠性高么?)的系统，TimesTen 作为大事务数据库的前端数据库会是一个不错的选择：
MS-SQL 有没有内存数据库？
问 ：MS SQL server (微软数据库)有类似于 oracle数据库的TimesTen内存数据库产品吗？
答：没有嘿。
另一种内存数据库 —— eXtremeDB
eXtremeDB实时数据库是一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒一级。接口语言包括C、C＋＋、嵌入式SQL、JNI等，通过定制数据库根据应用动态生成。使用时通过接口编程，编译链接时将eXtremeDB内核嵌入到应用程序中。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘在内）。eXtremeDB通过交易机制保证数据一致性来支持本地多进程或多线程，通过RPC或RSQL实现网络化访问。eXtremeDB通过eXtremeLog实现磁盘镜像、通过eXtremeHA实现内存镜像进行自动在线备份以保证数据安全。eXtremeDB支持各种平台，包括Solaris、HPUX、Windows、Linux、VxWorks、eCos等各种OS，运行在x86、ARM、PowerPC、MIPS等各种处理器上。体验eXtremeDB会有一种耳目一新的感觉。
提供免费下载评估：
http://www.leadingtek.com.cn
感兴趣的朋友可以评估一下这一崭新的实时数据管理技术。小弟也是新手，期待大家共同交流 多多互相学习。
eXtremeDB在管理实时数据的时候，有这样的优点：
.功能特别全。
eXtremeDB将数据保存在内存中，在内存中建立数据结构，在数据结构上提供数据库API，这些API提供了通常只有在企业数据库上才有的各种数据管理功能，如表结构、交易管理、HASH索引、树索引、OID、Autoid、引用、历史版本、事件触发等。在eXtremeDB的表中，不仅可以支持通常的简单数据，而且可以支持结构和矢量等等复杂数据。这对诸如机顶盒等应用领域而言，特别有利。
.性能特别高。
由于数据是保存在内存中，因此，每次插入、检索、更新数据的操作都非常快。通常，在400MHz的处理器上一个交易的时间只有1～2微秒。这要比静态数据管理或常规数据库的性能要高很多。
.硬件要求特别低。
eXtremeDB在使用的时候，基本开销只有50K～100K尺寸；管理数据的效率高达70％～80％。相比而言，Oracle等商业数据库或我们自己编写的数据管理软件，效率在10％～20％左右。以我们为Genesis Microchip做的参考设计而言，管理152K个节目信息，包括标题索引、内容索引等诸多功能的数据库，占用内存的尺寸在8～9M左右。在我们的EPG参考设计中，如果用400MHz的处理器，检索一个节目的时间机会感觉不到。
.开发非常方便
eXtremeDB的数据库系统以C/C++的Library的形式提供给用户，与用户的程序无缝集成在一个运行程序之中。开发过程流畅，使用非常方便。
提供免费下载评估：
http://www.leadingtek.com.cn
感兴趣的朋友可以评估一下这一崭新的实时数据管理技术。小弟也是新手，期待大家共同交流 多多互相学习。
eXtremeDB在管理实时数据的时候，有这样的优点：
.功能特别全。
eXtremeDB将数据保存在内存中，在内存中建立数据结构，在数据结构上提供数据库API，这些API提供了通常只有在企业数据库上才有的各种数据管理功能，如表结构、交易管理、HASH索引、树索引、OID、Autoid、引用、历史版本、事件触发等。在eXtremeDB的表中，不仅可以支持通常的简单数据，而且可以支持结构和矢量等等复杂数据。这对诸如机顶盒等应用领域而言，特别有利。
.性能特别高。
由于数据是保存在内存中，因此，每次插入、检索、更新数据的操作都非常快。通常，在400MHz的处理器上一个交易的时间只有1～2微秒。这要比静态数据管理或常规数据库的性能要高很多。
.硬件要求特别低。
eXtremeDB在使用的时候，基本开销只有50K～100K尺寸；管理数据的效率高达70％～80％。相比而言，Oracle等商业数据库或我们自己编写的数据管理软件，效率在10％～20％左右。以我们为Genesis Microchip做的参考设计而言，管理152K个节目信息，包括标题索引、内容索引等诸多功能的数据库，占用内存的尺寸在8～9M左右。在我们的EPG参考设计中，如果用400MHz的处理器，检索一个节目的时间机会感觉不到。
.开发非常方便
eXtremeDB的数据库系统以C/C++的Library的形式提供给用户，与用户的程序无缝集成在一个运行程序之中。开发过程流畅，使用非常方便。
建立自己的内存数据库 —— 有意思
现在的内存便宜,16G以上内存的服务器已不少见.大内存的确让你的服务器运行程度加快了不少.但有些分析报表,总产生N个中间的表,数据在里面倒来倒去,从这个表合计到那个表.不但速度很慢,而且,这个过程还有可能影响了正常的业务.减慢了服务器的响应时间.
也经常有人出于业务的考虑,如某些系统要实时数据采集,有些系统可能每秒有上万条的 INSERT INTO 量.我看了一下相关的回复,大体上都是增加硬盘,应用分布式管理,表分区等等..一句话.基本上是砸钱加硬件. :) .这的确是好办法.不过,现在是经济
危机,尤其是中小型企业,每一分钱都算得紧紧的,我相信你这个DBA也很难向老板开口.
也经常有人出于业务的考虑,如某些系统要实时数据采集,有些系统可能每秒有上万条的 INSERT INTO 量.我看了一下相关的回复,大体上都是增加硬盘,应用分布式管理,表分区等等..一句话.基本上是砸钱加硬件. :) .这的确是好办法.不过,现在是经济
危机,尤其是中小型企业,每一分钱都算得紧紧的,我相信你这个DBA也很难向老板开口.
不扯了,如果真的要在内存中建一个数据库,不难,很简单.
1.下载一个 ramdisk 或类拟的软件,先在2G左右的内存虚拟成一个硬盘.
2.在你的实体硬盘上建立一个空的数据库(直接在虚拟盘中建库是不可能的). 设置这个库的事务方式为简单.
3.分离这个新建的库.
4.将这个库 COPY 到你的虚拟盘上,然后附加.
我在我的电脑上测试:L730T + 2G + 320G.
100万条,基本是每秒 INSERT INTO 20000 条左右,而且,这个数据很平稳.
OK,你的内存数据库完成了.
以后呢,凡是分析报表扯到的临时中间表,都可以放到这个库里,用完就KILL,或者你有很多实时数据要采集,也放到这个库里(要注意隔一定时间回写到实体表,还要注意断电. :)
1.下载一个 ramdisk 或类拟的软件,先在2G左右的内存虚拟成一个硬盘.
2.在你的实体硬盘上建立一个空的数据库(直接在虚拟盘中建库是不可能的). 设置这个库的事务方式为简单.
3.分离这个新建的库.
4.将这个库 COPY 到你的虚拟盘上,然后附加.
我在我的电脑上测试:L730T + 2G + 320G.
100万条,基本是每秒 INSERT INTO 20000 条左右,而且,这个数据很平稳.
OK,你的内存数据库完成了.
以后呢,凡是分析报表扯到的临时中间表,都可以放到这个库里,用完就KILL,或者你有很多实时数据要采集,也放到这个库里(要注意隔一定时间回写到实体表,还要注意断电. :)
关于这篇文章的讨论：
如果能解决可靠性的问题后,确实是个好办法,用ramdisk跑大型软件的话,根据我的经验确实很不错,就象楼主说的要解决安全的问题.
顺便说下,其实市面上有卖日本某公司ram disk硬盘,价格其实也不是太贵,sata接口的.用的是ddr2的内存,一般是32g或者64g的,速度和楼主说的没有什么区别,不过使用上要方便的多.
顺便说下,其实市面上有卖日本某公司ram disk硬盘,价格其实也不是太贵,sata接口的.用的是ddr2的内存,一般是32g或者64g的,速度和楼主说的没有什么区别,不过使用上要方便的多.
生产环境是不可能这你这么玩的.
这只是举了一个应用点。
某个方法是不可能适合所有场景的，我的意思是说，在有些时候，通用内存库来存放统计的中间表或实时要求高的表，可以减少IO，提高服务器的并发数和响应时间。至于有人说还不如将这2G的内存留给SQL，呵呵，你发现过没有？你的数据库只有2个G，内存有十几个G，SQLSERVER一样能把它占满。SQL缓冲机制其实是很傻的。如果人为地，有目的地划一个内存区域来操作，从内存的利用率和前台执行效能来说。这要比SQL自己管理要高得多。
某个方法是不可能适合所有场景的，我的意思是说，在有些时候，通用内存库来存放统计的中间表或实时要求高的表，可以减少IO，提高服务器的并发数和响应时间。至于有人说还不如将这2G的内存留给SQL，呵呵，你发现过没有？你的数据库只有2个G，内存有十几个G，SQLSERVER一样能把它占满。SQL缓冲机制其实是很傻的。如果人为地，有目的地划一个内存区域来操作，从内存的利用率和前台执行效能来说。这要比SQL自己管理要高得多。
看了一些回复，可能大部分人不知道主动缓冲的重要性。
这实质就是主动的缓冲的一种方式。我只是用了SQLSERVER举了一个例子。
主动缓冲对 大型网站，大型的商务应用，是非常必要的。以前我们一般是手工去做，做了一堆LIST（OF T） 的泛型，写了一大堆的静态类来实现这种复杂的逻辑。非常麻烦。写过类拟功能的兄弟肯定知道。
其实，思路再放宽那么一点点，如不用SQLSERVER，用文件型的数据库，如MYSQL。 ：） ，效果会更好。效率也更高。在三层应用中，中间放一个MYSQL的内存库（注：MYSQL中有内存表的概念，但效率也好不到哪里去，与这个是两回事）。做一个独立的类来管理它，你的网站经这一个小小的改动，它的并发量将是十倍八倍地增长。
说了这么多，绝招都教出去了。后悔！！哈哈。。。
这实质就是主动的缓冲的一种方式。我只是用了SQLSERVER举了一个例子。
主动缓冲对 大型网站，大型的商务应用，是非常必要的。以前我们一般是手工去做，做了一堆LIST（OF T） 的泛型，写了一大堆的静态类来实现这种复杂的逻辑。非常麻烦。写过类拟功能的兄弟肯定知道。
其实，思路再放宽那么一点点，如不用SQLSERVER，用文件型的数据库，如MYSQL。 ：） ，效果会更好。效率也更高。在三层应用中，中间放一个MYSQL的内存库（注：MYSQL中有内存表的概念，但效率也好不到哪里去，与这个是两回事）。做一个独立的类来管理它，你的网站经这一个小小的改动，它的并发量将是十倍八倍地增长。
说了这么多，绝招都教出去了。后悔！！哈哈。。。
以前经历过不少面试，问的问题五花八门。应聘过DBA，也被一些简单的问题问住。他们不问我一个进销存怎样设计，不问我MRP如何设计。。。。他们好象不关心应聘者的对一个系统的全局观，却喜欢考一些他们的“研究”成果。三句都是，我们怎样怎样。。。
走出别人的大门后，自己也觉得有点可笑。做SQLSERVER的人，大部分都觉得SQLSERVER就是全部。做DB2的人，也认为DB2就是全部。。。。。
呵呵。。不说了，再说就得罪人了
走出别人的大门后，自己也觉得有点可笑。做SQLSERVER的人，大部分都觉得SQLSERVER就是全部。做DB2的人，也认为DB2就是全部。。。。。
呵呵。。不说了，再说就得罪人了
你这样说“将整个库放到内存中运行.修改时既修改虚拟库,也修改实体库.这样也可以减少了IO,也能非常有效率地提高数据的访问速度”，这样做了两次同样的操作会有弊病，1是如果访问量过多的话浪费了CPU的使用率，2就是读写内存的速度比硬盘的读写的速度要快，这样就不能实现同步也影响了速度，这样对一个数据库来说任务量非常的大。 按你的想法来说，如果说在内存中有够量的数据，按时间和比率来批量向硬盘上的实体表写入，这样可以提高效率
作为中间运算，把Temp数据弄过去就好
对于其他应用，微软在这一点不可能改变
因为对于数据库持久化是第一位的，也就是说除了临时数据，任何事务，微软都要先存盘的
对于其他应用，微软在这一点不可能改变
因为对于数据库持久化是第一位的，也就是说除了临时数据，任何事务，微软都要先存盘的
赞一下楼主的想法，有创意.
不过用在生产环境应该是不大合适滴
不过用在生产环境应该是不大合适滴
