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

datamann

关于TPC-H的问题，我已经核实了，情况如下:
TPC测试是参考测试，不是强制性标准。可以符合，也可以不符合。在历史上，曾经有过一个好笑的事，就是有些数据库不是去优化其数据库性能，而是优化该数据库对TPC测试的分值，就出了“高分低能”的事了。
要强制符合的事类似于SQL标准、ACID事务属性等标准。

nocode

这个吵架贴有点意思了。作为你们所谓的局方我想说几句。
首先说我不了解eXtremeDB，你说的4.1TB内存是在全局共享内存的情况下达到的吧？用了几台机器呢？我个人的了解SGI系统本身在计算方面是有很大优势的，集群交互也非传统设备可比。如果你的数据是从这个上面得到的，那么那些几百万分之一微秒的数据对普通用户根本没有意义的。最好能有个通用点的设备上的测试结果。另外，1个1T数据量的数据库要重启一次需要多久，这个能不能回答一下，我很想知道。
再说说altibase和timesten，经过我们的测试，在同样的环境里两个数据库其实速度差不多，不过timesten在设置为应用直链的情况下很快，比altibase快很多。但timesten在某些极端条件下速度异常的慢（比如一张很大数据量的全表更新），这个oracle也不知道为什么，已经从我们这里抓走数据作分析去了，怀疑是bug所致。
其实作为电信系统来讲对于实时性的要求比较高，但并不需要真的做到所谓的微秒级。我可以肯定对于高速并发事务来说，不管用那种内存数据库都能满足我们的要求。但更多的时候我们要考虑的是这种数据库对于我们应用的适用性到底如何，还要考虑投资问题。就算是电信也不能不计成本的。那种政府科研部门花的是国家的钱，我们可不行，呵呵。

lmx66768

楼上的我觉得你对产品的分析很清晰、清楚。

-----------------------------------------------
“不过timesten在设置为应用直链的情况下很快，比altibase快很多”

首先 我站在Altibase的角度分析。
我觉得这个直链模式也是Timesten 的一个优点，我想还是有应用点的。
但是我想强调一下timesten 这种模式下，不能确保宕机或宕库情况下，日志不丢失，即不能确保数据完整性。

另外是个人意测
我们几乎没有看到Timesten 的大数据量案例，并且在集成商听说大并发时出现过问题。
个人觉得这种直链模式会不会有大数据量、大并发下的隐患？！
//如果有timesten 的兄弟，希望多交流一下。单方面的意测不能认定什么，希望通过交流提高大家对内存数据库的认识。

datamann

"首先说我不了解eXtremeDB，你说的4.1TB内存是在全局共享内存的情况下达到的吧？用了几台机器呢？"
SGI Altix 4700服务器的硬件配置非常强悍，他的用户也非同一般。在用户最终确定使用eXtremeDB＋Altix4700方案之前，委托位于路易斯安娜大学的Louisiana Immersive Technologies Enterprise（LITE）对eXtremeDB的极限性能做过测试。LITE是专门做技术边界研究的机构。LITE的测试和最终用户的数据库尺寸稍有差别（1.17T）。这个测试报告后来公布了，过几天我摘要把这个报告翻译一下，在这里贴出，请您到时候光临看一下我的帖子。
SGI Altix 4700硬件到底强悍到什么程度？请看：
CPU类型：安腾2， 1.6GHz
CPU数量：80 『抱歉，我不清楚80个CPU算一台机器的SMP系统还是多台机器的集群系统，我再落实』
物理内存：4.1TB『最大24TB』
操作系统：64位SUSE Linux Enterprise Server 9

“如果你的数据是从这个上面得到的，那么那些几百万分之一微秒的数据对普通用户根本没有意义的。最好能有个通用点的设备上的测试结果。”
eXtremeDB在普通PC上也能达到微秒一级，我们正在Intel E2160 CPU ＋openSUSE 10上做测试，过几天我把测试结果摘要在这个论坛上也公布一下。E2160是目前Intel比较低端的处理器。主板是华硕的P5K SE，板载8GB DDR2－800内存。
eXtremeDB与altibase的对比测试，我没有。以后可以考虑做一个。不过，eXtremeDB在各种情况下，数据库一经给定，其操作速度相差基本没有差别。我们在VxWorks 5.5.1/Duron 2200上做过一个测试，从1条到100万条，性能波动在20％以内。『这种确定性，我们称之为“实时性”，而“微秒”是快速的意思。我的这个看法来自于实时UNIX。』我很惊诧的是，altibase在1000条操作的时候，速度上下相差38倍。这是一个大问题啊。
“1个1T数据量的数据库要重启一次需要多久，这个能不能回答一下，我很想知道。"
初始填充的时候，eXtremeDB花了33个小时；eXtremeDB有一个函数，mco_db_save()，把整个数据库备份下来，花了4.3小时；恢复这个备份的时候，花了4.7个小时。

“其实作为电信系统来讲对于实时性的要求比较高，但并不需要真的做到所谓的微秒级。我可以肯定对于高速并发事务来说，不管用那种内存数据库都能满足我们的要求。但更多的时候我们要考虑的是这种数据库对于我们应用的适用性到底如何，还要考虑投资问题。”
理解。
微秒级实时性的含义其实是多重的：在富资源系统上实现极速性能；在同等性能的情况下，降低硬件需求并简化系统架构；在资源紧凑系统上减低硬件成本。
还有一个奢求：是否能够请您把当时测试的题目给我？我用eXtremeDB试试，到时候把结果Email给您。

lmx66768

dataman

“我很惊诧的是，altibase在1000条操作的时候，速度上下相差38倍。这是一个大问题啊。”


这是那儿来的？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
我给你的b/s结构贴里是贴了一些数据。但是那个测试主要瓶颈在网络，那是socket 网络，webserver的性能。临时在比忙得网络做的。
当时我只想告诉你，你们的b\s结构性能并不比别人的快！！！别以为只有自己的是微妙级的！

------------------------------------------------------------------------
楼上有个兄弟说我们是吵架贴！！ 我很郁闷！！！
我没用过extremDB 不好说什么，请您也在不了解的情况下，谨言慎行！！

[ 本帖最后由 lmx66768 于 2008-1-15 09:37 编辑 ]

datamann

请您简化一下测试方法，如果有本地编程模式的话，请您用本地编程模式；如果只有C/S模式的话，请您把C/S放到同一个机器上。这样，网络的影响就可以消除了。在这种情况下，1000次事务性能晃动性情况如何？
本地编程：eXtremeDB的“嵌入式”模式、TimesTen的“直链”模式。altibase是否支持？

lmx66768

altibase 1 支持嵌入式的模式，
现在只支持本地 ipc 连接的模式。虽然比不上timesten 直链快，但是我也说过我们安全性肯定比它好。稳定性，并发性上应该也比它好。

lmx66768

你说的嵌入式，是不是一个应用程序一个数据库？？

datamann

多进程或多线程共享一个内存库。多进程的时候，内存库在共享内存里面。数据库内核以.a或.so或.lib的形式链接的时候包含到可执行文件里面。
这种模式是最稳定的。比如，IPC有个问题，就是IPC导致的进程间通信晃动性。在AIX上可能不一定感觉出来，在实时UNIX上就能感觉出来了。

lmx66768

多进程或多线程应该还是在一个程序里吧！这样的结构灵活性与其他数据库差距还是比较大的。
据我所知timesten 强悍的地方就是解决了这个问题，程序通过算法直接访问内存库的数据。//但是我个人怀疑发它的大并，大数据量的稳定性。
altibase 在早期也和extreme 嵌入式采用同样的结构，但是后来直链方式采用了IPC 。
我经常采用IPC测试，我经常在aix ，hp-unix ，sun ，linux 下测试，您说的晃动性我还真没感觉出来。

//根据市场的需要，和自身发展的需求，每个内存数据库厂商的发展方向都有一定的差异。相应的就会有更适合的应用环境。
    我的意思是确实有适合使用嵌入式数据库的系统，据我所知 solid 在这方面作的也比较多。