eXtremeDB的定位：极速实时数据管理系统

dryang10

呵呵 麻烦请教几个菜鸟问题：
1.如何将实时数据库写入磁盘中？

2.eXtremedb提供系统实时数据的安全机制有哪些？

Kenniu

恭喜！您刚拣到ITPUB送出的新年红包。28PUB币!

如果您的浏览器没有自动跳转，请点击这里

Kenniu

学习又能收到钱多好。。。

Kenniu

原帖由 datamann 于 2008-1-29 20:02 发表
eXtremeDB极速的根源在4个方面：
1.革命性的数据存储方式
2.革命性的访问方式
3.全面、灵活、开放的索引方式
4.革命性的接口方式

我想知道，怎么个革命法?

datamann

1.如何将实时数据库写入磁盘中？
2.eXtremedb提供系统实时数据的安全机制有哪些？
大量的快实时数据是不写入磁盘的，能够写入磁盘的在某种意义上说都是“非实时数据”了。比如预警指挥系统的目标定位信息，写入磁盘/掉电恢复的工作模式是不适用的。
但实时数据库并非只用于管理快实时数据，象电信计费、银行实时结算这种“软实时数据”用实时数据库管理也大有益处。软实时数据综合了快和安全两个部分的内容。eXtremeDB对这种类型的数据管理而言，性能是绰绰有余，用户关注的主要还是安全问题了。有这样几种解决方法：
－用mco_db_save()把整个数据库保存为影像文件到磁盘上，再用mco_db_load()从磁盘加载影响文件。
－通过eXtremeLog把关键事务记录到磁盘上，必要的时候可以恢复这些事务日志。这里的问题是内存数据库与磁盘打交道后，某种意义上就变成磁盘数据库了。情况是这样的：eXtremeLog是随时可以打开/关闭的，只日志关键性的事务，非关键性的事务（占大多数）不做日志，减少了磁盘访问的机会；eXtremeLog的日志过程是单一数据流写到磁盘而不是表格结构，可以发挥磁盘的峰值性能；eXtremeLog日志过程可以有多种工作模式，比如定时日志/定量日志等，能够系统谷底的时候日志，减少对系统性能的影响。
－eXtremeDB Fusion是一个混合数据库，就是介质可以是内存的，也可以是磁盘的。内存数据库部分保存快实时数据、磁盘数据库部分保存软实时数据。有一点要说明，eXtremeDB的磁盘数据库实际上是用户控制的一个虚拟内存。
－eXtremeHA，有2-safe和1+safe两种模式。这是比较常见的方法。
－再一个比较Cool的办法是NVRAM，这是针对板载数据库而言的。这里的NVRAM指的是普通RAM加上备份电源而不是SRAM或Flash。掉电后RAM中的数据由备份电源保持着，再定位到这个地方恢复出eXtremeDB数据库。
－前后台模式，这在计费里面比较常见了。内存数据库比磁盘数据库要快很多，但内存数据库又要与磁盘数据库进行前后台同步，性能上不匹配怎么解决？还是刚才的原因。内存数据库中的大量实时数据是没有必要同步到后台企业数据库里面的，比如内存数据库中可能不仅包含了谁什么时候给谁打了电话，还包含了拨号过程、Soft-PBX的交换矩阵...等等；同步到后台数据库的时候，只要谁给谁什么时候到什么时候打了电话，就可以了。这样，前后台的分工正好实现既快又安全的要求。

datamann

1.革命性的数据存储方式
内存非文件格式。这个过程是内存数据库技术含量最大的部分。
设想一下，在内存里建立隐含内存盘再把磁盘数据库搬到上面，是不是很容易？但这种方法的缺点也是很明显的：快的有限、数据存储占用更多的内存、文件IO导致的系统晃动及不稳定性等等...而这正是今天很多号称“内存数据库”的实现方法。
内存很快，给所有人的感觉都是内存很快。但这种感觉是从何而来的？是从我们往内存某个单元写数来的，比如做x=1可能只要几个机器周期。如果不是直接对x赋值，而是把x=1写到内存盘的某个文件上，比如x.dat上加一行x=1，这个速度快不快呢？还是快，但比直接赋值要慢的很多了。
x=1直接赋值的时候，在内存里面就是占用1个字节（最少情形）～8个字节（最多情形）；在x.dat文件里面加一行"x=1"情况如何呢？为什么磁盘数据库可以压缩？就是因为文件表格里面有很多空隙。
文件系统在计算机的各个部件中属于最不可靠的部分。您是否遇到过这种情形：磁盘还是好的，里面的文件却崩溃了？
所以说内存盘数据库的技术含量有限。

不走内存盘，那路就比较难了。不过结果证明也是值得的。这个方法就是内存管理的时候借鉴实时操作系统的内存管理技术，通过非文件化管理。这就是eXtremeDB的数据存储方法了。为什么说它是革命性的？可以用对比评测来感受。

2.革命性的访问方式
您看到很多“内存数据库”的访问模式和SQL Server没有区别，就是通过一个服务器程序访问数据源、用户程序通过进程间通信间接访问数据源。这个模式在实现上也很简单。
可是，它占用了太多的CPU资源；而且，进程间通信晃动性也太大了；在实时操作系统上，进程间通信还会造成优先级翻转。
因此，如果一种内存数据库是以管理强实时数据为目标的，进程间通信就是不可接受的。
不基于进程间通信怎么办？就是eXtremeDB的内核嵌入模式了。每个进程（就是每个程序 ）直接访问数据源。每个程序都直接访问数据源缩短了代码执行路径、使得系统确定性高了，是其优点；但N个进程同时访问数据源的时候，是不是有冲突？这就是eXtremeDB内核的功能之一了。
之中内核嵌入的访问方式是不是革命的？
当然，eXtremeDB也支持进程间通信（就是本地IPC模式）、远程访问（如eXtremeDB RPC Connector或eXtremeDB rSQL Connector了）这些“不革命”的模式了。

3.全面、灵活、开放的索引方式
我没有看到那种数据库能象eXtremeDB这样支持索引：
全面--不管是B-Tree、Hash、通常数据库采用的List索引，还是P-Tree、R-Tree、OID、AutoID...甚至用户自定义索引算法，eXtremeDB都可以支持
灵活--在eXtremeDB定义文件里标注出来，内核就自动帮您维护索引，比如
      uniq tree <字段1, 字段2...> tk12;
         内核就自动维护这个索引

4.革命性的接口方式
      eXtremeDB的接口API虽然非常直观，却是由用户数据库定义通过预编译器产生出来的。其它内存数据库不可避免地要进行动态内存分配和回收。在快实时数据管理的时候，这个过程产生内存碎片的速度可以很快，使得系统变慢甚至崩溃...通过这种定制的API，eXtremeDB不仅变快了，更重要的是它避免内存碎片的问题，系统变稳定了、强壮了。
      这是不是革命性的？

是啊，eXtremeDB与其它“内存数据库”相比，走了更多的弯路、吃了很多别人没有吃的苦。也正是如此，使得eXtremeDB更快、更小、更稳、更壮！
所以才说数据库技术要是有什么可以被称为“传奇”的话，一是E.F.Codd的SQL技术、而是eXtremeDB的内存数据库技术。

mygosh_love

这里很热闹呀=>extremedb  学习了 ………………

yaoyaoyao56

学习了

qiaqiafn

楼上的能否对extremedb HA多对多备份提些建议  ？
比如多对副、主备份等等 ?

datamann

eXtremeDB的备份以1对多为主。为什么需要多对多的备份？因为有多主站；为什么需要多主站？因为单一主站性能不足以满足需要。但实际上无论是多主站eXtremeDB还是多主站其它内存数据库，多主站性能很难超过eXtremeDB单主站性能。因此，在eXtremeDB系统，多主站的应用场景就比较少了。eXtremeDB也支持多主站HA，其场景是非性能原因导致对多主站的需求。eXtremeDB HA Appendum里面有关于多主站方案的描述，您不妨看看。