SQL或/with Nosql

Question

我正在设计一个具有基本功能的移动应用程序，例如注册、8月、帖子、实时消息等。我认为对于这类工作，Nosql应该更好地工作。但在很长一段时间内，我也想介绍支付交易。由于最终的一致性，NoSql在这里应该是一个问题(我可能错了)。因此，我只能将SQL用于来自Nosql用户数据的带有userid字段的事务。两者兼而有之是一种好做法吗。

我知道我从一开始就可以使用SQL数据库，但我认为基于扩展、分布式数据库等因素，NoSql将是一个很好的选择。

PS:我也是一个软件开发人员，但主要从事机器学习和计算机视觉方面的工作。对数据库没有多大作用。

Answer 1

因此，我只能将SQL用于来自Nosql用户数据的带有userid字段的事务。两者兼而有之是一种好做法吗。

我不认为将两个不同的数据库系统，特别是不同类型的数据库系统(关系数据库管理系统和NoSQL)如此紧密地结合在一起，对于相关的用例是一个好主意。这将被证明是很难管理的，而且很难在数据库系统之间保持一致性(特别是与可能不兼容ACID的NoSQL系统)。

我认为，基于扩展、分布式数据库等因素，NoSql将是一个很好的选择。

RDMBS可以与NoSQL数据库一样扩展。通常，从硬件的角度来看，关系数据库是垂直扩展的，而NoSQL数据库则是水平扩展的，但是一种方法与另一种方法没有内在的好处。也有水平扩展的关系数据库管理系统，就像NoSQL数据库系统能够垂直扩展一样。

从软件的角度来看，随着数据的增长，扩展的性能主要取决于架构师如何创建数据库，而不依赖于所选择的实际数据库系统，因为大多数现代数据库系统能够处理单个逻辑存储单元(例如表或文档)中超过千兆字节的数据记录。

我正在设计一个具有基本功能的移动应用程序，如注册、8月、帖子、实时消息等。

何时选择NoSQL数据库系统而不是关系数据库系统取决于许多因素，我认为这些因素中没有一个主要涉及性能。但是，决定何时选择哪种类型的数据库系统的主要因素之一是基于是否有定义良好的架构的事实。

NoSQL数据库非常适合存储没有具体模式的数据，可以随意/在您控制之外更改结构，或者结构更改的速率超过您作为开发人员在数据层中维护结构的容忍度。听起来您有一定程度的具体模式，因此RDBMS可以为您的用例工作，但您也应该考虑模型的结构是否会频繁变化或超出您的控制范围，如果您作为开发人员不希望管理数据层中的这些更改。

简而言之，当您需要具体地定义数据的结构时，NoSQL数据库是很好的延迟，直到数据在应用程序层中被使用。但是，它们在扩展、分发或性能方面并不是天生的更好。不幸的是，在互联网上有很多关于这方面的误解。

Answer 2

NoSQL涵盖了非常广泛的解决方案，这些解决方案通常只有“不使用SQL作为默认查询语言”。例如，自2018年以来，MongoDB一直支持多文档酸交易，而自MongoDB 4.2 (2019)以来，MongoDB一直支持分片集群中的分布式事务。默认是强一致性(所有从主数据读取和写入)，最终一致性作为可选的读取首选项。MongoDB还支持可选的JSON模式验证，与固定的模式目录相比，这是一种更灵活的方法。

但是，由于您正在设计一个移动应用程序，我认为更重要的需求将来自您的移动用例和您计划支持的平台。如果您的用例包括离线数据使用和本地查询(可能与云同步)，那么需要考虑的解决方案空间比数据库服务器解决方案更广。每个移动O/S通常都有一个本地的持久性解决方案(例如iOS中的核心数据或安卓中的Room )，还有一些跨平台库，比如SQLite (核心数据和空间都是它们的基础)。

还有一些跨平台的解决方案，比如领域 (由MongoDB在2019年收购)，它们提供可选双向云同步的设备持久性(包括模式、事务和关系)。领域SDK是开源的(Apache2.0许可证)，可以用作高性能的本地持久性解决方案，也可以作为移动应用程序与云中中央数据存储同步数据的脱机第一方法的一部分。领域同步使用MongoDB Atlas进行云存储，您还可以选择通过MongoDB驱动程序和工具与数据交互(例如，用于分析或机器学习用例)。领域的云端包括应用服务，如用户身份验证提供者、函数、触发器、GraphQL和静态文件托管。

在选择数据持久性方法之前，我会尝试缩小您的实际需求和预期需求，包括设备上服务和非设备服务。

Answer 3

您可能想看看SchemafreeSQL。它使用sql数据库创建无模式对象存储。您继续像往常一样使用数据库，并根据需要访问Nosql特性。