我可能会参与一个项目，其中一个重要的组件是大量文件的存储（在这种情况下是图像，但它应该只是作为文件存储）。
传入文件的数量预计约为每周500,000（平均每个约100 Kb），每天大约100,000个文件，每秒5个。 在达到平衡状态之前，文件总数预计将达到数千万，其中文件因输入速率的各种原因而过期。
所以我需要一个系统，可以在高峰时间每秒存储大约5个文件，同时读取大约4个文件并随时删除4个文件。
我最初的想法是，一个简单的NTFS文件系统，其中包含一个简单的存储，过期和读取服务应该足够了。我可以想象服务创建每年，每月，每天和每小时的子文件夹，以便将每个文件夹的文件数保持在最低限度，并允许在需要的情况下手动过期。
已经讨论了一个大型NTFS解决方案here，但我仍然可以使用一些建议来解决在使用上述规范构建存储时遇到的问题，期望的维护问题以及存在哪些替代方案。我希望尽可能避免使用分布式存储。
修改
感谢所有意见和建议。关于该项目的更多奖励信息：
这不是最终用户提供图像的网络应用程序。没有透露太多，因为这是在合同阶段，它更多的是质量控制类别。想想带有传送带和传感器的生产工厂。这不是传统的质量控制，因为产品的价值完全取决于图像和元数据数据库的顺利运行。
自主应用程序以先进先出的顺序访问图像99％，但也会发生用户应用程序的随机访问。超过一天的图像主要用于存档目的，但这个目的也非常重要。
由于各种原因，图像的过期遵循复杂的规则，但在某些日期，应删除所有图像。删除规则遵循依赖于元数据和用户交互的业务逻辑。
每天都会有停机时间，可以进行维护。
优选地，文件存储器不必将图像位置传送回元数据服务器。如果选择了某种散列或分布式系统，则可以通过映射数据库从元数据中唯一地扣除图像位置。
所以我的问题是：
答案 0 :(得分：5)
答案 1 :(得分：3)
将图像存储在一系列SQLite数据库中。听起来很疯狂，但它比直接将它们存储在文件系统上要快得多，占用的空间更少。
SQLite在存储二进制数据方面非常有效，并且通过将文件存储在聚合数据库而不是单独的OS文件中，当图像不符合精确的块大小时（这对于这么多文件来说很重要），它可以节省开销。此外，SQLite中的分页数据可以提供比使用普通操作系统文件更快的吞吐量。
SQLite在写入方面存在并发限制，但在您所讨论的限制范围内，并且可以通过巧妙地使用多个（数百个）SQLite数据库来进一步减轻。
尝试一下，你会感到惊喜。
答案 2 :(得分：1)
根据此处提供的一般信息，提供一些建议，了解您的应用程序实际执行或将要执行的操作的详细信息。
使用文件的sha1作为文件名（如果需要，在DB中存储用户提供的文件名）
问题在于，如果您关心数据，则无论如何都必须存储校验和 如果你使用sha1（sha256，md5，其他哈希），那么将很容易验证文件数据 - 读取 file，cacl hash，如果它与名称匹配，则数据有效。假设这是 某种类型的webapp，基于哈希的文件名可以在提供数据时用作etag。 （检查.git目录中的示例）。这假设你不能使用 用户提供的文件名无论如何，因为用户可以发送类似“＆lt;＆gt;？:(）。txt”
使用从您的应用角度来看有意义的目录结构
这里的主要测试是，应该可以通过查看来识别文件 仅在PATH \ FILE中，没有在DB中执行元数据查找。如果你的存储/访问模式是严格基于时间的，那么STORE \ DATE \ HH \ FILE是有意义的，如果你有用户拥有的文件，那么也许STORE \＆lt; UID的第一个N位＆gt; \ UID \ FILE会有意义。
使用事务进行文件/元数据操作
即。开始写文件元数据trx，尝试将文件写入FS，成功提交trx，回滚错误。当你在DB中有文件元数据而FS和vise-verso中没有文件时，应该特别小心避免这种情况。
使用多个根存储位置
即。 STORE01 \ STORE02 \ STORE \ - 这可以帮助开发（以及稍后扩展）。 有些开发人员可能会使用一台中央数据库和文件存储器，这些存储器是他们机器的本地存储器。从一开始就使用STORE将有助于避免元数据/文件梳理时的情况。将在应用程序的一个实例中有效，而在另一个实例中无效..
永远不会在DB中存储绝对路径