我对NoSQL数据库相对来说比较新，我必须评估不同的NoSQL解决方案以用于监视工具。CouchDB可以每天处理1500万条记录吗？
的情况如下： 一个数据是差不多100字节大，但实际上有很多他们。在一天，我们得到约15万条记录。所以我目前900万条记录（约15GB的SQL-插入脚本）
我的问题是测试：是否CouchDB的适合我的需要？我需要做的范围querys（上创建记录的日期），并总结了一些acoording由“二级指标”存储在数据）。 definied组列的我知道的MapReduce可能是计算出最佳的解决方案，但是CouchDB的JavaScript能够在可接受的时间内做到这一点吗？
我已经尝试过的MongoDB，但它的MapReduce真正的穷人做了一个糟糕的工作......我也读到的HBase和卡桑德拉。但梅比CouchDB的也是一个很好的可能性
我希望我给你所有必要的信息。谢谢您的帮助！
安迪
坦率地说，在这个时候，除非你有非常好的硬件，的Apache CouchDB的可能会遇到问题。地图/减少可能会很好。 CouchDB的增量式 map/reduce非常适合您的要求。
作为开发者，你会爱上它！不幸的是，作为系统管理员，您可能会注意到比预期更多的磁盘使用情况和I/O。
我建议尝试一下。作为HTTP和Javascript，很容易做可行性测试。请记住，初始视图构建需要很长时间（让我们假设参数需要比其他所有竞争数据库更长的时间）。但那个时候永远不会再被再度花费。地图/减少运行每个文档只有一次（实际上每个文档更新）。
如果名牌Apache CouchDB速度很慢，但您喜欢在沙发上放松，那么BigCouch群集将毫无问题地处理该负载。我非常肯定有BigCouch集群具有比这更大的数据和I/O需求。
+1然而，可以公平地指出，这里的“从不”意味着“直到对设计文档进行一些更改会引起视图的重建”。只是为了让你准备好这个...... :) –
对于生产使用，有一个解决方案。如果你问怎么样，我会很乐意提供细节。短版本：发送带有不同ID的新设计文档。查询它来建立索引。完成后，使用HTTP COPY重新命名新的旧的。原子升级，无需停机。 – JasonSmith
+1这是一个公平的问题和公平的答案（我试着对新成员保持温和，所以没有解释（因为你斜向问），我没有近距离投票）。 – msw
首先，知道性能的唯一方法就是测量它，因为有太多变数可供猜测。其次，当半个世纪的RDBM经验等待处理您的100个八位字节数据时，不要被结构化存储吸引过多。我猜在100B /行，你的数据不是很变化（SS擅长）。 – msw
好点，@msw。当然，明确知道绩效的方式是衡量;不过，我认为要求第一次逼近球场估计是有效的。我将问题标题修改得更加黑白。 （不知道你是否投票结束或者是其他人，但恕我直言，这是一个公平的问题。）最后，关于RDBM完全正确。他们比我们信誉更有价值。 – JasonSmith
我正在评估的数据当前是由一个非常强大的SQL-Server处理的。但它无法处理用户发送的用于从大量数据中获取信息的请求。它只需要很多时间。这就是为什么我们搜索具有横向扩展能力的NoSQL解决方案。 – andy