BLOB存储 - 100+ GB，MySQL，SQLite或PostgreSQL + Python

Question

我有一个简单的应用程序的想法，它将监视一组文件夹，索引它找到的任何文件。 gui将允许我快速标记新文件并将它们移动到单个数据库中进行存储，并提供一种简单的机制，用于按标记，名称，文件类型和日期查询数据库。目前我在一对可移动硬盘上有大约100多GB的文件，数据库至少会有那么大。如果可能，我想支持嵌入式二进制文件和文本文档的全文搜索。这将是一个单用户应用程序。

没有尝试开始数据库战争，但是哪种开源数据库最适合我？我很确定SQLLite不在桌面上，但我可能错了。

Answer 1

为什么要将文件存储在数据库中？只需存储您的元数据和文件名。如果由于某种原因需要将它们复制到新位置，只需将其作为文件系统副本即可。

删除文件内容后，任何有能力的数据库都可以处理数十万个文件的元数据。

Answer 2

我仍在为自己的某个项目研究此选项，但CouchDB可能值得一看。

Answer 3

我的偏好是将文档与元数据一起存储。一个原因是关系完整性。如果没有db的操作，您无法轻松移动文件或修改文件。我确信我可以处理这些问题，但它并不像我想的那样干净，而且我的经验是，大多数供应商现在可以处理数据库中的大量二进制数据。我想我想知道PostgreSQL或MySQL在这些领域是否有任何明显的优势，我主要熟悉Oracle。无论如何，感谢您的回复，如果数据库知道外部文件的位置，如果我愿意，也可以在以后将文件带入。该问题的另一个方面是，在使用Python时，任何一个数据库都更容易使用。我假设这是洗漱。

Answer 4

我总是讨厌回答“不要”，但你最好用Lucene（PyLucene）之类的东西进行索引。几乎总是建议将数据存储在数据库而不是文件内容中。

除此之外，这些数据库引擎都不会将LOB存储在单独的数据空间中（它们将嵌入到表的数据空间中），因此任何这些引擎都应该几乎相同（除了sqllite之外）。您需要转移到Informix，DB2，SQLServer或其他人才能获得这种二进制对象处理。

Answer 5

几乎任何一个都可以工作（即使SQLLite并不打算在并发多用户环境中使用，这可能是一个问题......）因为你不想索引实际的内容文件。

唯一的限制因素是给定数据库的最大“数据包”大小（通过数据包我指的是查询/响应）。通常这些限制大约为2MB，这意味着您的文件必须小于2MB。当然你可以增加这个限制，但是整个过程效率很低，因为例如要插入一个你必须要的文件：

• 将整个文件读入内存
• 在查询中转换文件（通常意味着对其进行十六进制编码 - 从而使大小从一开始就加倍）
• 执行生成的查询（本身意味着 - 对于数据库 - 它必须解析它）

我会使用简单的数据库和使用命名约定存储的相关文件，这使得它们易于查找（例如基于主键）。当然，这种设计不是“纯粹的”，但它会表现得更好，也更容易使用。

Answer 6

为什么要浪费时间模仿文件系统应该能够处理的东西？更多存储+ grep是你的答案。