主存DB与对象DB

Question

我目前正试图挑选一个数据库供应商。

我只是在向其他数据库开发人员征求一些个人意见。

我的问题特别针对下列人士：

1)以前使用过支持磁盘复制(即ExtremeDB)的主存DB (MMDB)。

或

2)使用了Versant对象数据库和/或客观性数据库和/或进度ObjectStore

问题是:如果您能够根据您的经验推荐一个数据库供应商，这将适合我的应用程序。

我的应用程序是一个商业的实时(读:高性能)面向对象的C++地理信息系统应用程序，我们需要做大量的lat/lon搜索(即给定一个区域，查找该区域内所有匹配的目标.R-树索引)。

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

1. 性能(列表/向量等动态长度数据的联接或多个表)
2. 编程容易(阻抗失配)

然而，就性能而言，

1. 输入数据以大约40 MB/s的速度输入到系统中。
2. 因此，系统还将以每秒大约350次插入的速度对数据库进行插入(每个对象的插入速度从64 be到128 be)，
3. 数据库将始终通过多个线程进行搜索和更新。

据我了解，这里列出的所有对象DB都使用缓存来存储数据库对象。ExtremeDB声称，由于它是专门为内存设计的，它可以避免缓存逻辑等的开销。请参阅googling:主存与内存磁盘数据库:基于Linux的基准测试。

所以.我有点糊涂。对象数据库可以用于实时系统吗？它和MMDB一样快吗？

Answer 1

从根本上讲，MMDB和OODB之间的区别在于，MMDB期望其所有数据都基于RAM，但在某个时候会持久化到磁盘。而OODB则更为传统，因为它并不期望整个DB都能与RAM相匹配。

MMDB可以利用这一点，放弃持久化数据不必“匹配”内存数据的概念。

持久化的方法是，它必须以某种方式在更新时将数据写入磁盘。

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

一旦日志正确地整合到主存储中，日志就会被丢弃(或重用)。

现在，RAM DB中的粗数据可以简单地通过将事务附加到日志文件来存在，当它重新启动时，它只会将登录加载到RAM中。因此，从本质上讲，日志文件就是数据库。

这种技术的缺点是，您拥有的事务越长、越多，您的日志/ DB就越大，因此DB启动时间就越长。但是，理想情况下，您也可以“快照”当前状态，这消除了所有日志的最新，并有效地压缩他们。

以这种方式，DB必须管理的所有常规操作都是将页面附加到日志中，而不是更新其他磁盘页、索引页等。因为，理想情况下，大多数系统不需要“启动”--通常，启动时间较少。

因此，以这种方式，MMDB可以比与磁盘有不同契约、维护日志和磁盘页的OODB更快。这样，即使整个DB与RAM相适应并被正确缓存，OODB也可能更慢，这仅仅是因为您在正常操作期间在日志操作之外发生磁盘操作，而在MMDB中，这些操作发生在“维护”任务中，可以在停机时间和/或安静时间内调度。

至于这些系统是否能满足您实际的性能需求，我不能说。

Answer 2

数据库的后端(读取器和写入程序、缓存、锁管理、txn日志文件、ACID语义)是相同的，因此RDB和OODB实际上非常相似。不同之处在于与应用程序程序员的接口。您的数据模型是否复杂，由许多具有实际继承关系的类组成？那么OO就好了。是不是比较平和简单呢？那就去RDB。这种关系的性质是什么？它是指针式的还是设置型的？那就去RDB。是不是比较复杂，比如(有序)列表，数组，地图？那你就该走了。另外，您是否有一个独立的应用程序而不需要与其他应用程序集成？那么OO就可以了。您是否必须与其他应用程序共享数据(例如，多个应用程序访问同一个数据库)？对OO来说，这是一个交易的破坏者，你应该坚持RDB。您的数据库模式是稳定的，还是预期它会频繁发展？OODB是不好的广告模式演变，所以如果您期望频繁的更改，坚持使用RDB。