我们正在开发一个非常大的项目，我想知道是否有人可以就我们应该选择什么数据库后端给我一些建议。
我们的系统由 1100 个电子设备组成，这些电子设备向中央服务器发送信号，然后服务器存储信号信息（信号长约 35 个字节）。这些设备每分钟发送大约 3 个信号，所以如果我们做数字，数据库中每天有 4.752.000 条新记录，每月总共有 142.560.000 条新记录。
我们需要一个快速且可靠的数据库后端。当然，我们需要对该数据库进行一些复杂的数据挖掘。我们正在对 MongoDB/Cassandra/Redis/CouchDB 进行一些研究，但是文档网站仍处于早期阶段。
有什么帮助吗？想法？
非常感谢！
不要让空间尺度（1000 多个设备）在计算和/或存储尺度上误导您。每秒几十个 35 字节的插入对于任何主流 DBMS 来说都是微不足道的工作负载，即使在低端硬件上运行也是如此。同样，每月 1.42 亿条记录仅是每月 1~10 GB 的存储量，没有任何压缩，包括索引。
在您的问题评论中，您说：
“这一切都与可靠性、可扩展性和速度有关。解决方案易于扩展（MongoDB 自动分片？）非常重要，只需投入更多节点，速度也非常重要
可靠性？任何主流 DBMS 都可以保证这一点（假设您的意思是它不会破坏您的数据，也不会崩溃——请参阅我在此答案底部对 CAP 定理的讨论）。速度？即使是单机，10~100倍这个工作量应该不是问题。可扩展性？按照目前的速度，一整年的数据，未经压缩，甚至完全索引，都可以轻松容纳在 100 GB 的磁盘空间内（同样，我们已经确定插入速度不是问题）。
因此，我不认为需要像 NoSQL 这样的奇特解决方案，甚至是分布式数据库——一个普通的、旧的关系数据库，如 MySQL 就可以了。如果您担心故障转移，只需在主从配置中设置备份服务器。如果我们谈论的是当前规模的 100 或 1000 倍，只需根据数据收集设备的 ID 水平划分几个实例（即{partition index} = {device id} modulo {number of partitions}）。
请记住，离开关系数据库世界的安全和舒适范围意味着放弃其表示模型和丰富的工具集。这将使您的“复杂数据挖掘”变得更加困难——您不仅需要将数据放入数据库，还需要将其取出。
尽管如此，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 和星型架构等等。也许我不应该使用它们，但它们是方便的术语。
无论如何，对于 OLTP，您需要能够快速插入数据的东西，而且还需要支持索引数据和搜索事物的东西。数据库对聚合有很大帮助，该数据库完成了一半的求和和查找最大值和最小值的工作。我真的很喜欢 MongoDB，因为它很容易设置和使用。我使用的数据往往是杂乱无章的，而且并非所有项目都具有相同的一组属性，因此 Mongo 宽容的无模式是一个福音。另一方面，您的数据听起来更加统一，因此 Mongo 可能不会给您带来那么多好处。不过，不要忽视良好的旧关系数据库。如果你要进行大量的求和等等，那么 SQL 就很棒，这就是它的目的。
对于 OLAP，一些更简单的工作，键值存储就是您所需要的。我使用 Redis 是因为它也很容易使用和设置。它还允许您存储比标量值更多的值，这很方便。有时您的值实际上是一个列表或散列，在大多数键值存储中，您必须对这些值进行编码，但 Redis 会原生处理它。Redis 的缺点是您无法进行查询（“就像给我所有具有此 Y 值的行”），您必须自己保留数据的索引。另一方面，您不需要索引，因为所有问题的答案都已预先计算，您需要做的就是通过问题定义的键查找答案。对于上面的问题，一周中哪一天的 X 最多，您可以查看周一、周二等 X 工作的数量。也许您
总之：MongoDB 和 Redis 非常适合我。我不认为 MongoDB 非常适合您的用例，相反，我认为您实际上可能会从传统的 SQL 数据库中受益更多（但这取决于，如果您的数据真的很简单，您也许可以一直使用 Redis）。最重要的是不要错误地认为您需要将数据保存在一个数据库中并永久保存。聚合和丢弃旧数据是关键。
CouchDB 非常可靠，提供出色的持久性，并且您将体验到非常低的 CPU 负载。它还非常擅长在多个节点之间进行按需或连续复制。
由于其复制能力和 RESTful API（它使用 HTTP 作为其 API），您可以使用成熟的工具轻松地进行水平扩展。（用于反向代理、HTTP 负载均衡器等的 Nginx 或 Apache）
您在 JavaScript 中编写 map/reduce 函数来预先计算查询。结果是在磁盘上逐步建立的，这意味着每个信号只需要计算一次。换句话说，查询可以非常快，因为它只需要对自上次运行查询以来记录的信号数据进行计算。
CouchDB 以磁盘空间换取性能，因此您可以预期会使用大量磁盘空间。如果您正确实施它们，您的查询可以闪电般快速并节省磁盘空间。
~3000 个信号/分钟 = 50 个写入/秒，这些系统中的任何一个都可以轻松处理。
但是，当您的数据集变得比内存大时，Cassandra 可能会工作得最好，而 Hadoop 集成将有助于您的数据挖掘。
因此，您将数据存储在中央数据库中以进行数据挖掘？没有在线交易处理？
我不认为 MongoDB 在持久性方面做得很好。请参阅http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of。
也许您可以使用分析数据库 Infobright，它有一个社区版： http: //www.infobright.org/？
您正在寻找可以允许“闪电般快速”写入（数据持久保存在磁盘上）的数据存储，并且数据挖掘将在稍后阶段发生（这是 READ 周期）。此外，考虑到您陈述的数字，事实证明您每天将收集所有 159MB 的信息，或每月大约 5GB。
在这种情况下，为什么不看看 Redis。
您可以随时归档每日 Redis 数据文件，稍后再参考（如果您担心加载 5GB 或更大的 RAM 空间，那么此归档可能是一种解决方法）
根据该站点上发布的数字，Redis 相当快。希望这可以帮助。基兰
如果您喜欢 Cassandra 的外观，因为它具有从一开始就设计的水平扩展能力、根据可用性调整一致性等，那么您可能还想看看Riak，它具有相似的功能集但方法不同.
我使用过Incanter的 MongoDB并且很喜欢它。虽然我无法用如此大的数据集谈论速度，但 Clojure（Incanter 所基于）在事务管理方面非常可靠。Incanter 还提供了一些很棒的分析工具，所以如果您打算分析所有这些数据，MongoDB + Incanter 可能是一个强大的组合。