我对制作一个用户可以上传大文件 (~2MB) 并转换为 html 文档的应用程序很感兴趣。此应用程序将没有数据库。相反，这些 html 文件存储在文档源树之外的特定可写目录中。因此，随着更多文件的添加，该目录将变得越来越大。用户应该能够通过访问相应的 url 来查看这些 html 文件。除了所有安全问题，如果这个目录继续增长，我需要担心什么？当文件更多时，访问其中的文件会花费更长的时间吗？它会因此而崩溃吗？我应该每 100 个文件左右创建一个新目录以防止这种情况发生吗？
重要的是，我想用金字塔和python制作这个应用程序
【问题讨论】：
标签： python filesystems scalability pyramid
这很大程度上取决于您的文件系统。您可能想查找 git 人员遇到的问题（也使用基于文件系统的唯一数据库）。
一般来说，明智的做法是拆分该目录，例如通过获取文件名的前两个或三个字母（或这些字母的哈希）并根据该键将文件分组到子目录中。你会有这样的结构：
uploaddir/
00/
files whose name sha1 starts with 00
01/
files whose name sha1 starts with 01
等等。这通过对可能很大的目录进行分区来减轻文件系统的负担。如果您想确保没有用户可以通过专门上传名称散列为相同初始字符的文件来执行拒绝服务攻击，您还可以对散列进行不同的播种或加盐或类似的方式。
具体来说，大目录的影响是非常特定于文件系统的。有些可能会变慢，有些可能会处理得很好，有些可能对文件有每个目录的限制。
【讨论】：
您可能希望按用户、应用程序或类似方式对目录进行分区，以便无论如何都易于管理 - 例如，如果用户停止使用该服务，您可以删除他们的目录。另外我想你会把它们拉上拉链。如果您保持良好的解耦，那么您以后就可以改变主意。
我很想知道使用 SQLite 之类的东西如何为您工作，因为您可以为每个分区目录拥有一个 sqlite db。
我认为 HTML 文件比他们上传的文件大，所以为什么要存储大的 HTML 文件。
像 Mongodb 之类的东西是不可能的？由于您的应用程序与多个服务器一起扩展，因此您在访问不同服务器上的其他文件时遇到了问题，除非您首先使用某种技术选择正确的服务器。那么您的服务器可能处于闲置状态，因为没有人想要那里的文档。
为什么仅限于将文件存储在目录中，是 POC 吗？
编辑
我发现阅读 http://blog.fogcreek.com/the-trello-tech-stack/ 之类的内容很有价值，我建议您找到一个已经在做您所做的事情的网站，并阅读他们的技术。堆栈。
正如有人已经评论过为什么不使用 Amazon S3 或类似产品。
现实地问自己，你想象有多少用户，你真的想花很多精力担心成为下一个 facebook 并尝试为后端做终极技术堆栈，当你可以让你的东西在那里被使用时.
几年前，我在一个系统上工作，该系统在文件系统上存储保险证书，我们用完 inode。！
我敢说这是一个糟糕的例子，看看什么对你和你的应用有用。
编辑
HAProxy 我相信是为了处理所有负载平衡问题。
我想作为用户我想http://docs.yourdomain.com/myname/document.doc 虽然我认为它是如此明显的名称存在安全问题。
【讨论】：