按投票排序
按时间排序
6 个回答
压力以及数据量比较大的业务不推荐使用Mongo GridFS。
Mongo GridFS在高并发(每秒写入10M,持续半小时到一个小时)的情况下secondary会无法catch up with primary。
Mongo GridFS不是为分布式存储而设计的,它解决的问题领域是小型业务已经使MONOGODB,但是又需要存储一些文件,而且需要给这些文件加一些元信息。
用它来存储图片以小文件是比较合适的。
但是把它当大规模的分布式存储系统就不太合适的,那你应该用S3或者其它云存储解决方案了
Mongo GridFS在高并发(每秒写入10M,持续半小时到一个小时)的情况下secondary会无法catch up with primary。
Mongo GridFS不是为分布式存储而设计的,它解决的问题领域是小型业务已经使MONOGODB,但是又需要存储一些文件,而且需要给这些文件加一些元信息。
用它来存储图片以小文件是比较合适的。
但是把它当大规模的分布式存储系统就不太合适的,那你应该用S3或者其它云存储解决方案了
gridfs是mongodb为了解决单个document不能超过4M的问题而推出的,通过将文件进行切分(默认256k,最大4M)存成单独的document(fs.chunks中),并保存一个文件索引表(fs.files)。
从原理上可以看出,如果你的文件并不大,不超过4M(当然,还要减去一些元数据的占用),那么大可不必采用gridfs,使用传统的collection会得到更高的性能。
补充:
1.8版本中doc的上限已经从4M上调到16M,相信对于绝大多数图片来说都够了。
从原理上可以看出,如果你的文件并不大,不超过4M(当然,还要减去一些元数据的占用),那么大可不必采用gridfs,使用传统的collection会得到更高的性能。
补充:
1.8版本中doc的上限已经从4M上调到16M,相信对于绝大多数图片来说都够了。
1. 有各种成熟的分布式文件系统,如fastdfs,mfs,也可以试试
2. 使用gridFs是因为你完全信赖mongodb,但这意味着风险,非常重要的数据建议使用replication set,不依赖单机可靠性.
这里有一个公司使用了mongodb存储音乐文件
http://blog.wordnik.com/12-months-with-mongodb
2. 使用gridFs是因为你完全信赖mongodb,但这意味着风险,非常重要的数据建议使用replication set,不依赖单机可靠性.
这里有一个公司使用了mongodb存储音乐文件
http://blog.wordnik.com/12-months-with-mongodb