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