用于存储来自移动传感器(全球定位系统、加速计等)的用户数据的SQL vs NoSQL数据库

Question

我正在做一个项目，我需要存储来自不同类型的移动传感器，智能手表等的数据，如GPS，加速计，心电图，心率传感器，我的任务是首先存储用户数据，然后与他们一起工作，我不确定我应该使用哪个数据库。非常感谢。

Answer 1

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

一个聊天应用大约有50/50的读/写。现在，假设我们的db是一个MySQL。在生产环境中，我们将创建一个主/从，因为这是MySQL支持的拓扑。在某一时刻，我们会遇到性能问题，而我们的瓶颈将会变成主控。为什么？因为只有主机写，从机跟随。db _ oplog中的每个改变都被发送到从机以进行复制。您可以告诉master只对其进行写操作，并返回success和slaves进行异步更新，但是这样做会导致读取不一致，或者您可以告诉整个集群复制写入操作，然后返回write success响应，但这更是一个性能瓶颈吗？我演示了什么？您必须根据您的应用程序需求进行权衡。它被称为CAP定理。它指出，您最多只能选择3个字母中的2个，以牺牲其余字母为代价。上限-一致性、可用性、分区容忍度。

现在，回到SQL/NoSQL。

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

LOCAL_QUORUM = (replication_factor/2) + 1 

因此，对于3个节点，每次读/写都必须通过协调器(决定将读/写发送到何处的节点)+传递由本地quorum配置定义的2个节点。

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

总结：

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

如果您不关心写入，并且需要快速读取，请选择读取速度快+一致性好的数据库->

如果您需要transactions -> SQL类型db

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