logo标签列表

如何高效地存储数十万份文档？

databasefile-storage
3
我正在开发一个需要存储大量文档（PDF、Word文件等）的系统。我正在使用Solr/Lucene来搜索从这些文档中提取出的相关信息，但我还需要一个地方来存储原始文件，以便用户可以打开/下载它们。
我考虑了几种可能性：
- 文件系统 - 可能不是存储100万个文档的好主意。 - SQL数据库 - 但我不需要大部分关系特性，因为我只需要存储二进制文档及其ID，所以这可能不是最快的解决方案。 - NoSQL数据库 - 我没有任何经验，所以我不确定它们是否好用，而且也有很多种，我不知道该选择哪一种。
我正在寻找的存储方式应该具备以下特点：
- 快速 - 可扩展 - 开源（不是必须的，但很好）
您认为什么是最佳的存储方式？
4个回答
5
一个文件系统，顾名思义，旨在以高效和可扩展的方式存储大量文件。
2
确保使用一个好的文件系统。FAT 可能不够用，ReiserFS 或 XFS 是更好的选择。对于 extN、NTFS 等，你的情况可能有所不同。另请参考 http://serverfault.com/questions/43133/filesystem-large-number-of-files-in-a-single-directory。 - Tom Anderson
1
@Tom：确实，说得好，但这（几乎）是不言而喻的...如果你选择关系型数据库，你也要确保它是一个好的数据库；同样，如果你选择了NoSQL数据库。无论你选择哪个系统，都要确保它能够很好地完成工作。 - LukeH
2
没错！但有时候那些不言而喻的事情也需要说出来。 - Tom Anderson
1

你可以关注Facebook，因为它存储了大量文件（150亿张照片）：

  • 他们最初使用由商业存储设备提供的NFS共享。
  • 然后他们转向自己实现的http文件服务器Haystack。

如果您想了解更多信息，请查看Facebook笔记http://www.facebook.com/note.php?note_id=76191543919

关于NFS共享。请记住，出于性能原因，NFS共享通常限制一个文件夹中的文件数量。（如果您认为所有最新的文件系统都使用B树来存储其结构，则可能会有点直观上的不理解）。因此，如果您使用商业NFS共享（如NetApp），您可能需要将文件保存在多个文件夹中。

如果您拥有任何类型的文件ID，就可以这样做。只需将Ascii表示分成几个字符组，并为每个组创建文件夹。 例如，我们使用整数作为ID，因此具有ID 1234567891的文件存储为storage/0012/3456/7891。

希望这能帮到您。

0

依我之见...

我会将文件压缩后存储到磁盘（文件系统）中，并使用数据库来跟踪它们。

如果这是它唯一的工作，可能会使用Sqlite。

0
文件系统：在考虑整体情况时，DBMS再次使用文件系统。而文件系统专门用于保存文件，因此您可以看到优化（正如LukeH所提到的）。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接