通过 MongoDB 的 GridFS 提供静态文件

Question

我对 Django 还很陌生，我正在尝试在 OpenShift 上部署一个小型爱好项目。我知道有些约定建议不要让 Django 提供静态和媒体文件，因为它效率低下。我还注意到，当DEBUG 关闭时，Django 拒绝提供媒体文件。这就是为什么我正在寻找更好的方式来提供这些内容。

Django 的文档支持像 Amazon S3 这样的 CDN 作为提供静态服务的最佳方式之一，但作为一个爱好者，我现在更愿意坚持使用免费增值解决方案。我发现 MongoDB——我还不太熟悉的另一种技术——提供了GridFS 作为存储后端。我可以通过 MongoLab 获得免费的 MongoDB 存储，所以这对我来说很有趣。

这样的建设会在实践中发挥作用还是这是疯狂的谈话？如果这是可行的，我需要对我的 OpenShift 环境和 Django 设置进行哪些更改以让 GridFS 提供静态内容？我见过人们使用CloudFlare's free CDN 提供静态内容的替代设置，但是我无法从本地开发环境上传/访问媒体文件。

Answer 1

长话短说：这是个坏主意。

原因如下：为了提供静态文件，您首先需要处理请求，从 GridFS 获取数据，它实际上将文件分散在 255k 块中，这些块必须被收集（取决于大小，当然），只有这样他们才能被退回。

我倾向于使用varnish 来缓存应用程序提供的静态文件，无论是 django 还是 Servlet 容器。像这样工作：

1. 所有请求都发送到清漆，清漆要么从缓存中提供所请求的资源，要么将其交给后端。
2. Varnish 使用您的 django 应用程序作为后端。不过，我通常让 django 运行在一个额外的 lighttpd 后面。
3. 当 django 返回一个静态文件时，varnish 将该文件放入内存缓存区。我通常为此分配了大约 100M - 有时甚至更少。您应该知道静态文件的大小。我倾向于做一个简单的缓存配置，比如“缓存所有以 .css、.js、.png 结尾的文件”。
4. 此静态资源的所有后续请求现在都将由 varnish 提供服务 - 从内存通过 sendfile 系统调用，甚至不会到达后端。

总而言之：这种方式可以从您的应用程序中获取负载，减少延迟，快速交付资源，无需任何编程工作即可轻松设置。

编辑：对于 OpenShift 环境：保持原样即可。从 MongoDB 提供静态文件根本没有意义。