3

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

我只是从那里的数据库开发人员那里寻求一些个人意见。

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

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

或者

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

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

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

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

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

不过，就性能而言，

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

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

  3. 数据库将始终通过多个线程进行搜索和更新。

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

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

4

2 回答 2

5

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

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

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

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

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

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

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

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

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

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

于 2009-05-18T18:46:04.187 回答
1

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

于 2009-11-06T10:34:09.530 回答