在扩展存储文件系统中文件的应用程序时，我需要考虑什么？

Question

我很有兴趣制作一个应用程序，用户可以上传大文件（~2MB）转换为html文档。此应用程序将没有数据库。相反，这些html文件存储在文档源树之外的特定可写目录中。因此，随着向其添加更多文件，该目录将变得越来越大。用户应该能够通过访问相应的URL来查看这些html文件。除了所有安全问题之外，如果此目录继续增长，我还需要担心什么？访问内部文件的时间会更长吗？它会因此而崩溃吗？我应该每100个文件创建一个新目录，以防止这种情况吗？

重要的是，我想使用金字塔和python制作这个应用程序

Answer 1

您可能希望按用户，应用程序或类似方式对目录进行分区，以便无论如何都可以轻松管理 - 例如，如果用户停止使用该服务，您只需删除其目录即可。我也认为你会把它们拉上来。如果你保持良好的解耦，那么你以后就可以改变主意了。

我有兴趣看看如何使用像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 虽然我认为有一个安全问题，它是如此明显的名称。

Answer 2

这在很大程度上取决于您的文件系统。您可能想要查找git人员遇到的问题（也使用基于文件系统的唯一数据库）。

一般情况下，最好将该目录拆分，例如通过获取文件名的前两个或三个字母（或其中的哈希），并根据该键将文件分组到子目录中。你有一个像这样的结构：

uploaddir/
    00/
         files whose name sha1 starts with 00
    01/
         files whose name sha1 starts with 01

等等。这通过对可能较大的目录进行分区来减轻文件系统的负担。如果您希望确保没有用户可以通过专门上传名称哈希为相同初始字符的文件来执行拒绝服务攻击，那么您也可以使用不同的方式对哈希进行种子处理，或者对其进行加盐或类似的操作。

具体来说，大目录的效果是特定于文件系统的。有些可能会变慢，有些可能会很好地处理，有些可能会有文件的每个目录限制。