主存数据库与对象数据库

Question

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

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

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

1）之前使用过支持复制到磁盘（混合）的主内存数据库（MMDB）（即 极速数据库)

或者

2）已经使用过 Versant 对象数据库 和/或 客观性数据库 和/或 进度对象存储

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

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

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

1. 性能（与列表/向量等动态长度数据相连或多个表格）
2. 易于编程（阻抗不匹配）

不过，就性能而言，

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

2. 因此，系统还将以每秒大约 350 次插入的速度向数据库中插入数据（每个对象的大小从 64KB 到 128KB 不等），

3. 数据库将通过多个线程一致地搜索和更新。

根据我的理解，我在这里列出的所有对象数据库都使用缓存来存储数据库对象。ExtremeDB声称，由于它是专门为内存设计的，因此可以避免缓存逻辑等开销。通过谷歌搜索查看更多：主内存对比RAM 磁盘数据库：基于 Linux 的基准测试

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

Answer 1

从根本上来说，MMDB 和 OODB 之间的区别在于 MMDB 期望其所有数据都基于 RAM，但在某个时刻保留到磁盘。而 OODB 更为传统，因为不需要将整个 DB 装入 RAM。

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

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

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

一旦日志被正确合并到主存储中，日志就会被丢弃（或重新使用）。

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

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

通过这种方式，数据库必须管理的所有日常操作都是将页面附加到日志，而不是更新其他磁盘页面、索引页面等。由于理想情况下，大多数系统不需要那么频繁地“启动”，因此启动时间也许不是什么问题。

因此，通过这种方式，MMDB 可以比 OODB 更快，后者与磁盘有不同的契约，维护日志和磁盘页面。通过这种方式，即使整个数据库适合 RAM 并正确缓存，OODB 也会变慢，这仅仅是因为在正常操作期间您在日志操作之外进行了磁盘操作，而 MMDB 则将这些操作作为“维护”进行任务，可以在停机时间和/或安静时间安排。

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

Answer 2

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