主内存DB与对象DB

Question

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

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

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

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. 易于编程 （阻抗不匹配）

但是，就性能而言，

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

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

3. 将通过多个线程持续搜索和更新数据库。

据我所知，我在这里列出的所有对象数据库都使用缓存来存储数据库对象。 ExtremeDB声称，因为它专为内存而设计，它可以避免缓存逻辑等的开销。通过googling查看更多内容：主内存与RAM-Disk数据库：基于Linux的基准

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

Answer 1

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

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

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

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

将日志正确合并到主存储中后，日志将被丢弃（或重复使用）。

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

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

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

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

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

Answer 2

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