具有低内存要求和 Ruby 界面的数据库
我需要一个内存要求低的数据库，用于内存很少的小型虚拟服务器。目前我只能使用 SQLite 和京都内阁或东京内阁。数据库应该有 Ruby 界面。
理想情况下，我想避免键值存储，因为我有“复杂”查询（比查找单个键更复杂）和元组作为键。另一方面，我不想拥有固定的模式并避免 SQL 数据库的规划和迁移工作。数据库服务器也不是必需的，因为只有一个应用程序将使用数据库。
你有什么建议和号码给我吗？
I need a database with low memory requirements for a small virtual server with few memory. At the moment I'm stuck with SQLite and Kyoto Cabinet or Tokyo Cabinet. The database should have a Ruby interface.
Ideally I want to avoid key-value-stores, because I have “complex” queries (more complex than looking up a single key) and tuples as keys. On the other hand I don't want to have a fixed schema and avoid the planning and migration efforts of a SQL database. A database server is also not necessary because only a single application will use the database.
Do you have any recommendations and numbers for me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有 无架构 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，但错误/问题较少。）：
缺点：
如果磁盘便宜而内存昂贵，那么它将是满足您需求的良好选择。
“...CouchDB 的另一个优势，它已被证明可以服务数千个并发请求，只需要大约 10MB 的 RAM - 这有多棒？！？！” （来自：http://www.larsgeorge.com/ 2009/03/hbase-vs-couchdb-in-berlin.html )
There is schema-less Postgresql (Postgresql 9.2 + json). Not as hard/confusing to set up as I thought. You get lots of flexibility with queries while still getting the benefits of schema-less storage. PG 9.2 includes plv8js, a new language handler that allows you to create functions in JavaScript. Here is one example of how you can index and query JSON docs in PG 9.2: http://people.planetpostgresql.org/andrew/index.php?/archives/249-Using-PLV8-to-index-JSON.html
CouchDB (Use BigCouch. Based on CouchDB, but fewer bugs/problems.):
Downsides:
If disk is cheap and memory expensive, it would make a good candidate for your needs.
"...another strength of CouchDB, which has proven to serve thousands of concurrent requests only needed about 10MB of RAM - how awesome is that?!?!" (From: http://www.larsgeorge.com/2009/03/hbase-vs-couchdb-in-berlin.html )
SQLite3 非常适合您想要做的事情。它被许多公司用作嵌入式应用程序数据库，因为它灵活、快速且经过充分测试，并且占地面积小。创建和清除表很容易，因此它可以很好地用于测试或单一应用程序使用的数据存储。
它使用的 SQL 语言足够丰富，可以完成正常的事情，但我建议使用 Sequel 。它是一个很棒的 ORM，可以轻松地让您将其视为成熟的 ORM，或者直接将原始 SQL 与 DBM 进行对话。
SQLite3 is a great fit for what you are trying to do. It's used by a lot of companies as their embedded app database because it's flexible, fast, well tested, and has a small footprint. It's easy to create and blow away tables so it plays well with testing or single-application-use data stores.
The SQL language it uses is rich enough to do normal things but I'd recommend using Sequel with it. It's a great ORM and easily lets you treat it as a full-blown ORM, or drop all the way down to talking raw SQL to the DBM.
您可能正在寻找一种只有数据库文件而没有正在运行的服务器的解决方案。在这种情况下，Sqlite 应该是一个不错的选择——如果你不需要它，只需关闭连接即可。 Sqlite 拥有您需要的 RDMS 的一切（期望直接执行 FK，但这可以通过触发器来完成），并且内存占用非常小，因此在这种情况下，您可能更担心 ORM 的内存（如果有）用途。
就我个人而言，我也将 sqlite 用于该用例，因为它是可移植的并且易于访问和安装（无论如何这不应该是服务器上的问题，但在桌面应用程序中却是）。
You are looking for a solution that only has a database file and no running server, probably. In that case, Sqlite should be a good choice - If you don't need it, just close the connection and that's it. Sqlite has everything that you need from and RDMS (expect for enforcing FK's directly, but that can be done with triggers), with a very little memory footprint, so in that case you are probably worried more about the memory your ORM (if any) uses.
Personally, I use sqlite for that use case as well, as it is portable and easy to access and install (which shouldn't be the problem on a server anyway, but in a desktop application it is).
BerkeleyDB 和 SQLite API 正是您所需要的。
http://www.oracle.com/technetwork/database/berkeleydb /概述/sql-160887.html
BerkeleyDB with SQLite API is what you need.
http://www.oracle.com/technetwork/database/berkeleydb/overview/sql-160887.html