我开发了一个新网站,我想使用GridFS作为所有用户上传的存储,因为与普通的文件系统存储相比,它提供了很多优势.
由nginx提供服务的GridFS基准测试表明,它不如nginx提供的普通文件系统快.
有人在那里,谁已经在生产环境中使用GridFS,或者将它用于新项目？
我有一个rails 3 app,在herokus bamboo stack上运行良好/快速.为了测试我的应用程序是否适用于即将到来的雪松堆栈,我已按照"入门"指南将其部署到heroku.令我惊讶的是,一切运作良好,没有错误.我注意到的唯一区别是:与在竹堆上运行的app相比,响应时间相当慢.用独角兽而不是薄的测试显示没有差异.
您是否注意到两个堆栈之间的差异大致相同？
我已经有过MongoDB,CouchDB,Redis,Tokyo Cabinet和其他NoSQL数据库的经验.最近我偶然发现了Riak,它对我来说非常有趣.为了开始使用它,我决定写一个小的Twitter克隆,NoSQL World中的"hello world".要获得完全可用的克隆,有必要按时间顺序排序推文.在阅读了Riak文档之后,我发现Map-Reduce是这项工作的正确工具.在我的开发环境中它运行得很好,但是生产中的性能如何,有数百个并行查询？是否有其他的,可能更快的方法来排序数据,还是可以以有序的形式存储数据(如Cassandra)？
我想我找到了另一个解决这个问题的方法 - 一个简单的链表.因此,一个可能的实现可能是,每个用户都获得他/她自己的"时间线桶",其中存储了与推文 - 数据本身的链接(推文被单独存储在"推文"桶中).如您所知,此时间轴存储桶必须包含名为"first"的键,该键链接到最新的时间轴对象,并且是列表的起点.要在时间轴中插入新推文,只需在时间轴存储桶中插入一个新项目,将此新项目的"下一个"链接设置为"第一个" - 项目,然后将新项目设置为"第一个".
简而言之:像在链表中那样插入项目...
与Twitter一样,个人时间线只显示向用户显示的20条推文.要收到最后20条推文,只需要2个查询.为了加快速度,第一个查询使用Riak的链接行走能力来获取最新的20个对象,标记为"next".最后,第二个和最后一个查询使用第一个查询计算的键来接收推文本身(使用map/reduce).
要删除您刚刚取消关注的用户的推文,我会使用Riak 1.0的二级索引功能来接收相关的时间轴对象/推文.