数据模型在所谓的“ NoSQL”数据库中对可伸缩性和性能有多大影响？

如果不带CAP定理（一致性，可用性，分区：选择两个），就永远无法谈论所谓的“ NoSQL”数据库。如果您不得不说，在MongoDB（分区，一致性）和CouchDB（可用性，分区）之间，首先需要考虑的是“我需要正确的数据还是需要一直访问？”。

这些新的数据库中取得进行分区。但是，如果我不这样做怎么办？如果我只是想拥有一个键/值，列，文档，任何数据库而不是一个关系数据库，并且只创建一个服务器实例而不进行分片，那该怎么办呢？在那种情况下，我既没有可用性又没有一致性吗？MongoDB不需要复制任何内容，因此可以使用。而且CouchDB将只有一个数据源，因此它将非常一致。

因此，那意味着在那种情况下，MongoDB和CouchDB在用例方面几乎没有区别？好吧，当然除了性能，API和其他功能外，但这更像是在PostgreSQL和MySQL之间进行选择，而不是拥有两个根本不同的要求。

我在这里吗？是否可以通过不创建多个实例将AP或CP数据库更改为AC数据库？还是我缺少什么？

我们反过来问这个问题。如果我使用一个关系数据库，比如说MySQL，并将其置于主/从配置中，该怎么办？我不使用ACID事务如果我要求立即将所有写入同步到从属服务器，那岂不是使其成为CP数据库吗？而且，如果我将其同步了一些预定义的时间间隔，并且客户端是否从从属设备读取过时的数据也没关系。那不是将它变成AP数据库吗？这是否意味着如果我放弃ACID合规性，仍然可以对部分数据库使用关系模型？

本质上：在CAP定理中，您准备放弃的可扩展性要比基础数据模型还重要吗？具有列，文档，键值等内容是否可以增强关系模型的可伸缩性？我们可以设计一个完全为分区容忍度设计的关系数据库吗？（也许它已经存在）。我们可以使NoSQL数据库ACID兼容吗？

抱歉，它有很多问题，但是最近我阅读了很多有关NoSQL数据库的信息，在我看来，使用它们的最大好处是，它们更适合数据的“形状”，而不仅仅是分区CAP并放弃了ACID合规性。毕竟，并不是每个人都有太多数据需要分区。在我甚至考虑对数据进行分区之前，不使用关系模型是否会对性能/可伸缩性有所帮助？

即使您不分片数据，使用NoSQL数据库也会增强可伸缩性吗？好吧，让我们定义可伸缩性。如果在涉及数据库/后端系统时将可伸缩性称为“垂直伸缩”和“水平伸缩”，其中水平伸缩是对数据进行分片，那么这将成为一个琐碎的问题，因为答案绝对是“否”，因为您留下了唯一的选择是垂直扩展（即获得更好的硬件）。但是，如果您在广义上是指应用程序的灵活性，数据值等方面的可伸缩性，那么这是一个完全不同的问题，有许多答案。就像您提到的那样，它通常取决于您对数据的处理方式以及如何存储数据。让我在这里以在大多数情况下您仍然应该使用RDBMS且NoSQL应该填补适当位置的声明作为开头。以下是对特定实例的描述，在特定实例中，NoSQL数据库在满足特定要求的情况下将更为有益，而我们可以忽略水平缩放。

以创建一个类似于google drive，dropbox或box的云文件存储系统的想法为例，但是您决定使用虚拟化文件系统会更有益，而不是使用实际的文件系统。现在您遇到了一个问题，因为您的数据模型突然变成了RDBMS中效率极低的树形结构（尽管事实是所有内容都被索引了）。因为现在您有了一个包含名称，用户和父项的3列表。User是用户表的外键，Parent是自引用可为空的外键（由于根目录中没有父级，因此为空）。那么主键是什么？在这种情况下，它是所有列上的复合键...这突然使Parent成为我们最大的敌人。

现在想想如何将其放入某种形式的文档存储中？您不必处理数据，而可以使用它并将其存储为树结构，从而减少了开发时间并降低了维护成本。如果您正在降低成本，那不就意味着另一种可扩展性吗？另外，在这种情况下，您将从头开始正确地创建系统，这应该为应用程序本身提供更大的灵活性。目前，我正在使用MongoDB在单个服务器上运行此服务器，正如您所解释的，它为我提供了一个可用的，一致的模型，该模型与查看MySQL或Postgres的区别没有太大不同。

至少使用MongoDB，您可以定义要与一个查询进行通信才能与之通信的服务器数量，因此，是的，如果您告诉所有查询与所有服务器实例进行通信，则可以将其转换为“一致的，可用的”模型。

因此，我认为您有权利，因为数据存储方式将带来巨大的好处。在某些关系模型中，有些东西并不能很好地适合于其他模型（作为另一个简短的示例，Amazon使用某种形式的Graph数据库作为产品的推荐引擎）。

我是否正确理解您的问题？

编辑：更多的数据会减慢速度吗？是。它会减慢多少速度？老实说，我没有足够的经验来给出适当的答案。键/值：本质上是一个查找表，其中包含与查找键关联的大量数据。这将真的非常快，因为您只能通过按键查找内容。列/族：本质上是结构更丰富的键/值存储。您只能基于Column进行查询，因此这也应该非常快。文档：聚合样式架构。在这里，您将希望将类似的数据汇总在一起。对于这种数据库，可以进行非规范化，并且可以预期。根据您要执行大量写入还是读取操作，您可以组织数据，以便将数据分布在多个分片上以分配写入操作或读取操作（请注意，您可以创建一种混合方法，这两种方法均对两者都有利，但通常需要为一个或另一个选择优化）图：此图的优势在于它可以非常快速地创建和删除关系。如果您有一些需要在数据之间更改关系的数据（请考虑某种形式的推荐引擎），则应使用此数据。

在这些数据库中的任何一个中存储数据的方式都会影响性能（类似于以下事实：如果在某些RDBMS中错误地存储数据，将会影响性能）。因此，希望使这一点更加清楚：您需要知道应该使用哪个数据库系统以及如何在该数据库系统中存储数据。