【发布时间】：2013-06-30 15:20:49
【问题描述】：
我正在开发一个应用程序，该应用程序需要存储与音乐文件（艺术家、标题、播放次数等）相关的元数据，以及整数集（特别是 SHA-1 哈希）。
我选择的解决方案需要：
- 提供“快速”存储和检索（查看可能包含数千首歌曲的列表时，我需要能够或多或少地以交互方式检索元数据）。
- 跨平台（Linux、Windows 和 OSX）。
- 提供一个我可以通过 C++ 与之交互的接口。
- 开源（或者至少像啤酒一样免费）。
- 提供快速集合操作（并集、交集、差集） - 如果解决方案不提供此功能，但它允许我存储二进制数据，我可以使用"Fast Set Operations Using Treaps" 之类的技术自己实现此功能。
- “嵌入”——也就是说，无需我
fork另一个进程即可运行，或者至少提供一个简单的接口来执行此操作（如 libmysqld）。
我考虑过的解决方案包括：
- 平面文件。这非常简单，但除了平面数据存储之外不提供任何功能。
- SQLite。这似乎是一个非常受欢迎的选项，但它似乎在性能和并发方面存在一些问题（请参阅KDE's Akonadi，了解一些示例问题）。
- 嵌入式 MySQL/MariaDB。这似乎是一个合理的选择，但考虑到我不需要很多复杂的 SQL 功能，它也可能有点重量级。
我认为完美的假设解决方案类似于 Redis，但它将数据持久保存到磁盘，并且仅将部分数据存储在内存中以加快检索速度。 Redis 本身可能不是一个好的选择，因为 1) 我需要手动 fork 它，2) 它的 Windows 端口似乎不是坚如磐石，以及 3) 将我的 所有 数据存储在 RAM 中会不太理想。
对于此类问题还有其他解决方案吗，或者我已经列出的解决方案之一比其他解决方案好得多？
【问题讨论】：
-
Akonadi 中基于 Mutex 的事务序列化（必需，因为 SQlite 对并发的支持可能不够）可以在 IMAP 同步等后台操作进行时阻塞客户端。 呵呵?为什么见鬼人们在锁定他们的数据库并调用一个 SQLite 问题的同时进行 IMAP 同步（无论这意味着什么）？
-
你知道，SQlite 网站上的基准测试似乎与 KDE 所说的完全矛盾，Akonadi 的糟糕表现并不会让我感到惊讶。也许 SQlite 确实值得更多研究。
-
SQlite 无处不在，从您的浏览器到可以处理成千上万用户的生产服务器（去过那里，做过那个，得到了 T 恤）。这不是性能问题。
-
我不明白为什么人们会投票结束这个问题，因为“相关”列中的每个问题都非常相似，而且不仅没有被关闭，而且还有投票。询问应该使用哪种类型的数据库来解决特定问题似乎属于常见问题解答中的“程序员常用的软件工具”类别。
标签： c++ database data-structures embedded-database