我仍然无法实时了解nosql是如何有益的，而我们在传统的RDBMS中也有索引。如果有人可以在实际应用中建议柱状数据库的优势，特别是在使用结构，半结构化或非结构化数据方面。
答案 0 :(得分：2)
很大程度上，这取决于您希望数据存储区执行的操作。如果您希望能够扩展以满足存储或操作需求，那么RDBMS只能带您到目前为止。
它可以缩放 以满足需求。 RDBMS实际上只能垂直缩放 。也就是说，添加更多内存，添加更多磁盘等。分布式（NoSQL）数据库允许您添加更多计算机实例，从而使扩展更容易。这称为水平缩放。
以下是使用Cassandra的示例：
假设我有一个3节点集群，我的密钥空间（数据库）也配置了复制因子（RF）3.这意味着每个节点负责100％的数据。我加载了我的数据，它占用了100GB的磁盘空间（在每个节点上）。现在，虽然我的群集中可能总共有300GB的数据，但我的数据的单个副本是100GB。
所以我的产品团队来找我并说他们需要将他们拥有的数据量增加一倍。我知道我用200GB驱动器构建了他们的3节点集群。如果我什么也没做，那些驱动装置就会填满（如果没有，他们就不会留下太多空间）。
现在由我来扩展群集以满足他们的空间需求。我将首先向集群添加3个新节点（总共6个），但我将把RF保留为3.这使得每个节点负责50％的数据，即50GB。当我的产品团队加载更多数据以满足其“倍增”要求时，每个节点应该回升到大约100GB。单个数据副本现在为200GB。但是每个节点负责50％，每个200GB驱动器仍然只有100GB。
示例＃2：
假设具有6个节点的上述群集能够支持每秒10,000次操作的操作负载（操作）。我的产品团队再次来找我，说在节日期间，他们计划需要支持20,000个操作。由于当前群集只能支持其中的一半，因此它会在强烈的吞吐量下窒息，并且一个或多个节点可能会崩溃。
随着Cassandra线性扩展，实现这一目标的方法是（再次）使群集的大小加倍。所以我将它从6个节点增加到12个节点，同时仍然保持我的RF为3.在运行一些性能测试之后，他们验证它确实可以支持20,000个操作。由于我的数据的单个副本为200GB，因此总数据量仍为600GB。有12个节点，每个节点现在只负责25％的数据，或50GB。
因此可扩展性是优势。但是如何建模数据？分布式数据库建模的主要思想是双重的：
NoSQL数据库的一个缺点是您的查询模式受到限制。为了减少网络时间，您需要确保您的查询可以由单个节点提供。
这通常意味着使用自然键，因为它们更符合您对数据的要求。代理键（alpha，数字或两者）分布很好，但对查询不是很有用。用户“Bob Jones”可能在我的系统中是“3582346556230”。但是当我想查询Bob的数据时，我可能永远不想通过“3582346556230”来询问它，因为这对应用程序或使用数据的上下文没有任何意义。
此外，您希望您的数据具有结构。非结构化数据是不可查询的数据。就那么简单。如果您希望非结构化数据可查询，则需要解析其标识方面以用作键。您不想“搜索”或运行SELECT * FROM个查询。 NoSQL数据库中的全表扫描比它们的RDBMS数据库更耗费资源，因为它们必须检查每个节点，对副本进行排序，从而产生额外的网络时间。
NoSQL数据库使您能够扩展（增加数据或需求）。但重要的是要注意它们的可伸缩性可以使某些东西（RDBMS可能擅长），比你习惯的更难。
答案 1 :(得分：1)
RDBMS中的R， r elational ，是Mongo遗漏的最大的东西。几乎没有办法让数据库理解不同表集合中的条目如何相互关联。 RDBMS的一大优势是能够定义数据库将强制执行的约束，最常见的是外键约束，这些约束确保一个表中的id引用另一个表中的现有id。
数据库能够强制执行此类约束的一个要求显然是所有内容都需要经过一个事实来源，并且需要有一个中央实体交叉检查数据;它不能分散，因为两个不同的主要来源之间的差异可能导致数据不一致。
在Mongo中，每个数据blob都非常独立。它不以任何方式引用数据库强制执行的其他条目。 Mongo也有弱到ACID guarantees，这意味着对race condition插入或更新的保护很少。总而言之：Mongo在数据一致性方面几乎没有任何保证，并且主要将这些问题卸载到应用程序层。这使它可以更加分散。
E.g。缩放Mongo的一个好方法是让许多辅助服务器复制主服务器以进行只读访问。无法保证主要和辅助节点在任何给定时间都处于同步状态，写入主节点的数据可能需要几秒钟才会流向辅助节点。但这允许您拥有几乎无限数量的辅助只读服务器，这非常适合在大量读取负载下扩展数据库。
Mongo处理群集的方式也允许它具有非常高的正常运行时间，因为如果服务器出现故障，群集将自动重组为初级和次级。这甚至允许滚动维护而无需任何客户端停机。
在写入过程中不必强制执行复杂的约束或事务一致性，这样就可以更加快速地编写数据库，从而实现更加轻松的写入方式。同样，以允许不一致的数据为代价。这就是为什么大多数写作几乎意味着原子地更新集合中的单个文档而不保证其他文档，这是与许多表中的RDBMS事务更新不同的范例。
我不建议使用Mongo来存储金融分类账这样的东西，它严重依赖事务保证来保持一致性。然而，像Twitter这样的事情就是一个很好的例子：许多独立的数据片段必须由大量的客户阅读。