10

我正在开发一个应用程序，该应用程序需要存储与音乐文件（艺术家、标题、播放次数等）相关的元数据，以及整数集（特别是 SHA-1 哈希）。

我选择的解决方案需要：

  • 提供“快速”存储和检索（在查看可能包含数千首歌曲的列表时，我需要能够或多或少地以交互方式检索元数据）。
  • 跨平台（Linux、Windows 和 OSX）。
  • 提供一个我可以从 C++ 交互的接口。
  • 开源（或者至少像啤酒一样免费）。
  • 提供快速集合操作（​​并集、交集、差集） - 如果解决方案不提供此功能，但它允许我存储二进制数据，我可以使用类似“Fast Set Operations Using Treaps”之类的技术自己实现此功能。
  • 被“嵌入”——也就是说，无需我使用fork另一个进程即可操作，或者至少提供一个简单的界面来执行此操作（如 libmysqld）。

我考虑过的解决方案包括：

  • 平面文件。这非常简单，但除了平面数据存储之外不提供任何功能。
  • SQLite。这似乎是一个非常受欢迎的选项，但它似乎在性能和并发方面存在一些问题（请参阅KDE 的 Akonadi，了解一些示例问题）。
  • 嵌入式 MySQL/MariaDB。这似乎是一个合理的选择，但考虑到我不需要很多复杂的 SQL 功能，它也可能有点重量级。

我认为完美的假设解决方案类似于 Redis，但它将数据持久保存到磁盘，并且仅将部分数据存储在内存中以快速检索。Redis 本身可能不是一个好的选择，因为 1) 我需要fork手动操作，2) 它的 Windows 端口似乎不够坚如磐石，以及 3) 将我的所有数据存储在 RAM 中并不理想。

对于此类问题是否还有其他解决方案，或者我已经列出的解决方案之一比其他解决方案好得多？

4

2 回答 2

4

最后，我决定将 SQlite 用于元数据。它似乎与例如 libmysqld 一样快，如果不快的话，它有一个非常简单干净的 C 接口。根据基准，它应该足够快以满足我的需求。

对于较大的数据结构，我打算只将它们存储在单独的二进制文件中（SQlite 网站说它可以存储二进制数据，但是如果您的数据大小超过一定数量，则将其存储在平面文件中会更快 - 请参阅本页）。

于 2013-07-19T15:35:09.520 回答
3

不要将二进制文件 BLOBS 存储在 SQLite 中，除非你想要一个大象大小的数据库。只需在文件系统上存储一个带有路径文件名的字符串。SQLite 唯一的缺点是它不允许远程（Web）访问，但您可以将其嵌入到小型 TCP/HTTP 服务器中。

于 2017-04-29T18:19:34.567 回答