内存数据库有几个人用过？

内存数据库很多，但是还是存在一个盒子的限制，一个内存数据库也是一个设备，一个设备就有单点风险，那么你用两个内存数据库？实际就是分布式缓存,两者区别是缓存中的内存，内存数据库放的还是数据；而分布式缓存放的是对象，对象不只是数据，是聚合体，是一个对象群，并时刻能在多台服务器内存中维持自身的统一性，就像你们兄弟俩一起闯江湖，不论到哪块服务器内存中，你们兄弟俩都会彼此照顾。数据就不会彼此照顾，都是死的东西。

内存数据库一般运行在和应用同样的进程空间，用来保存应用运行的数据。
内存数据库有现成产品，好像有一个叫hssqldb，java写的。
内存数据库不是用来永久保存数据的，只用来临时保存运行所需的数据。相对于数组等传统方式，好处是可以利用SQL的特性，简化程序设计，并且可以相对容易的和访问普通数据库的模块重用代码。

按 userjava的说法，内存数据库，跟缓存唯一区别就是可以利用SQL特性，简化程序设计对吗？ 可以理解为可以特殊的缓存，对吧。

我主要还想知道，什么时候需要考虑用内存数据库。

>>> 相对于数组等传统方式，好处是可以利用SQL的特性，简化程序设计
C/S方式访问数据库，才需要SQL。既然已经放到内存里来了，还需要啥子SQL哟。这不是脱裤子放屁嘛？还不仅仅是多此一举，应该是自找麻烦。

移动已经在使用内存数据库了，难道它在自找麻烦？？
内存数据库拥有一切数据库系统拥有的特性，比如用户授权访问、数据独立、易共享，可扩充等特点。而且对于用户屏蔽了存储方式。

>>> 相对于数组等传统方式，好处是可以利用SQL的特性，简化程序设计
我疑问的是上面这条。楼上的该先看清了，再回。

移动和PC有大区别。当不需要大存储量时，选用电子盘或自供电静态RAM，就轻而易举地解决持久性问题。
要解决的是持久性，而不是SQL。

usejava说的不对，内存数据库并不是仅仅为了保存一个临时数据而准备的，他在使用上就像正常的数据库一样，从使用者的角度上如果不告诉你使用的是什么数据库，两者给你的感觉是一样的。内存数据库本身也包括了备份、故障转移等功能，这些问题跟正常数据库一般无二。

我有一个高档导航仪，它里面的RAM就是静态的，且永久供电。在这样的机器里，为啥还要用“内存数据库”？没它，喜欢纯OO的朋友不是正好可以实现自己的理想了吗？来个DB，不是又要数据VS对象了吗？
[该贴被beepbug于2009-05-01 12:50修改过]

1.什么时候我们的系统需要内存数据库支持。
>>> 应用系统不止一种语言访问共享数据时（c/c++和java）

2.如果我们项目需要内存数据库支持，我们需要自己设计内存数据库吗？还是有第三方开发的内存数据库，有哪些可用的内存数据库产品可用，最好是开源的。
>>> 不需要自己设计内存数据库，市面上有很多成熟产品如：solidDB、altibase(韩国的 据说中国电信等大企业在用)
，开源的好像也有

3.开发内存数据库难度大吗，如何开发，需要什么技术。大体步骤是什么？
>>> “开发内存数据库难度大吗”你是想自己开发数据库系统吗？如果是想开发内存数据库 应该有些难度（据说华为用的就是自己开发的内存数据库）

4.既然是内存数据库。那么数据都放在内存。。要是断电数据不丢了吗。如何保证数据不意外丢失。
>>> 只要你成功的将数据写进了内存库中 那么它会保证下次启动内存数据库时数据的存在

5.既然是数据库，那么如果如果无限存储的话，那对内存也就需要无限支持。是不是用内存数据库的系统一般数据量都有限呢
>>> 这个没去研究过、只是在现实应用中 我们在设计内存数据库中的表时都特别注意避免大数据量 （没谁会给自己找麻烦）

个人认为这东西要不是绝对需要要的话 使用他只会给自己带来麻烦 最大问题是 往往内存数据库的数据会定时同步到传统的oracle中做持久保存

起初想把jivejdon 部分数据实现为内存数据库中 但没时间 哈哈 再说了 内存数据库也不是绝对能带来多大好处 这都要经过实际测试才知道

>>>3.开发内存数据库难度大吗，如何开发，需要什么技术。大体步骤是什么？
如果像上面一位说的，可以用SQL访问，那就简单罗。如果你有常规硬盘数据库的源码，那就简单了，因为你只需要修改DBMS的最底层代码，把本来访问硬盘指定扇区的代码，修改为访问指定内存空间就行了。
>>>5.既然是数据库，那么如果如果无限存储的话，那对内存也就需要无限支持。是不是用内存数据库的系统一般数据量都有限呢。
无限是不可能的，硬盘数据库也是有限的。内存数据库更是有限，如果计算一下，是有限得可怜。在UNIX机上，一个进程占4GB虚存，其中1GB是系统空间，用户空间只有3GB。放库数据的必须是共享空间，在DBMS进程里占一块，在应用程序进程里也占同样的一块。一共也只有3GB，你划分吧。

我来回答楼上的几个问题
》》如果像上面一位说的，可以用SQL访问，那就简单罗。如果你有常规硬盘数据库的源码，那就简单了，因为你只需要修改DBMS的最底层代码，把本来访问硬盘指定扇区的代码，修改为访问指定内存空间就行了。
首先楼上说的开发估计是应用使用内存数据库的开发难度，使用的门槛很低，而开发的门槛却不是那么低的，两者的开发完全不同，首先寻址方式就不同，第二个空间分配不同，第三数据整理方式不同，过去传统数据库需要讲磁盘数据读入内存，现在这一步省略了，也就是过去传统数据库最大的使用时间IO时间为0，这样起到了提升速度的作用。

至于说4G内存的问题，楼上不觉得眼熟么？？4G＝2^32看到这个你就知道了这个只是32位系统的一个内存访问的问题，不过这个问题不成为问题，你UNIX下的oracle数据库难道只能使用4G的内存么？？呵呵。

1）对，是不简单。至少让我搞，我不行。但是，我说的是相对的。如果甲按MySQL的功能但不抄它的源码做一个内存DBMS，而乙把MySQL源码拿来改写一下最底层，那甲与乙的工作量应该是100:1或更低。而比较技术难度，更悬殊得多。
如果甲自行做一个极简单的内存DBMS，那工作量仍然比乙大得多，技术复杂度也仍然比乙高得多。
DBMS的最底层，就是与硬盘接口的部分，对于熟悉底层的来说，不算难事。你可以在底层加一“插片”（一小段代码），把原本映射到硬盘扇区“重定向”到内存某一块。
2）UNIX上的Oracle DBMS同时运行若干个进程，每个进程所占的虚存都是4GB（包括内核态空间）。它只需放缓存数据。

1、如果是一个重头做，一个在别人基础上修改（确实了解源代码的情况下），当然是修改的要比重头来来的快，比如Oracle。当然修改起来并不是只是访问内存的跟硬盘的区别，两者在空间申请，数据管理上还有有很大不同的。
2、我只是想说明可以通过一些变通的方式获取更多的内存，但是需要牺牲的是效率，不过现在可以使用64位的操作系统，2^64这个数字估计购使用一段时间了。