我们正在开发一个非常大的项目，我想知道是否有人可以给我一些有关应该选择哪种数据库后端的建议。
我们的系统由1100个电子设备组成，这些电子设备将信号发送到中央服务器，然后服务器存储信号信息（信号长约35个字节）。这些设备每分钟每分钟将发送大约3个信号的方式，因此，如果我们进行数字编码，则数据库上每天将有4.752.000条新记录，而每月总共有142.560.000条新记录。
我们需要一个快速且可靠的数据库后端。当然，我们需要在该数据库上进行一些复杂的数据挖掘。我们正在对MongoDB / Cassandra / Redis / CouchDB进行一些研究，但是文档网站仍处于早期阶段。
有什么帮助吗？有想法吗？
非常感谢！
Answers:
不要让空间比例（1000多个设备）误导您计算和/或存储比例。每秒几十个35字节的插入量对于任何主流DBMS来说都是微不足道的工作量，即使在低端硬件上运行也是如此。同样，每月1.42亿条记录每月仅约1到10 GB的存储量，没有任何压缩（包括索引）。
在您的问题评论中，您说：
“这完全与可靠性，可伸缩性和速度有关。非常重要的一点是，该解决方案可以轻松地扩展（MongoDB自动分片？），只需添加更多节点即可，而且速度也非常重要。
可靠性？任何主流的DBMS都可以保证这一点（假设您的意思是不会破坏数据，也不会崩溃-请参阅此答案底部有关CAP定理的讨论）。速度？即使只有一台机器，这个工作量的10到100倍也不成问题。可扩展性？以目前的速度，一年中未压缩甚至完全索引的数据很容易容纳100 GB磁盘空间（同样，我们已经确定插入率不是问题）。
因此，我认为没有明显的需求像NoSQL这样的奇异解决方案，甚至是分布式数据库-像MySQL这样的普通的旧关系数据库也就足够了。如果您担心故障转移，只需在主从配置中设置备份服务器即可。如果我们说的是当前规模的100倍或1000倍，则只需根据数据收集设备的ID（即{分区索引} = {设备ID}以{分区数}为模）对几个实例进行水平分区。
请记住，离开关系数据库世界的安全和舒适范围意味着要放弃其表示模型和丰富的工具集。这将使您的“复杂数据挖掘”变得更加困难-您不仅需要将数据放入数据库中，还需要将其取出。
综上所述，MongoDB和CouchDB非常易于部署和使用。它们也非常有趣，它将使您对许多人（不仅仅是程序员-执行人员！）也更具吸引力。
共同的看法是，你提出三个NoSQL的解决方案，Cassandra是最好的高容量插入（当然，相对而言，我不认为你有高插入量-这是旨在通过使用Facebook的） ; 与之相比，使用起来更加困难。因此，除非您有未提到的一些奇怪要求，否则我建议您针对其用例。
如果您对NoSQL部署持肯定态度，则可能需要考虑CAP定理。这将帮助您在MongoDB和CouchDB之间做出决定。这是一个很好的链接：http : //blog.nahurst.com/visual-guide-to-nosql-systems。一切都归结为您所说的“可靠性”：MongoDB用可用性来交换一致性，而CouchDB用一致性来交换可用性。（Cassandra允许您通过指定要写入/读取多少服务器才能成功进行写入/读取来完成每个查询的权衡取舍；更新：现在，带有BigCouch的CouchDB也是如此！非常令人兴奋...）
祝您项目顺利。
答案很大程度上取决于收集后您要如何处理。存储大量数据很容易：只需将其复制到日志文件中，无需数据库。另一方面，如果要对其执行复杂的分析和数据挖掘，则数据库很有用。
下一个问题是您要进行哪种分析。是否仅对具有最后一个小时/天/周/月的具有特定属性的数据子集执行数据，可以对数据进行汇总或以某种方式进行预先计算？换句话说：您是否需要以收集的形式访问整个数据集？当数据太旧而无法引起兴趣时，您可以归档数据吗？您可以汇总数据并对汇总执行分析吗？
根据我在广告分析方面的经验（收集有关广告展示次数的数十亿个数据点），聚合是关键。您收集原始数据，对其进行清理，然后将其放入MongoDB，Cassandra甚至MySQL之类的数据库中，以进行更新和查询。然后，您定期聚合数据并将其从数据库中删除（但存档原始数据，以后可能需要）。
汇总实质上会询问您要询问的有关数据的所有问题，并将其保存为易于检索特定问题答案的格式。假设您想知道一周中的哪一天中X最多。最简单的实现是将所有记录的信号保存在一个巨大的表中，并执行查询以对所有具有X的行求和。信号增长此查询将花费越来越长的时间。进行任何索引，分片或优化都不会帮助您。取而代之的是每天/每小时/分钟（取决于确切的用例以及您的报告需要更新的时间），而是查看记录的新信号，并且每增加X，您就会增加一个计数器来跟踪多少X是星期一，如果是星期一，则是星期二，如果是星期二，依此类推。这样，您以后便可以检索一周中每一天的计数并进行比较。对您希望能够回答的所有问题执行此操作，然后从数据库中删除信号（但再次保留原始数据）。
记录聚合的数据库类型可以与存储传入信号的数据库类型相同，但是不必太花哨。它将存储代表特定答案的键以及通常只是数字的值。
在老式的数据仓库中，您将输入信号存储在其中的数据库称为OLTP（用于在线事务处理），而将聚合数据存储在其中的数据库称为OLAP（用于在线分析处理）。OLTP针对插入进行了优化，而OLAP针对查询进行了优化。这些术语很古老，当人们听到它们时，他们往往会立即想到SQL和starchemas等。也许我不应该使用它们，但是它们是方便的术语。
无论如何，对于OLTP，您需要可以快速插入数据的东西，但是还需要支持索引数据和搜索内容的东西。数据库对汇总和查找最大值和最小值进行了一半的工作，极大地帮助了聚合。我真的很喜欢MongoDB，因为它很容易设置和使用。我使用的数据往往比较混乱，并且并非所有项目都具有相同的属性集，因此Mongo宽容的无模式性是一个福音。另一方面，您的数据听起来更加统一，因此Mongo可能不会给您带来太多好处。不过，请不要忽视良好的旧关系数据库。如果您要进行很多求和，等等，那么SQL很棒，这就是它的基础。
对于OLAP，更简单的方法是使用键值存储。我使用Redis是因为它也很容易使用和设置。它还使您可以存储比标量值更多的数据，这很方便。有时，您的值实际上是大多数键值存储中的列表或哈希，因此您必须对这些值进行编码，但是Redis本机处理它。Redis的缺点是您无法执行查询（例如“为我提供所有具有Y值的行”），您必须自己保留数据索引。另一方面，由于所有问题的答案均已预先计算，因此您不需要太多索引，您所需要做的就是通过问题定义的键查找答案。对于上面的问题，您应该在一周中的哪一天X，星期一，星期二等查询X个工作。
结论：MongoDB和Redis对我来说很棒。我认为MongoDB对于您的用例不是很好，相反，我认为您实际上可能会从传统的SQL数据库中受益更多（但这取决于您，如果您的数据确实很简单，则可以一直使用Redis）。最重要的是不要误以为您需要将数据保存在一个数据库中并永久保存。聚合和丢弃旧数据是关键。
CouchDB非常可靠，具有出色的耐用性，您将遇到非常低的CPU负载。它在按需或连续复制多个节点之间的复制方面也很出色。
凭借其复制功能和RESTful API（它的API使用HTTP），您可以使用成熟的工具轻松地水平扩展。（Nginx或Apache用于反向代理，HTTP负载均衡器等）
您可以使用JavaScript编写map / reduce函数来预先计算查询。结果在磁盘上逐步建立，这意味着每个信号只需要计算一次。换句话说，查询实际上可以很快，因为它只需要对自上次运行查询以来记录的信号数据进行计算。
CouchDB将磁盘空间用于性能交换，因此您可以期望使用大量磁盘空间。如果正确实施查询，查询可能很快，并节省了磁盘空间。
因此，您要将数据存储在中央数据库中以进行数据挖掘吗？没有在线交易处理？
我不认为MongoDB在持久性方面做得很好。参见http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of。
也许您可以使用Analytics db Infobright，它具有社区版本：http : //www.infobright.org/？
您正在寻找一个可以进行“快速闪电式”写入（数据持久存储在磁盘上）的数据存储，而数据挖掘将在稍后的阶段（这是READ周期）进行。另外，考虑到您陈述的数字，事实证明您每天将收集全部159MB信息，或每月大约5GB。
在这种情况下，为什么不看Redis。
您始终可以存档每日Redis数据文件，并在以后进行引用（如果您担心要加载5GB或更大的RAM空间，那么此存档可能是一种解决方法）
根据该站点上发布的数字，Redis相当快。希望这可以帮助。基兰
我使用过Incanter的MongoDB，并且喜欢它。尽管我不能说这么大的数据集的速度，但是Clojure（Incanter所基于的）在事务管理方面非常可靠。Incanter还提供了一些出色的分析工具，因此，如果您打算分析所有这些数据，MongoDB + Incanter可能是一个强大的组合。