我们正在开发一个非常大的项目，我想知道是否有人可以给我一些关于我们应该选择什么数据库后端的建议。

我们的系统由1100个电子设备组成，它们向中央服务器发送信号，然后服务器存储信号信息(信号长约35个字节)。 这些设备每分钟每分钟发送大约3个信号，所以如果我们做数字，那么数据库上每天将有4.752.000个新记录，每月新记录总数为142.560.000。

我们需要一个快速可靠的数据库后端。 当然，我们需要在该DB上进行一些复杂的数据挖掘。 我们正在对MongoDB / Cassandra / Redis / CouchDB进行一些研究，但文档网站仍处于早期阶段。

有帮助吗？想法？

非常感谢！

不要让空间尺度(1000多个设备)误导你的计算和/或存储规模。对于任何主流DBMS来说，每秒几十个35字节的插入是一项微不足道的工作，甚至可以在低端硬件上运行。同样，每月1.42亿条记录仅为每月1~10千兆字节的存储量，没有任何压缩，包括索引。

在您的问题评论中，您说：

"It's all about reliability, scalability and speed. It's very important that the solution scales easily (MongoDB autosharding?) just throwing in more nodes, and the speed is also very important

可靠性？任何主流DBMS都可以保证这一点(假设你的意思是它不会破坏你的数据，而且它不会崩溃 - 请参阅我对这个答案底部的CAP定理的讨论)。速度？即使使用一台机器，这个工作量的10~100倍也不应成为问题。可扩展性？按照目前的速度，全年的数据，未压缩，甚至完全索引，很容易适应100千兆字节的磁盘空间(同样，我们已经确定插入速率不是问题)。

因此，我没有看到任何明确需要像NoSQL，甚至是分布式数据库这样的奇特解决方案 - 像MySQL这样简单，旧的关系数据库就可以了。如果您担心故障转移，只需在主从配置中设置备份服务器。如果我们说的是当前比例的100或1000倍，则仅基于数据收集设备的ID水平分区几个实例(即{partition index} = {device id} modulo {分区数})。

请记住，离开关系数据库世界的安全和舒适范围意味着放弃其代表性模型和丰富的工具集。这将使您的"复杂数据挖掘"变得更加困难 - 您不仅需要将数据放入数据库，还需要将其解决。

所有这些，MongoDB和CouchDB的部署和使用都非常简单。它们也非常有趣，并且会让你对任何人都更具吸引力(不仅仅是程序员 - 高管！)。

常见的是，在你建议的三种NoSQL解决方案中，Cassandra是高插入量的最佳选择(当然，相对而言，我认为你没有高插入量 - 这是专为Facebook设计的) ;这与更难以合作相对应。因此，除非你有一些你没有提到的奇怪要求，否则我建议不要使用它。

如果您积极参与NoSQL部署，您可能需要考虑CAP定理。这将帮助您在MongoDB和CouchDB之间做出决定。这是一个很好的链接：http：//blog.nahurst.com/visual-guide-to-nosql-systems。这完全归结为"可靠性"的含义：MongoDB交换可用性以保持一致性，而CouchDB交换可靠性的一致性。 (Cassandra允许您通过指定必须为写入/读取成功写入/读取的服务器数量来细化这种权衡;更新：现在，CouchDB，BigCouch也是如此！非常令人兴奋...)

祝你的项目好运。

答案的大部分取决于你收集后想要用它做什么。存储大量数据很简单：只需将其存入日志文件，无需数据库。另一方面，如果您想对其执行复杂的分析和数据挖掘，那么数据库会很有帮助。

接下来的问题是你要做什么样的分析。是否会对具有特定属性的数据子集执行，仅限最后一小时/每天/每周/月，数据是否可以聚合或以某种方式预先计算？换句话说：您是否需要以收集的形式访问整个数据集？如果数据太老而无法存档，您能将数据归档吗？您可以聚合数据并对聚合进行分析吗？

根据我使用广告分析(收集有关广告曝光的数十亿个数据点)的经验，聚合是关键。您收集原始数据，对其进行清理，然后将其放入MongoDB，Cassandra甚至MySQL等数据库中，以便进行更新和查询。然后定期聚合数据并将其从数据库中删除(但归档原始数据，以后可能需要它)。

聚合实质上会询问您要询问的有关数据的所有问题，并将其保存在一个表格中，以便于检索特定问题的答案。假设您想知道一周中哪一天拥有最多的X.这个天真的实现是将所有记录的信号保存在一个巨大的表中，并进行查询，将所有具有X的行相加。作为收集的数量信号增长此查询将花费更长时间。没有任何索引，分片或优化将有助于此。相反，每天/每小时/每分钟(取决于确切的使用案例以及您的报告需要的最新情况)，您可以查看您记录的新信号，并且每增加一个X，您就会增加计数器，以跟踪记录的数量星期一，如果星期一是星期二，星期二是星期二，等等。这样你以后可以检索一周中每一天的计数并进行比较。对所有想要回答的问题执行此操作，然后从数据库中删除信号(但同样，保留原始数据)。

您记录聚合的数据库类型可以与存储传入信号的数据库类型相同，但它不需要非常花哨。它将存储代表特定答案的键，以及通常只是数字的值。

在旧学校数据仓库中说出存储传入信号的数据库称为OLTP(用于在线事务处理)，存储聚合的数据库称为OLAP(用于在线分析处理)。 OLTP针对插入进行了优化，OLAP针对查询进行了优化。这些术语很古老，当人们听到它们时，他们倾向于立即思考SQL和星际事件以及所有这些。也许我不应该使用它们，但它们是方便的术语。

无论如何，对于OLTP，您需要快速插入数据的东西，但也需要支持索引数据和搜索内容的东西。数据库可以完成聚合，它可以完成求和和查找最大值和最小值的一半工作。我非常喜欢MongoDB，因为它很容易设置和使用。我使用的数据往往是杂乱的，并非所有项目都具有相同的属性集，因此Mongo的宽松无模式是一个福音。另一方面，你的数据听起来更加统一，所以Mongo可能不会给你带来多少好处。不过，不要忽略那些旧的关系数据库。如果你要进行大量的求和等等，那么SQL就很棒了，这就是它的基础。

对于OLAP而言，更简单的工作方式，就是您需要的键值存储。我使用Redis因为它也很容易使用和设置。它还允许您存储超过标量值，这很方便。有时您的值实际上是一个列表或散列，在大多数键值存储中，您必须对这些值进行编码，但Redis本身处理它。 Redis的缺点是你无法进行查询("就像给我所有具有Y值的行")，你必须自己保留索引到你的数据。另一方面，由于所有问题的答案都已预先计算好，所以您不需要索引，所有您需要做的就是通过问题定义的键来查找答案。对于上面的问题，一周中的哪一天拥有最多的X，你可以查看星期一，星期二等X工作的数量。也许你已将它们存储为X：星期一，X：星期二等。

总结：MongoDB和Redis对我很有用。我不认为MongoDB对你的用例非常好，相反我认为你实际上可能从传统的SQL数据库中获益更多(但这取决于，如果你的数据非常简单，你可以一直使用Redis)。最重要的是不要错误地认为您需要将数据存储在一个数据库中并永久保存。聚合和丢弃旧数据是关键。

好。

CouchDB非常可靠，具有出色的耐用性，并且您将体验到非常低的CPU负载。它也非常适合在多个节点之间进行复制，无论是按需还是连续。

由于它的复制功能和RESTful API(它使用HTTP作为其API)，您可以使用成熟的工具轻松地水平扩展。 (用于反向代理的Nginx或Apache，HTTP负载平衡器等)

您可以在JavaScript中编写map / reduce函数来预先计算查询。结果在磁盘上逐步建立，这意味着每个信号只需要计算一次。换句话说，查询可以非常快，因为它只需要对自上次运行查询以来记录的信号数据进行计算。

CouchDB交换磁盘空间以提高性能，因此您可以使用大量磁盘空间。如果您正确实施它们，您的查询可以快速闪存并节省磁盘空间。

试试CouchDB吧。

看看为什么大型强子对撞机科学家在BBC上使用CouchDB和CouchDB作为容错，可扩展，多数据中心键值存储

~3000信号/分钟= 50次写入/秒，这些系统中的任何一个都能够轻松处理。

但是，随着您的数据集大于内存，Cassandra可能会发挥最佳效果，而Hadoop集成将有助于您的数据挖掘。

您正在寻找可以允许"快速"写入(数据保留在磁盘上)的数据存储，并且数据挖掘将在稍后阶段发生(这是READ周期)。此外，考虑到您所说的数字，事实证明您每天将收集所有159MB的信息，或每月约5GB。

在这种情况下，为什么不看看Redis。

您可以随时归档每日Redis数据文件，稍后再参考(如果您担心加载5GB或更大的RAM空间，那么您的归档可能是一种解决方法)

Redis相当快，基于该网站上发布的数字。
希望这可以帮助。
基兰

那么您是将数据存储在中央数据库中以进行数据挖掘？没有在线交易处理？

我不认为MongoDB在耐用性方面做得很好。请参见http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of。

也许你可以使用分析db Infobright，它有一个社区版：http：//www.infobright.org/？

如果你喜欢Cassandra的设计从一开始就能够水平扩展，调整一致性和可用性，那么你可能还想看看Riak，它具有类似的功能集但是采用了不同的方法。

我使用过Incanter的MongoDB并且喜欢它。虽然我无法谈论如此大型数据集的速度，但Clojure(Incanter所基于的)在事务管理方面非常可靠。 Incanter还提供了一些出色的分析工具，因此如果您计划分析所有这些数据，MongoDB + Incanter可能是一个强大的组合。