哪个能够存储 1 亿条记录的嵌入式数据库具有高效的 C 或 C++ API答案

【问题标题】：Which embedded database capable of 100 million records has an efficient C or C++ API哪个能够存储 1 亿条记录的嵌入式数据库具有高效的 C 或 C++ API
【发布时间】：2010-10-06 05:17:19
【问题描述】：

我正在寻找一个跨平台的数据库引擎，它可以处理数亿条记录的数据库，而不会严重降低查询性能。它需要有一个 C 或 C++ API，可以轻松、快速地构造记录并解析返回的数据。

极力劝阻那些数据必须与字符串相互转换才能将其输入数据库的产品。存储 IP 地址等内容的技术用户不希望或不需要这种开销。这是一个非常重要的标准，因此如果您要提及产品，请明确说明它们如何提供如此直接的 API。不想粗鲁，但我可以使用 Google - 请假设我已经找到了大多数主流产品，我在问，因为通常很难弄清楚它们提供的直接 API，而不仅仅是 SQL 的 C 包装器。

它不需要是 RDBMS - 一个简单的 ISAM 面向记录的方法就足够了。

虽然主要需求是单用户数据库，但将来可能会扩展到某种共享文件或服务器操作。

如果数据库来自小公司，则非常需要访问源代码，无论是开源还是通过许可。它不能是 GPL 或 LGPL。

【问题讨论】：

我想知道有多少数据库甚至可以满足这个要求，尤其是最后一条关于源代码的声明。
需求来自真实数据库，但出于非技术原因，我们正在探索替代方案。我避免提及名字以查看其他人的建议;-)
BobbyShaftoe：很多很多解决方案都是可能的......查看整个线程。
我提交了重新打开并更改了标题，因为我认为跳上这个并投票关闭它的人只是在追逐作为编辑的分数 - 标题之前要求“最佳”产品，但问题在要满足的一长串要求中非常明确，并且该问题在很长一段时间内被许多人投票认为有帮助。

标签： c database performance cross-platform

【解决方案1】：

你可以考虑 C-Tree by FairCom - 告诉他们我派你去的 ;-)

【讨论】：

c-tree 实际上是当前使用的引擎。许可和其他考虑因素的变化促使我寻找替代方案。该站点可能会继续使用 c-tree，但会为其他人提供一个很好的性能示例。
@[Andy Dent]：很难超越 C-Tree 的表现，他们已经在该领域领先了 20 多年！早在 2002 年，Ray Brown（总裁）和 Randal Hoff（Dir. Biz. Dev.）就非常愿意与我一起为另一家公司提供许可，在你放弃之前与他们交谈。

【解决方案2】：

我是hamsterdb的作者。

tokyo cabinet 和 berkeleydb 应该可以正常工作。 hamsterdb 肯定会工作。它是一个简单的 C API，开源，独立于平台，速度非常快，并且经过数百 GB 和数亿个项目的数据库测试。

如果您愿意评估并需要支持，请给我发邮件（hamsterdb.com 上的联系表格） - 我会尽我所能提供帮助！

再见克里斯托夫

【讨论】：

Hamsterdb 演变成 upscaleddb，看起来更有趣，但根据博客 upscaledb.com/blog/0015-release-of-upscaledb-2.2.1.html，它在 2017 年被有效地放弃了

【解决方案3】：

您没有提及您使用的平台，但如果只有 Windows 可以，请查看 Windows 2000 及更高版本中包含的嵌入式 ISAM 表引擎 Extensible Storage Engine（以前称为 Jet Blue）。它用于 Active Directory、Exchange 和其他内部组件，针对少量大型表进行了优化。

它有一个 C interface 并支持二进制数据类型 natively。它支持indexes、transactions，并使用日志来保证原子性和持久性。没有查询语言；您必须自己直接使用tables 和indexes。

ESE 不喜欢通过网络打开文件，也不支持通过文件共享来共享数据库。您将很难找到任何支持通过文件共享进行共享的数据库引擎。 Access Jet 数据库引擎（AKA Jet Red，完全独立的代码库）是我所知道的唯一一个，它以破坏网络文件而臭名昭著，尤其是当它们很大 (>100 MB) 时。

无论您使用什么引擎，您很可能都必须自己在自己的网络服务器进程中实现共享使用功能，或者使用离散的数据库引擎。

【讨论】：

投票赞成提供信息丰富的答案并提醒我我忘了说它必须是跨平台的

【解决方案4】：

对于几年后找到此页面的任何人，我现在正在使用 LevelDB 并在顶部添加一些脚手架来添加必要的多重索引。特别是，它非常适合 iOS 上的嵌入式数据库。我最终写了一本关于它的书！（LevelDB 入门，2013 年末来自 Packt）。

【讨论】：

LevelDB 在性能和可靠性方面确实是一个糟糕的选择。 LevelDB 设计本质上容易损坏，并且代码质量本身低于标准。请参阅此崩溃漏洞报告wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf 只有 LMDB 被证明是防崩溃的，并且它是完全跨平台的。
hyc 在推荐 LMDB 而非 LevelDB 方面并不是一个无私的一方，对于任何阅读了他的评论并且没有进一步深入了解他的隶属关系的人来说。我没有资格评论他意见的真实性，因为我没有详细比较这两个引擎，但他一直在关注 LevelDB 的帖子并将人们指向 LMDB。
是的，我是 LMDB 的作者。但独立研究证实了我所说的。您可能没有详细比较这两种引擎，但许多其他引擎都有。 usenix.org/conference/osdi14/technical-sessions/presentation/…

【解决方案5】：

一个选项可以是Firebird。它既提供基于服务器的产品，也提供嵌入式产品。

它也是开源的，所有类型的语言都有大量的提供者。

【讨论】：

谢谢（你好 Mitch），我什至有 Firebird 的书，但是像 ibpp.org 这样的 API 偏向于 SQL 端，纯 C API 带有大量免责声明：firebirdfaq.org/faq9
@Andy Dent：回答的是 jaydenm；我刚刚编辑添加了 firebird 链接 ;-)

【解决方案6】：

我相信您正在寻找的是 BerkeleyDB： http://www.oracle.com/technology/products/berkeley-db/db/index.html

别介意它是 Oracle，许可证是免费的，而且它是开源的——唯一的问题是，如果你重新分发使用 BerkeleyDB 的软件，你必须同时提供你的源代码——或者购买许可证。

它不提供 SQL 支持，而是直接查找（通过 b-tree 或哈希表结构，以更适合您的需要为准）。它非常可靠、快速、ACID、内置复制支持等等。

这是我上面提到的页面的一小段引述，其中列出了一些功能：

数据存储

Berkeley DB 快速存储数据，很容易没有发现的开销其他数据库。伯克利 DB 是 C 在同一进程中运行的库作为您的应用程序，避免进程间通信延迟使用远程数据库服务器。共享缓存将最活跃的数据保存在内存，避免昂贵的磁盘访问。

本地、进程中数据存储

架构中立的应用程序原生数据格式

索引和顺序检索（Btree、Queue、Recno、Hash）

每个应用程序有多个进程，每个进程有多个线程

用于高并发系统的细粒度和可配置锁定

多版本并发控制 (MVCC)

支持二级索引

内存中、磁盘上或两者兼有

在线 Btree 压缩

在线 Btree 磁盘空间回收

在线弃锁解除

磁盘数据加密 (AES)

记录高达 4GB，表格高达 256TB

更新：刚刚跑过这个项目，想到了你发布的问题： http://tokyocabinet.sourceforge.net/index.html 。它在 LGPL 下，因此不符合您的限制，但仍然是一个值得一试的有趣项目。

【讨论】：

每当像甲骨文这样的供应商要求您通过电子邮件向他们发送定价信息而没有给出价格范围的指示时，我都会感到非常紧张。
这是一个公平的问题。请注意，如果您不分发（或分发您的源代码），这些东西是免费的。您也可以尝试获取预购版本；它们同样稳定，并且没有附加 Oracle。

【解决方案7】：

SQLite 将满足这些标准，但未来最终的共享文件场景除外（实际上，如果网络文件系统正确实现文件锁定，它可能会这样做）。

【讨论】：

SQLite 将所有数据存储为字符串。我/不确定，但我认为 OP 关于将数据库数据存储为字符串的具体参考是他已经看过 SQLite 的某种神秘暗示。就个人而言，我也喜欢 SQLite。
我没有试图暗示任何事情 - 现有的 API 能够将直接二进制值倒入记录中，并且我已经被告知系统的最大用户对更改该模式不感兴趣的操作。有了这些数据量，您真的想将整数映射到字符串吗？
有一个基于 SQLite 的真正的客户端-服务器商业产品，带有 C++ SDK - realsoftware.com/realsqlserver
SQLite 不会将整数存储为字符串（我认为它可能有，但那至少是一两年前，如果不是更多的话）。事实上，它使用可变大小的二进制整数，因此它可以将字节和 int64 存储在同一列中，并且将使用尽可能少的空间。

【解决方案8】：

已经提到了许多好的解决方案（例如 SQLite）。让我添加两个，因为您不需要 SQL：

HamsterDB速度快，使用简单，可以存储任意二进制数据。不提供共享数据库。
Glib HashTable 模块似乎也很有趣，非常常见，因此您不会冒险进入死胡同。在另一端，我不确定是否有简单的方法可以将数据库存储在磁盘，它主要用于内存中的东西

我已经在数百万条记录项目中进行了测试。

【讨论】：

谢谢，看起来都很有趣。虽然 Glib 显然仅在 LGPL 下可用，但这并不排除它（尽管我对 LGPL 持谨慎态度，因为它限制了您的构建选项，以免它演变为 GPL）。

【解决方案9】：

既然您熟悉 Fairtree，那么您可能也熟悉 Raima RDM。

几年前它开源了，然后 dbstar 声称他们以某种方式获得了版权。不过，这似乎值得商榷。从阅读原始的 Raima 许可证来看，这似乎是不可能的。当然，可以保留原始代码版本。这是相当罕见的，但我有一份存档。

【讨论】：

【解决方案10】：

SQLite 往往是首选。它不会将数据存储为字符串，但我认为您必须构建一个 SQL 命令来进行插入，并且该命令将构建一些字符串。

如果您不需要关系数据库，BerkeleyDB 是一款设计精良的产品。我不知道 Oracle 对此收取什么费用，以及您是否需要为您的应用程序提供许可证。

我个人会考虑为什么您有一些要求。您是否进行过测试以验证您需要直接插入数据库的要求？似乎您可能需要几个小时来编写一个包装器，该包装器可以从您想要的任何 API 转换为 SQL，然后查看 SQLite、MySql... 是否满足您的速度要求。

【讨论】：

雄心勃勃的下属曾两次尝试用 SQL 引擎替换原来的引擎 - 大小是真正的要求，并且现有的 C++ 代码映射与二进制 API 配合得很好
哦，快。我将不得不开始使用“雄心勃勃的下属”作为信号线。它有合适的戒指。
不是我的线，也不是我的下属，但请随意使用这个词 ;-)
是的，sqlite.org/cintro.html 似乎很确定您使用的是基于 SQL 的间接 API，没有解决方法。

【解决方案11】：

曾经有一个产品叫 b-trieve，但我不确定是否包含源代码。我认为它已经停产了。我所知道的唯一一个面向 ISAM 的数据库引擎是 c-tree。

【讨论】：