mongodb - NoSQL(Cassandra/Mongodb)与 RDBMS

Question

您好，我正在从系统设计的角度学习 NoSQL 数据库的功能，并且还了解到很多大公司使用分片 RDBMS 而不是那些 nosql 数据库来保存数据。

这是否表明 NoSQL 数据(Cassandra/MongoDB)的唯一优势是因为它是现成的分布式解决方案并且维护成本低廉？

Answer 1

read that a lot of big companies use shard rmdb

在我的上一份工作中，我的组织支持手动分片的 Postgres 解决方案。这给我们带来了巨大的痛苦，因为它的规模很大，很难管理和维护。请记住，RDBMS 并不是真正设计为以这种方式工作的。

only advantage of nosql ... is because it's an off-the shelf distributed solution

这个决定实际上就是权衡。当您的数据工作负载无法由单个数据库实例处理或者您需要无单点故障的正常运行时间时，NoSQL 可以为您提供帮助。为了分区容错性和可用性而牺牲一致性的数据库(“AP”数据库)通常能够以很小的延迟处理大量工作负载，因为它们能够将数据(以及查询)传播到多个服务器实例。

此外，如果您的数据需要具有地理或数据中心意识，您将需要一个支持该功能的数据库。试图让数据库产品以其原始设计未考虑到的方式工作会带来痛苦。

cheap to maintain

询问任何经营企业数据库组织的人，他们都会告诉您 NoSQL 维护起来并不便宜(或容易)。当然，您可能会获得不必“购买”的开源产品，但您将需要(通常是高薪)数据库工程师来维护它。

scalability comes along with nosql by design, but it also seems that sql can also achieve the same and the primary issue is only the maintenance/configuration when scaling it up.

这要看情况。您计划扩展到多大，需要支持多少个数据副本？像 Apple 这样的大型企业拥有数千台运行 Apache Cassandra 的服务器。他们这样做是因为 iCloud 需要扩展才能满足 9 亿 iPhone 用户的需求。他们可以根据计算资源的需求轻松添加(扩大)或删除(缩小)。

与 Cassandra (NoSQL) 相比，使用关系数据库实现这种级别的可扩展性需要做更多的工作。当您发现需要进一步扩展时，您基本上会考虑数据重新加载场景(因为分片大小本质上发生了变化)以将数据获取到新实例。数据库团队将(很快)达到扩展 RDBMS 所需的工作量不切实际的地步。

另一方面，客户端应用程序如何知道哪个关系数据库服务器发送查询？对于大多数关系数据库，您最终将不得不以某种方式构建或增强该逻辑层。当数据库实例的数量发生变化时，您也需要应用程序了解这一点。 NoSQL 数据库负责节点发现，并且(大多数)对其进行抽象，因此客户端应用程序无需担心它。

还请记住，并非所有 NoSQL 数据库都是平等创建的。在某些产品上，只有某些节点才会接受写入。在某些产品上，任何节点都可以处理读取或写入。关系数据库对此没有任何概念，因此您也必须考虑到这一点。

tl;博士;

由于扩展，它比单纯的维护要复杂得多。如果不是，每个主要的关系数据库都会有一个简单的方法来处理这个问题，NoSQL DB 将变得无关紧要。但这并没有发生。