主内存DB与对象DB

时间:2009-05-18 18:22:18

标签: rdbms in-memory-database object-oriented-database

我目前正在尝试选择数据库供应商。

我只是在寻找其他数据库开发人员的个人意见。

我的问题特别针对以下人士:

1)之前使用了支持复制到磁盘(混合)的主内存数据库(MMDB)(即ExtremeDB

2)使用了Versant Object Database和/或Objectivity Database和/或Progress ObjectStore

问题是:如果您可以根据您的经验推荐数据库供应商,那将适合我的应用程序。

我的应用程序是一个商业实时(读取:高性能)面向对象的C ++ GIS类应用程序,我们需要进行大量的lat / lon搜索(即给定一个区域,找到所有匹配的目标)该地区...... R-Tree指数)。

我想要存储到数据库中的数据类型都被建模为对象,它们使用std :: list和std :: vector,所以自然,Object Database似乎有意义。我已经阅读了足够的文章来说服自己,传统的RDBMS可能不是我真正想要的

  1. 表现(加入或多个 动态长度数据的表格 列表/载体)
  2. 易于编程 (阻抗不匹配)
  3. 但是,就性能而言,

    1. 输入数据以约40 MB / s的速度输入系统。

    2. 因此,系统也将以每秒大约350次插入的速率插入数据库(每个对象从64KB到128KB),

    3. 将通过多个线程持续搜索和更新数据库。
    4. 据我所知,我在这里列出的所有对象数据库都使用缓存来存储数据库对象。 ExtremeDB声称,因为它专为内存而设计,它可以避免缓存逻辑等的开销。通过googling查看更多内容:主内存与RAM-Disk数据库:基于Linux的基准

      所以..我只是有点困惑。可以在实时系统中使用对象DB吗?它是否像MMDB一样“快”?

2 个答案:

答案 0 :(得分:5)

从根本上说,MMDB和OODB之间的区别在于,MMDB期望其所有数据都基于RAM,但在某些时候仍然存在于磁盘中。而OODB更为传统,因为没有期望整个DB适合RAM。

MMDB可以通过放弃持久化数据不一定要“匹配”RAM数据的概念来利用这一点。

任何具有持久性的方法都会起作用,它必须以某种方式在更新时将数据写入磁盘。

几乎所有数据库都使用某种日志。这些日志基本上是附加到文件的“原始”数据页,或者可能是单个事务。当文件“太大”时,将启动一个新文件。

将日志正确合并到主存储中后,日志将被丢弃(或重复使用)。

现在,简单地通过将事务附加到日志文件就可以存在RAM DB中的原始数据,并且当它重新启动时,它只是将登录加载到RAM中。因此,实质上,日志文件是数据库。

这种技术的缺点是你拥有的事务越多越多,日志/数据库越大,因此数据库启动时间越长。但是,理想情况下,您还可以“快照”当前状态,从而消除所有日志,并有效地压缩它们。

通过这种方式,DB必须管理的所有例行操作都是将页面附加到日志,而不是更新其他磁盘页面,索引页面等。理想情况下,大多数系统不需要“启动”通常,也许启动时间不是问题。

因此,通过这种方式,MMDB可以比具有与磁盘不同的合同的OODB更快,从而维护日志和磁盘页面。这样,即使整个数据库适合RAM并且正确缓存,OODB也可能更慢,原因很简单,因为您在正常操作期间在日志操作之外引发磁盘操作,而MMDB则将这些操作作为“维护”发生任务,可以在停机时间和/或安静时间安排。

至于这些系统中的任何一个是否能满足您的实际性能需求,我不能说。

答案 1 :(得分:1)

数据库的后端(读写器进程,缓存,锁管理,txn日志文件,ACID语义)是相同的,因此RDB和OODB在这里实际上非常相似。区别在于应用程序员的接口。您的数据模型是否复杂,包含许多具有实际继承关系的类? OO很好。它相对扁平而简单吗?然后去RDB。这种关系的本质是什么?它是指针式的吗?然后去RDB。是更复杂,像(有序)列表,数组,地图?然后你应该去OO。此外,您是否有一个独立的应用程序,而无需与其他应用程序集成?然后OO没问题。您是否必须与其他应用共享数据(即多个应用访问同一个数据库)?那么这对OO来说是一个交易破坏者,你应该坚持使用RDB。数据库的架构是稳定的还是您希望它经常发展? OODB是糟糕的广告架构演变,因此如果您希望频繁更改,请坚持使用RDB。