我目前运行一个基于MySQL的网站，用户可以在每次有人完成广告时宣传广告并获得收入。每次有人观看广告（“展示”），每次用户点击添加（“点击”）以及每次有人完成广告（“潜在客户”）时，我们都会记录。
由于我们获得了如此多的流量，因此我们在每个相应的表中都有数百万条记录。然后，我们必须查询这些表，以便让用户了解他们已经获得了多少，因此我们最终会在一次请求中多次对数百万行的表执行多次查询，同时进行数百次。
我们正在寻求从MySQL迁移到键值存储或类似的东西。我们需要能让我们存储所有这些数百万行的内容，以毫秒为单位查询它们，最重要的是，使用adhoc查询我们可以查询任何单个列，因此我们可以执行以下操作：
FROM leading WHERE country ='US'AND_id = 501（显然是NoSQL等价物）
FROM点击WHERE ad_id = 1952 AND user_id = 200 AND country ='GB'
等
有没有人有任何好的建议？我在考虑MongoDB或CouchDB，但我不确定他们是否能够处理每秒多次查询数百万条记录以及我们需要的特殊查询类型。
谢谢！
答案 0 :(得分：5)
根据这些要求，如果遇到负载问题，最好还是坚持使用SQL并设置复制/群集。您可以在文档数据库上设置索引，以便可以进行这些查询，但是您并没有真正获得当前系统的任何内容。
NoSQL系统通常省略了关系系统的一些更复杂的功能，从而提高了性能。这意味着只有在您的方案不需要这些功能时，它们才会有用。对表格数据运行即席查询正是SQL的设计目标。
答案 1 :(得分：2)
CouchDB的map / reduce是 incremental ，这意味着它只处理一次文档并存储结果。
让我们暂时假设CouchDB是世界上最慢的数据库。您的第一个查询包含数百万行，可能需要20个小时。听起来很糟糕。但是，您的第二个查询，第三个查询，第四个查询和第100个查询将花费50毫秒，可能包括HTTP和网络延迟等100个。
你可以说CouchDB没有通过基准测试，但在学校里获得了很高的荣誉。
我不担心性能，而是CouchDB能否满足您的即席查询要求。 CouchDB想知道将发生什么查询，因此它可以在查询到达之前预先进行艰苦的工作。当查询到达时，答案已经准备就绪了！
使用CouchDB，您的所有示例都。所谓的 merge-join （很多平等条件）都没问题。但是，CouchDB不能同时支持多个不等式查询。您不能在一次查询中向18-40岁之间用户点击次数少于10次的用户询问CouchDB。
关于CouchDB的HTTP和Javascript界面的好处是，很容易进行快速的可行性研究。我建议你试一试！
答案 2 :(得分：2)
大多数人可能会推荐像这样的跟踪/分析系统 MongoDB ，原因很简单。您应该阅读“MongoDB权威指南”一书中的„MongoDB for Real-Time Analytics”章节。根据数据大小和扩展需求，您可以获得所有性能，无架构存储和即席查询功能。如果系统的耐用性和不可预测性问题对您有风险，您需要自行决定。
对于更简单的跟踪系统， Redis 将是一个非常好的选择，提供丰富的功能，超快的速度和真正的耐用性。要了解如何在Redis中实现此类系统，请参阅this gist。缺点是，您需要自己定义所有“索引”，而不是像“免费”那样获取它们，就像MongoDB一样。然而，没有免费午餐，MongoDB指数绝对不是免费午餐。
我认为您应该了解 ElasticSearch 如何让您：
它本身就是一个“全文搜索引擎”，但不要让自己感到困惑。阅读„Data Visualization with ElasticSearch and Protovis“文章，了解ElasticSearch的真实世界用例作为数据挖掘引擎。
在these slides上查看“滑动窗口”场景的真实世界用例。
有许多可供ElasticSearch使用的客户端库，例如Ruby的Tire，因此很容易快速启动原型。
为了记录（对@jhs :)充分尊重，根据我的经验，我无法想象 Couchdb 是一个可行且有用的选项。不过，这将是一个非常棒的备份存储空间。
答案 3 :(得分：1)
如果您的工作集可以放入内存中，并且您索引文档中的正确字段，那么您将全部设置好。你的问题不是很典型的东西，我确信使用适当的硬件，正确的集合设计（非规范化！）和索引你应该很好。阅读Mongo查询，并使用explain()来测试查询。远离IN和NOT IN条款，这是我的建议。
答案 4 :(得分：1)
这实际上取决于您的数据集。 NoSQL设计的首要规则是首先定义您的查询方案。一旦你真正理解了如何查询数据，那么你可以查看各种NoSQL解决方案。默认的分配单位是关键。因此，您需要记住，您需要能够在节点机器之间有效地分割数据，否则您将最终得到一个水平可伸缩的系统，所有工作仍在一个节点上完成（尽管根据具体情况更好的查询）。
您还需要回顾CAP定理，大多数NoSQL数据库最终都是一致的（CP或AP），而传统的Relational DBMS是CA.这将影响您处理数据和创建某些事物的方式，例如密钥生成可能会变得棘手。
还记得比HBase等系统中没有索引概念。您的应用程序逻辑需要构建所有索引，并且需要对所有更新和删除进行管理。使用Mongo，您实际上可以在字段上创建索引并相对快速地查询它们，还可以将Solr与Mongo集成。您不仅需要在Mongo中按ID查询，就像在HBase中进行查询一样，这是一个列族（也称为Google BigTable样式数据库），您实际上拥有嵌套的键值对。
因此，再次涉及到您的数据，您要存储的内容，您计划如何存储它，以及最重要的是您希望如何访问它。 Lily项目看起来非常有前途。我参与的工作我们从网上获取大量数据，我们将其存储，分析，剥离，解析，分析，流式传输，更新等等。我们不只是使用一个系统而是很多最适合手头的工作。对于这个过程，我们在不同阶段使用不同的系统，因为它使我们能够快速访问我们需要的地方，提供实时流式传输和分析数据的能力，重要的是，随时跟踪所有内容（如生产中的数据丢失）系统是一个大问题）。我正在使用Hadoop，HBase，Hive，MongoDB，Solr，MySQL甚至是好的旧文本文件。请记住，使用这些技术生产系统比在服务器上安装MySQL要困难一些，有些版本不稳定，你真的需要先进行测试。在一天结束时，它实际上取决于业务阻力水平和系统的任务关键性。
迄今为止没有人提到的另一条路径是NewSQL--即水平可扩展的RDBMS ......有一些像MySQL集群（我认为）和VoltDB可能适合你的原因。
同样，要了解您的数据和访问模式，NoSQL系统也是非Rel，即非关系，并且更适合非关系数据集。如果您的数据本质上是关系型的，并且您需要一些真正需要执行诸如笛卡尔积（也称为连接）之类的SQL查询功能，那么您可能更好地坚持使用Oracle并在索引，分片和性能调整方面投入一些时间。
我的建议是实际使用几种不同的系统。但是对于您的用例，我认为Column Family数据库可能是最佳解决方案，我认为有一些地方已经针对非常类似的问题实施了类似的解决方案（我认为NYTimes正在使用HBase来监控用户页面点击）。另一个很好的例子是Facebook等，他们正在使用HBase。这里有一篇非常好的文章可以帮助你一路走来，并进一步解释上面的一些观点。 http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html
最后一点是NoSQL系统不是全部而是最终结束。将您的数据放入NoSQL数据库并不意味着它将比MySQL，Oracle甚至文本文件更好地执行...例如，请参阅此博文：http://mysqldba.blogspot.com/2010/03/cassandra-is-my-nosql-solution-but.html
我看看;
MongoDB - 文档 - CP
CouchDB - 文档 - AP
Redis - 在内存键值（非列族）中 - CP
Cassandra - 专栏系列 - 可用＆amp;分区容忍（AP）
HBase - 列族 - 一致＆amp;分区容忍（CP）
Hadoop / Hive - 另请参阅Hadoop流式传输......
Hypertable - 另一个CF CP DB。
VoltDB - 一个非常好看的产品，一个分布式的关系数据库，可能适用于您的情况（可能更容易移动）。它们似乎也提供了企业支持，这可能更适合产品环境（即为商业用户提供安全感）。
任何方式都是我的2c。玩弄系统真的是你找出真正适用于你的情况的唯一方法。