我仍然不能实时地说明nosql是如何有益的，而我们在传统的rdbms中也有索引。如果有人能建议列式数据库在实际应用中的优势，特别是在使用结构化、半结构化或非结构化数据方面。
u1ehiz5o1#
很大程度上，这取决于您希望数据存储做什么。如果您希望能够扩展以满足存储或操作需求，rdbms只能做到这一点。它涉及到如何扩展以满足需求。rdbms实际上只能垂直扩展。也就是说，添加更多的ram，添加更多的磁盘等等。分布式（nosql）数据库允许您添加更多的机器示例，从而使扩展更容易。这称为水平缩放。下面是一个使用cassandra的示例：假设我有一个3节点的集群，我的keyspace（数据库）也配置了3的复制因子（rf）。这意味着每个节点负责100%的数据。我加载数据，它占用了100gb的磁盘空间（在每个节点上）。现在，虽然我的集群中可能总共有300gb的数据，但我的数据的单个副本是100gb。所以我的产品团队来找我，说他们需要将他们拥有的数据量翻一番。我知道我用200gb的驱动器构建了他们的3节点集群。如果我什么都不做，这些驱动器将几乎填满（如果他们不这样做，他们就不会留下更多的空间来做其他事情）。现在由我来扩展集群以满足他们的空间需求。我将首先向集群添加3个新节点（总共6个节点），但我将把rf保留为3。这使得每个节点负责50%的数据，即50gb。当我的产品团队加载更多的数据以满足他们的“加倍”需求时，每个节点都应该上升到100gb左右。数据的单个副本现在是200gb。但由于每个节点负责50%，每个200gb驱动器仍然只有100gb。示例2：假设上面有6个节点的集群能够支持每秒10000次操作（ops）的操作负载。我的产品团队又来找我，说假期他们的项目需要支持20000个运营。由于当前集群只能支持其中的一半，因此在高吞吐量下会阻塞，一个或多个节点可能会崩溃。随着cassandra线性扩展，实现这一点的方法是（再次）将集群的大小增加一倍。所以我把它从6个节点增加到12个节点，同时保持我的射频为3。在运行了一些性能测试之后，他们验证了它确实可以支持20000次操作。由于我的数据的单个拷贝是200gb，所以总的数据占用空间仍然是600gb。有了12个节点，每个节点现在只负责25%的数据，即50gb。因此，可扩展性是优势所在。但是数据建模怎么样？分布式数据库建模的主要思想有两个方面：建立一个表结构，这个表结构通过键控可以很好地分布。我们不希望每个节点上的数据量不均匀。在表上构建键，使其符合查询要求。nosql数据库的缺点之一是查询模式受到限制。为了减少网络时间，您需要确保查询可以由单个节点提供服务。这通常意味着使用自然密钥，因为这些密钥更符合您对数据的要求。代理键（alpha、numeric或两者）分布良好，但对查询并不真正有用。在我的系统中，用户“bob jones”可能是id“3582346556230”。但是，当我想查询bob的数据时，我可能永远不会希望通过“3582346556230”来请求它，因为这对应用程序或使用数据的上下文没有任何意义。另外，您希望数据具有结构化。非结构化数据是不可查询的数据。就这么简单。如果您希望非结构化数据是可查询的，则需要解析出其标识方面以用作键。你不想“搜索”或逃跑 SELECT * FROM 查询。nosql数据库中的全表扫描比rdbms数据库中的全表扫描更消耗资源，因为它们必须检查每个节点，对副本进行排序，因此需要额外的网络时间。nosql数据库使您能够进行扩展（针对数据或需求的增加）。但需要注意的是，它们的可伸缩性可能会使某些事情（rdbms可能擅长的）变得比您习惯的更困难。
SELECT * FROM
dgsult0t2#
rdbms中的r，relational是mongo缺少的最大的东西。几乎没有办法让数据库了解不同表集合中的条目是如何相互关联的。RDBMS的一大优点是能够定义数据库将强制执行的约束，最典型的是外键约束，它确保一个表中的id引用另一个表中的现有id。数据库要能够执行这些约束的一个要求显然是，一切都需要经过一个真相来源，并且需要有一个中心实体交叉检查数据；它不能分散，因为两个不同的主要数据源之间的差异可能导致数据不一致。在mongo中，每个数据块都是非常独立的。它不引用数据库以任何方式强制执行的其他条目。mongo也有弱到没有acid的保证，这意味着对种族条件插入或更新几乎没有保护。一句话：mongo在数据一致性方面没有什么保证，主要是将这些问题转移到应用层。这使得它的工作更加分散。e、 g.扩展mongo的一个好方法是拥有多个辅助服务器，这些服务器复制一个主服务器进行只读访问。无法保证主数据集和辅助数据集在任何给定的时间都是同步的，写入主数据集的数据可能需要几秒钟才能流到辅助数据集。但这允许您拥有几乎无限数量的辅助只读服务器，这对于在高读取负载下扩展数据库非常有用。mongo处理集群的方式也允许它有很高的正常运行时间，因为如果服务器宕机，集群会自动将自己重新组织为主集群和辅助集群。这甚至允许滚动维护，而无需任何客户端停机。在编写过程中不必强制执行复杂的约束或事务一致性，还允许更快速地向数据库写入。同样，代价是允许不一致的数据。这就是为什么大多数编写几乎意味着原子式地更新集合中的单个文档，而不保证其他文档，这与跨多个表的rdbms事务性更新不同。我不建议mongo存储像财务分类账这样的东西，因为财务分类账在很大程度上依赖于事务性保证的一致性。然而，像twitter这样的东西是一个完美的例子：许多独立的数据片段必须被大量的客户端读取。
2条答案
按热度按时间u1ehiz5o1#
很大程度上，这取决于您希望数据存储做什么。如果您希望能够扩展以满足存储或操作需求，rdbms只能做到这一点。
它涉及到如何扩展以满足需求。rdbms实际上只能垂直扩展。也就是说，添加更多的ram，添加更多的磁盘等等。分布式（nosql）数据库允许您添加更多的机器示例，从而使扩展更容易。这称为水平缩放。
下面是一个使用cassandra的示例：
假设我有一个3节点的集群，我的keyspace（数据库）也配置了3的复制因子（rf）。这意味着每个节点负责100%的数据。我加载数据，它占用了100gb的磁盘空间（在每个节点上）。现在，虽然我的集群中可能总共有300gb的数据，但我的数据的单个副本是100gb。
所以我的产品团队来找我，说他们需要将他们拥有的数据量翻一番。我知道我用200gb的驱动器构建了他们的3节点集群。如果我什么都不做，这些驱动器将几乎填满（如果他们不这样做，他们就不会留下更多的空间来做其他事情）。
现在由我来扩展集群以满足他们的空间需求。我将首先向集群添加3个新节点（总共6个节点），但我将把rf保留为3。这使得每个节点负责50%的数据，即50gb。当我的产品团队加载更多的数据以满足他们的“加倍”需求时，每个节点都应该上升到100gb左右。数据的单个副本现在是200gb。但由于每个节点负责50%，每个200gb驱动器仍然只有100gb。
示例2：
假设上面有6个节点的集群能够支持每秒10000次操作（ops）的操作负载。我的产品团队又来找我，说假期他们的项目需要支持20000个运营。由于当前集群只能支持其中的一半，因此在高吞吐量下会阻塞，一个或多个节点可能会崩溃。
随着cassandra线性扩展，实现这一点的方法是（再次）将集群的大小增加一倍。所以我把它从6个节点增加到12个节点，同时保持我的射频为3。在运行了一些性能测试之后，他们验证了它确实可以支持20000次操作。由于我的数据的单个拷贝是200gb，所以总的数据占用空间仍然是600gb。有了12个节点，每个节点现在只负责25%的数据，即50gb。
因此，可扩展性是优势所在。但是数据建模怎么样？分布式数据库建模的主要思想有两个方面：
建立一个表结构，这个表结构通过键控可以很好地分布。我们不希望每个节点上的数据量不均匀。
在表上构建键，使其符合查询要求。
nosql数据库的缺点之一是查询模式受到限制。为了减少网络时间，您需要确保查询可以由单个节点提供服务。
这通常意味着使用自然密钥，因为这些密钥更符合您对数据的要求。代理键（alpha、numeric或两者）分布良好，但对查询并不真正有用。在我的系统中，用户“bob jones”可能是id“3582346556230”。但是，当我想查询bob的数据时，我可能永远不会希望通过“3582346556230”来请求它，因为这对应用程序或使用数据的上下文没有任何意义。
另外，您希望数据具有结构化。非结构化数据是不可查询的数据。就这么简单。如果您希望非结构化数据是可查询的，则需要解析出其标识方面以用作键。你不想“搜索”或逃跑
SELECT * FROM查询。nosql数据库中的全表扫描比rdbms数据库中的全表扫描更消耗资源，因为它们必须检查每个节点，对副本进行排序，因此需要额外的网络时间。nosql数据库使您能够进行扩展（针对数据或需求的增加）。但需要注意的是，它们的可伸缩性可能会使某些事情（rdbms可能擅长的）变得比您习惯的更困难。
dgsult0t2#
rdbms中的r，relational是mongo缺少的最大的东西。几乎没有办法让数据库了解不同表集合中的条目是如何相互关联的。RDBMS的一大优点是能够定义数据库将强制执行的约束，最典型的是外键约束，它确保一个表中的id引用另一个表中的现有id。
数据库要能够执行这些约束的一个要求显然是，一切都需要经过一个真相来源，并且需要有一个中心实体交叉检查数据；它不能分散，因为两个不同的主要数据源之间的差异可能导致数据不一致。
在mongo中，每个数据块都是非常独立的。它不引用数据库以任何方式强制执行的其他条目。mongo也有弱到没有acid的保证，这意味着对种族条件插入或更新几乎没有保护。一句话：mongo在数据一致性方面没有什么保证，主要是将这些问题转移到应用层。这使得它的工作更加分散。
e、 g.扩展mongo的一个好方法是拥有多个辅助服务器，这些服务器复制一个主服务器进行只读访问。无法保证主数据集和辅助数据集在任何给定的时间都是同步的，写入主数据集的数据可能需要几秒钟才能流到辅助数据集。但这允许您拥有几乎无限数量的辅助只读服务器，这对于在高读取负载下扩展数据库非常有用。
mongo处理集群的方式也允许它有很高的正常运行时间，因为如果服务器宕机，集群会自动将自己重新组织为主集群和辅助集群。这甚至允许滚动维护，而无需任何客户端停机。
在编写过程中不必强制执行复杂的约束或事务一致性，还允许更快速地向数据库写入。同样，代价是允许不一致的数据。这就是为什么大多数编写几乎意味着原子式地更新集合中的单个文档，而不保证其他文档，这与跨多个表的rdbms事务性更新不同。
我不建议mongo存储像财务分类账这样的东西，因为财务分类账在很大程度上依赖于事务性保证的一致性。然而，像twitter这样的东西是一个完美的例子：许多独立的数据片段必须被大量的客户端读取。