我是meteor和mongodb的初学者，我正在寻找一种方法在mongodb的集合中同时存储许多图像。如果有演示或其他可以帮助我的东西请给我。谢谢！
答案 0 :(得分：13)
管理文件上传既复杂又难，取决于您处理的文件类型和文件数量
如果图像或文件的数量和大小不是很大，那么可以尝试mongoDB GridFS，有两个支持GridFS的着名软件包：
meteor add cfs:standard-packages cfs:gridfs CollectionFS还支持服务器文件系统（从不将此用于用户上传文件）AWS-S3，甚至Dropbox。 CFS非常强大，并且具有许多有用的功能。但是，我在使用它时遇到了一些问题，并且可以弄清楚如何到处走走，所以我搬走了......（huge number of open bug tickets听起来不正确）meteor add vsivsi:file-collection与CFS相比轻量级，仅支持GridFS。离开CFS后我暂时转换到文件集合，它更容易启动和运行，IMO更容易预测。BUT！ GridFS的问题在于 MongoDB的维护成本很高 ，请参阅mongolab和compose.io（以前的mongohq）定价。它很昂贵，因为维护mongo很难，甚至调试很难，如果你的数据库崩溃，你的应用程序也不会工作！因此，保持文件上传远离mongoDB可能是一个更好的主意......
简短回答是：S3（或Google云/等效的Azure），您可以看到定价here。 S3稳定，安全，便宜，并且完美缩放（Dropbox仍然使用S3）。
但问题是...... S3更难学。我目前使用slingshot来管理客户端文件上传（因此大型文件上传不会减慢我的网络服务器速度），并且到目前为止工作得很好（如果这个软件包不适合你，那么你可以随时切换回官方AWS SDK，例如this或this。
虽然难以学习和设置，但S3非常灵活且功能强大，因此如果您允许用户将文件上传到您的应用程序，存储大量文件，想要拥有不同的用户角色/权限，或者只是我想要准备规模，我认为S3是首选。
有一些服务提供简单的设置文件上传和托管，你只需要付费，哈哈。
我个人最喜欢的是Filepicker（重命名为filestack），您可以尝试他们的免费计划，也可以meteor package to use。我在几个月前使用它时称它为filepicker.io，并且工作正常（现在我切换到我自己的S3）。
我从不建议在mongoDB中存储任何静态文件，即使是微小的图像。对于长期和可扩展性，S3 + cloudfront（用于提供静态文件的CDN）是解决方案。但是，如果您刚刚开始构建应用，那么您就不应该浪费时间来设置所有这些AWS配置/策略。我建议从filepicker开始，只需输入代码片段就可以了，然后你可以专注于构建真正的核心功能。