具有低内存要求和 Ruby 接口的数据库答案

【问题标题】：Database with low memory requirements and Ruby interface具有低内存要求和 Ruby 接口的数据库
【发布时间】：2011-01-06 21:20:29
【问题描述】：

我需要一个内存要求低的数据库，用于内存很少的小型虚拟服务器。目前我被 SQLite 和京都内阁或东京内阁困住了。数据库应该有一个 Ruby 接口。

理想情况下，我想避免键值存储，因为我有“复杂”的查询（比查找单个键更复杂）和元组作为键。另一方面，我不希望有一个固定的模式并避免 SQL 数据库的规划和迁移工作。数据库服务器也不是必需的，因为只有一个应用程序会使用数据库。

你有什么建议和号码给我吗？

【问题讨论】：

你可以让服务器消耗多少内存？
我会说少于 10 MiB。但如果数据库有令人信服的特性，我可以升级服务器。

标签： ruby database nosql memory-management key-value-store

【解决方案1】：

有schema-less Postgresql (Postgresql 9.2 + json)。设置起来不像我想象的那么难/令人困惑。您在查询方面获得了很大的灵活性，同时仍然获得了无模式存储的好处。 PG 9.2 包含 plv8js，这是一种新的语言处理程序，允许您在 JavaScript 中创建函数。以下是如何在 PG 9.2 中索引和查询 JSON 文档的一个示例：http://people.planetpostgresql.org/andrew/index.php?/archives/249-Using-PLV8-to-index-JSON.html
CouchDB（使用 BigCouch。基于 CouchDB，但错误/问题更少。）：
- 非常低的内存要求。
- 无模式。
- 基于 HTTP 的接口。 Ruby 有大量的 HTTP 客户端。 HTTP 缓存（如 Varnish）也可以加快读取速度。
- 创意/复杂查询。您可以在文档（记录）中的任何键上创建索引和查询。由于索引非常可编程，因此您可以在查询方面发挥很大的创意。
缺点：
- 设置查询/索引的学习曲线。
- 您必须安排一种称为“压缩”的清理操作。
- 与其他数据库相比，数据将占用更多空间。
- 更多：http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html
如果磁盘便宜而内存昂贵，那么它将是满足您需求的理想选择。

“...CouchDB 的另一个优势，它已被证明可以为数千个并发请求提供服务，只需要大约 10MB 的 RAM - 这真是太棒了？！？！” （来自：http://www.larsgeorge.com/2009/03/hbase-vs-couchdb-in-berlin.html）

【讨论】：

【解决方案2】：

SQLite3 非常适合您尝试做的事情。很多companies 都将它用作他们的嵌入式应用程序数据库，因为它灵活、快速、经过良好测试并且占用空间小。创建和删除表很容易，因此它可以很好地用于测试或单一应用程序使用的数据存储。

它使用的 SQL 语言足够丰富，可以做正常的事情，但我建议使用 Sequel 和它。这是一个很棒的 ORM，您可以轻松地将其视为成熟的 ORM，或者直接将原始 SQL 与 DBM 对话。

【讨论】：

SQLite 有点受限 (sqlite.org/omitted.html)。我真的很想能够写意见。此外，对我来说，缺少 DROP COLUMN 支持似乎对迁移有问题（您可以通过创建临时表、复制除要删除的列之外的数据、删除原始表并从临时表重新创建来进行迁移，但这确实是丑）。

【解决方案3】：

您可能正在寻找一种只有数据库文件而没有正在运行的服务器的解决方案。在这种情况下，Sqlite 应该是一个不错的选择——如果你不需要它，只需关闭连接即可。 Sqlite 拥有你需要的一切和 RDMS（期望直接执行 FK，但这可以通过触发器来完成），内存占用非常少，所以在这种情况下，你可能更担心你的 ORM 的内存（如果有的话）用途。

就我个人而言，我也将 sqlite 用于该用例，因为它可移植且易于访问和安装（这在服务器上应该不是问题，但在桌面应用程序中却是）。

【讨论】：

但是使用 SQL 时，您会遇到模式和规划（绘制数据模型图，将它们转换为正常形式等）开销以及模式迁移问题。如果我找不到其他解决方案，SQLite 将是我的选择，因为我知道它会起作用。自从我使用 ORM（最后是 ActiveRecord）以来已经有一段时间了。我的印象是他们只提供他们抽象的数据库的最低公分母并生成次优查询。但由于 SQLite 只实现了 SQL 92，所以它不应该是一个巨大的限制。
@ott “模式和规划问题（绘制数据模型图，将它们转换为标准形式等）开销，可能还有模式迁移问题”为什么？如果你想这样做可能会很复杂，或者你可以为 ActiveRecord 或 Sequel 编写一些迁移，然后让他们完成繁重的工作。将数据库适配器更改为 MySQL、Postgres 或其他东西，ORM 仍将处理所有模式的创建和操作。
@ott 就 SQL 查询质量而言，我已经多次查看 ActiveRecord 和 Sequel 的输出，它们生成的查询是我大部分时间都会编写的。你会惊讶于他们有多聪明。而且，如果您发现他们走错了路，您可以轻松地替换您自己手动调整的 SQL，他们会很乐意使用它。他们肯定胜过使用 DBI 和手写所有内容。
@the Tin Man：续集看起来很有希望，因为您拥有更大的控制权，并且如果您愿意，实际的 SQL 数据库也不会被抽象。如果我要使用 SQL 数据库，我可能会尝试 Sequel。

【解决方案4】：

您需要的是带有 SQLite API 的 BerkeleyDB。 http://www.oracle.com/technetwork/database/berkeleydb/overview/sql-160887.html

【讨论】：

Berkeley DB在实践中相对于SQLite的默认存储引擎有哪些优势？
@ott SQLite 的默认存储引擎使用数据库级锁定，这意味着一次只有一个写入者可以访问数据库。 BerkeleyDB 使用页面级锁定和 MVCC，因此它允许多个并发写入者。如果您的应用程序是并发写入密集型的，您应该使用 BerkeleyDB 存储引擎。如果您的应用程序不经常修改数据，SQLite 的默认存储引擎和 BerkeleyDB 执行相同。