Database 用于存储移动传感器（GPS、加速度计等）用户数据的SQL vs NoSQL数据库

我正在做一个项目，我需要存储来自不同类型的移动传感器、智能手表等的数据，比如GPS、加速度计、ECG、心率传感器，我的任务是先存储用户数据，然后再处理他们，我不确定我应该使用什么样的数据库。非常感谢。

这取决于您的应用程序需要。 例如，让我们看一个聊天应用程序，以便更好地了解要选择的db

一个聊天应用程序有大约50/50的读/写操作。现在，假设我们的数据库是MySQL。进入生产阶段，我们将创建一个主/从，因为这是MySQL支持的拓扑。在某个时候，我们会遇到性能问题，而我们的瓶颈将成为主要问题。为什么？因为只有主人写作，奴隶跟随。db oplog中的每个更改都会传输到要复制的从属设备。您可以告诉主机只对其进行写入并返回success，而从机则返回update async，但是这样，您的读取将不一致，或者您可以告诉整个集群复制写入，然后返回写入成功响应，但这更像是一个性能瓶颈？我演示了什么？您必须根据应用程序需要进行权衡。这被称为CAP定理。它指出，您最多只能选择3个字母中的2个，以牺牲其余字母为代价。CAP—一致性、可用性、分区容差

现在，回到SQL/NoSQL

SQL数据库允许事务处理，就像合同上说的，要么提交我给你的所有内容，要么什么都不提交。 NoSQL数据库为您提供了以不同方式排列数据的机会，但它们不提供事务。相反，它们各自以不同的方式处理读/写操作。例如，对于我们的聊天应用程序，我会选择一个非常快速的写db，比如Cassandra（工作方式类似于只附加日志）。Cassandra的节点都是平等的，没有主或从配置，这意味着每个节点都接受读/写操作。这很好，但我仍然存在读取不一致的问题。这个问题可以通过法定人数来部分解决。基本上，这意味着，我更喜欢在我的应用程序数据库中进行一致的读取，而不是可用性，这是完全好的，仍然比MySQL快得多。 Cassandras默认复制因子，对于X节点，为X。对于3个节点，复制因子将为3，这意味着所有数据将被复制3次，本地仲裁（必须响应操作的节点数）将为3/2+1->2

LOCAL_QUORUM = (replication_factor/2) + 1 

因此，对于3个节点，每个读/写必须通过协调器（决定将读/写发送到何处的节点）+通过本地仲裁配置定义的2个节点

以上只是Cassandra的一个示例尝试，它是一个非常复杂的数据库，因为它是关于数据库的主题

总之：

如果您需要快速写入+快速读取->您必须在一致性、高可用性和分区容差+适当的数据库之间做出决定

如果您不关心写操作，需要快速读取->读取速度快的数据库+一致性

如果需要事务->SQL类型数据库

---

最后但并非最不重要的一点是，很大程度上取决于您如何对数据和组件的相互通信进行建模。

当然，我可以没完没了地谈论报告+如何根据报告进行构建，但这可能超出了本文的范围。