主存数据库与对象数据库
我目前正在尝试选择一个数据库供应商。
我只是向其他数据库开发人员寻求一些个人意见。
我的问题特别针对以下人群：
1）之前使用过支持复制到磁盘（混合）的主内存数据库（MMDB）（即 ExtremeDB)
或
2) 已使用Versant 对象数据库 和/或 客观性数据库</a> 和/或 Progress ObjectStore
问题是：如果您可以根据您的经验推荐一个数据库供应商，那么适合我的应用。
我的应用程序是一个商业实时（读取：高性能）面向对象的 C++ GIS 类型的应用程序，我们需要进行大量的纬度/经度搜索（即给定一个区域，找到该区域内的所有匹配目标。 ..R树索引）。
我想要存储到数据库中的数据类型都被建模为对象，并且它们使用 std::list 和 std::vector，所以自然地，对象数据库似乎是有意义的。 我已经阅读了足够多的文章来说服自己，传统的 RDBMS 可能不是我真正想要的
- 性能（连接或多个） 动态长度数据的表，例如 列表/向量）
- 易于编程 （阻抗不匹配）
但是，就性能而言，
输入数据以大约 40 MB/s 的速度输入系统。
因此，系统还将以每秒大约 350 次插入的速度向数据库中插入数据（每个对象的大小从 64KB 到 128KB 不等），
- 数据库将通过多个线程一致地搜索和更新。
根据我的理解，我在这里列出的所有对象数据库都使用缓存来存储数据库对象。 ExtremeDB声称，由于它是专门为内存设计的，因此它可以避免缓存逻辑等的开销。通过谷歌搜索查看更多信息：主内存与RAM磁盘数据库：基于Linux的基准
所以..我有点困惑。 对象数据库可以在实时系统中使用吗？ 它和MMDB一样“快”吗？
I'm currently trying to pick a database vendor.
I'm just seeking some personal opinions from fellow database developers out there.
My question is especially targeted towards people who:
1) have used Main Memory DB (MMDB) that supports replicating to disk (hybrid) before (i.e. ExtremeDB)
or
2) have used Versant Object Database and/or Objectivity Database and/or Progress ObjectStore
and the question is really: if you could recommend a database vendor, based on your experience, that would suit my application.
My application is a commercial real-time (read: high-performance) object-oriented C++ GIS kind of app, where we need to do a lot of lat/lon search (i.e. given an area, find all matching targets within the area...R-Tree index).
The types of data that I would like to store into the database are all modeled as objects and they make use of std::list and std::vector, so naturally, Object Database seems to make sense. I have read through enough articles to convince myself that a traditional RDBMS probably isnt what I'm really looking for in terms of
- performance (joins or multiple
tables for dynamic-length data like
list/vector) - ease of programming
(impedance mismatch)
However, in terms of performance,
Input data is being fed into the system at about 40 MB/s.
Hence, the system will also be doing insert into the database at the rate of roughly 350 inserts per second (where each object varies from 64KB to 128KB),
- Database will consistently be searched and updated via multiple threads.
From my understanding, all of the Object DBs I have listed here use cache for storing database objects. ExtremeDB claims that since it's designed especially for memory, it can avoid overhead of caching logic, etc. See more by googling: Main Memory vs. RAM-Disk Databases: A Linux-based Benchmark
So..I'm just a bit confused. Can Object DBs be used in real-time system? Is it as "fast" as MMDB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从根本上来说，MMDB 和 OODB 之间的区别在于 MMDB 期望其所有数据都基于 RAM，但在某个时刻保留到磁盘。 而 OODB 更为传统，因为不需要将整个 DB 装入 RAM。
MMDB 可以通过放弃持久数据不一定必须与 RAM 数据“匹配”的概念来利用这一点。
任何具有持久性的工作方式都必须在更新时以某种方式将数据写入磁盘。
几乎所有数据库都为此使用某种日志。 这些日志基本上是附加到文件的“原始”数据页，或者可能是单个事务。 当文件变得“太大”时，将启动一个新文件。
一旦日志被正确合并到主存储中，日志就会被丢弃（或重新使用）。
现在，简单地通过将事务附加到日志文件就可以存在一个原始的 RAM 数据库，并且当它重新启动时，它只是将日志加载到 RAM 中。 所以，本质上，日志文件就是数据库。
这种技术的缺点是事务越长、越多，日志/数据库就越大，因此数据库启动时间就越长。 但是，理想情况下，您还可以“快照”当前状态，这会消除所有最新日志，并有效地压缩它们。
通过这种方式，数据库的所有日常操作必须管理的是将页面附加到日志，而不是更新其他磁盘页面、索引页面等。因为，理想情况下，大多数系统不需要经常“启动”，也许启动时间不是一个问题。
因此，通过这种方式，MMDB 可以比 OODB 更快，后者与磁盘有不同的契约，维护日志和磁盘页面。 这样，即使整个数据库适合 RAM 并正确缓存，OODB 也会变慢，这仅仅是因为在正常操作期间您在日志操作之外进行了磁盘操作，而 MMDB 则将这些操作作为“维护”进行任务，可以在停机时间和/或安静时间安排。
至于这两个系统是否能满足你实际的性能需求，我不好说。
Fundamentally, I difference between a MMDB and a OODB is that the MMDB has the expectation that all of its data is based in RAM, but persisted to disk at some point. Whereas an OODB is more conventional in that there's no expectation of the entire DB fitting in to RAM.
The MMDB can leverage this by giving up on the concept that the persisted data doesn't necessarily have to "match" the in RAM data.
The way anything with persistence is going to work, is that it has to write the data to disk on update in some fashion.
Almost all DBs use some kind of log for this. These logs are basically "raw" pages of data, or perhaps individual transactions, appended to a file. When the file gets "too big", a new file is started.
Once the logs are properly consolidated in to the main store, the logs are discarded (or reused).
Now, a crude, in RAM DB can exist simply by appending transactions to a log file, and when it's restarted, it just loads the log in to RAM. So, in essence, the log file IS the database.
The downside of this technique is the longer and more transactions you have, the bigger your log/DB is, and thus the longer the DB startup time. But, ideally, you can also "snapshot" the current state, which eliminates all of the logs up to date, and effectively compresses them.
In this manner, all the routine operations of the DB have to manage is appending pages to logs, rather than updating other disk pages, index pages, etc. Since, ideally, most systems don't need to "Start up" that often, perhaps start up time is less of an issue.
So, in this way, a MMDB can be faster than an OODB who has a different contract with the disk, maintaining logs and disk pages. In this way, an OODB can be slower even if the entire DB fits in to RAM and is properly cached, simply because you incur disk operations outside of the log operations during normal operations, vs a MMDB where these operations happen as a "maintenance" task, which can be scheduled during down time and/or quiet time.
As to whether either of these systems can meet you actual performance needs, I can't say.
数据库的后端（读取器和写入器进程、缓存、锁管理、txn 日志文件、ACID 语义）是相同的，因此 RDB 和 OODB 实际上非常相似。 区别在于应用程序员的接口。 您的数据模型是否复杂，由许多具有真正继承关系的类组成？ 那么OO就好了。 是不是比较扁平、简单？ 然后去RDB。 关系的本质是什么？ 是像指针一样设置吗？ 然后去RDB。 是否更复杂，例如（有序）列表、数组、映射？ 那你应该去OO。 另外，您是否有一个独立的应用程序，不需要与其他应用程序集成？ 那么OO就可以了。 您是否必须与其他应用程序共享数据（即多个应用程序访问同一数据库）？ 那么这对于 OO 来说是一个破坏性的因素，你应该坚持使用 RDB。 您的数据库架构是否稳定，或者您希望它经常发展吗？ OODB 是糟糕的广告模式演变，因此如果您预计会频繁更改，请坚持使用 RDB。
The back ends of databases (reader and writer processes, caching, lock managing, txn log files, ACID semantics) are the same, so RDBs and OODB are actually very similar here. The difference is the interface to the application programmer. Is your data model complicated, consists of lots of classes with real inheritance relationships? Then OO is good. Is it relatively flat and simple? Then go RDB. What is the nature of the relationships? Is it pointer-like and set like? Then go RDB. Is is more complicated, like (ordered) list, array, map? Then you should go OO. Also, do you have a stand-alone application with no need to integrate with other apps? Then OO is ok. Do you have to share data with other apps (i.e. several apps access the same database)? Then that's a deal-breaker for OO, and you should stick with RDB. Is the schema of your database stable or do you expect it to evolve frequently? OODBs are bad ad schema evolution, so if you expect frequent changes, stick with RDBs.