主内存数据库vs对象数据库

Question

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

我只是从其他数据库开发人员那里寻求个人意见。

我的问题是特别有针对性的对人谁：

1）主内存数据库（MMDB），支持复制到磁盘（混合）之前（即ExtremeDB）

或

2已经使用）已经使用Versant Object Database和/或Objectivity Database和/或Progress ObjectStore

问题是：如果你可以推荐一个数据库供应商，根据你的经验这将适合我的应用程序。

我的应用程序是一个商业实时（读取：高性能）面向对象的C++ GIS类应用程序，我们需要做很多纬度/经度搜索（即给定一个区域，找到所有匹配的目标在该区域内... R-Tree索引）。

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

1. 性能方面寻找（连接或多个 表动态长度的数据，如 列表/矢量）
2. 易于编程 （阻抗不匹配）

然而，在性能方面的，

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

2. 因此，该系统也将被以每秒大约350插入物的速率（其中，每个对象从64KB到128KB而异），做插入到数据库

3. 数据库将始终如一地被搜索和经由多个更新线程。

从我的理解中，我列出的所有Object DB都使用缓存来存储数据库对象。 eXtremeDB的声称，因为它是专门为内存，这样可避免缓存逻辑的开销等，通过谷歌搜索查看更多：主内存与RAM磁盘数据库：一个基于Linux的基准

So..I'm刚有点困惑。对象DB可以用于实时系统吗？它与MMDB一样“快”吗？

Answer 1

从根本上说，MMDB和OODB的区别在于MMDB有一个期望，即其所有数据都基于RAM，但在某个时刻仍然保留在磁盘上。而OODB更传统，因为没有期望整个DB适合RAM。

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

的方式与持久什么是去工作，是它写在以某种方式更新数据到磁盘。

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

一旦日志中到主存储适当合并，日志将被抛弃（或重复使用）。现在

，粗，在RAM DB可以通过附加事务日志文件只是存在，它的重新启动时，它只是加载在日志中RAM。所以，实质上，日志文件就是数据库。

这种技术的缺点是时间更长，更多的交易你有更大的日志/ DB是，这样长的DB的启动时间。但是，理想情况下，您还可以“快照”当前状态，从而消除所有日志，并有效压缩它们。

以这种方式，数据库必须管理的所有例行操作都是将页面附加到日志，而不是更新其他磁盘页面，索引页面等。因为理想情况下，大多数系统不需要“启动“通常，开始时间可能不是问题。

所以，在这种方式中，内存数据库可以比谁拥有与磁盘不同的合同，维护日志和磁盘页面的面向对象数据库更快。通过这种方式，一个面向对象数据库可以更慢，如果整个DB适应在RAM中，正确缓存，仅仅是因为你在正常操作期间招致磁盘操作日志操作之外，Vs的内存数据库，其中这些操作发生的“维护”任务，可以在停机时间和/或安静时间进行调度。

至于是否这两种系统都能满足你的实际性能需求，我不能说。

Answer 2

的后端的数据库（读写器进程，缓存，锁管理，TXN日志文件，ACID语义）是相同的，所以RDBS和面向对象数据库实际上是非常相似的在这里。区别在于应用程序员的接口。你的数据模型是否复杂，由许多具有真正继承关系的类组成？然后OO是好的。它是相对平坦和简单吗？然后去RDB。关系的性质是什么？它是否像指针一样设置？然后去RDB。是更复杂的，像（有序）列表，数组，地图？那么你应该去OO。另外，你有没有需要与其他应用程序集成的独立应用程序？然后OO就OK了。您是否必须与其他应用程序共享数据（即多个应用程序访问相同的数据库）？那么这对于面向对象来说是一个破坏行为，你应该坚持RDB。数据库的架构是否稳定或您期望其频繁发展？ OODB是糟糕的广告模式演变，所以如果您希望频繁更改，请坚持使用RDB。