sql - 对于一台机器上的结构化数据，NoSQL是否比RDBMS有任何真正的优势？

Question

因此，我一直在努力弄清楚NoSQL是否真的在自动分片和处理非结构化数据之外带来了那么多值(value)。

假设我可以将结构化数据放在一台计算机上，或者具有有效的SQL“自动分片”功能，那么NoSQL选项有什么优势？我确定了以下内容:

基于文档的(MongoDB，Couchbase等)-除了“自动分片”功能外，我很难理解其好处。链接对象与SQL连接非常相似，而嵌入式对象极大地增加了文档的大小，并给复制带来了挑战(注释可能既属于帖子又属于用户，因此数据将是多余的)。而且，ACID的丢失和交易也是一个很大的缺点。

基于键值(Redis，Memcached等)-服务于不同的用例，非常适合缓存但不是复杂的查询

柱状(Cassandra，HBase等)-似乎最大的好处是数据存储在磁盘上的方式更多，并且大多数用于聚合，而不是一般使用

图(Neo4j，OrientDB等)-最吸引人的是，同时使用边缘和节点会产生有趣的值(value)主张，但对于高度复杂的关系数据而不是一般用途最有用。

我可以看到键值，列和图数据库在特定用例(缓存，社交网络关系映射，聚合)方面的优势，但是看不到有任何理由使用MongoDB之类的东西来处理结构化数据，除了“自动”分片功能。

如果SQL具有类似的“自动分片”功能，那么SQL是否会毫无疑问地处理结构化数据？在我看来是这样，但是我希望社区的意见...

注意:这是针对典型的CRUD应用程序，例如社交网络，电子商务站点，CMS等。

Answer 1

如果您是从一台服务器上启动的，那么NoSQL的许多优势将荡然无存。最受欢迎的NoSQL的最大优点是高可用性，减少了停机时间。最终的一致性要求也可以提高性能。这确实取决于您的需求。

基于文档的-如果您的数据非常适合少量的小数据桶，则使用面向文档的数据库。例如，在分类网站上，我们以用户，帐户和列表为核心数据。大量的搜索和显示操作仅针对 list 。对于旧数据库，我们必须执行近40个联接操作才能获得单个列表的数据。使用NoSQL，它是一个查询。使用NoSQL，我们还可以针对嵌套数据创建索引，再次查询结果时不使用Joins。在这种情况下，我们实际上是出于搜索和显示的目的将数据从SQL镜像到MongoDB(还有其他原因)，目前正在研究长期迁移策略。 ElasticSearch，RethinkDB和其他数据库也是很好的数据库。 RethinkDB实际上对数据采取了非常保守的方法，ElasticSearch的即开即用索引是首屈一指的。

键值存储库-缓存在这里是一个很好的用例，当您运行中型到大量读取数据的高容量网站时，仅一个好的缓存策略就可以使您一次处理4-5倍的用户服务器。键值存储(RocksDB，LevelDB，Redis等)也是Graph数据的很好选择，因为单个映射可以通过subject-predicate-target值保存，这对于在顶部绘制选项非常快。

柱状-特别是Cassandra，即使是单值查找，也可以用来分配大量负载。 Cassandra的扩展与使用的服务器数量成线性关系。非常适合繁重的读写场景。我发现这对实时搜索的值(value)不高，但是在您的负载非常高并且需要分发时非常有用。这需要更多的计划，并且很可能无法满足您的需求。您可以调整设置以满足您的CAP需求，甚至可以在框中处理向多个数据中心的分发。注意:大多数应用程序确实不需要这种使用级别。在大多数情况下，您都可以考虑使用HBase / Hadoop或Cassandra，ElasticSearch可能更适合。

图-我对图数据库不熟悉，因此无法在此处注释(除了使用键值存储作为基础选项之外)。

假设您随后对MongoDB和SQL分别进行了评论，即使两者都是自动分片的。特别是PostgreSQL在获得不受限制的数据可用性(JSON / JSONB类型)方面取得了长足的进步，更不用说从PLV8之类的东西中获得的力量了，它可能最适合处理可能引发的负载类型具有NoSQL优势的文档存储。发生故障的地方是复制，分片和故障转移被栓在并非真正存在的解决方案上。

对于中小型负载，分片确实不是最好的方法。大多数情况下大多数情况下都是读取的，因此当您拥有3-5台服务器时，在其中具有其他读取节点的副本集通常会更好。在这种情况下，MongoDB非常有用，可以自动选择主节点，并且故障转移非常快。我所见过的唯一奇怪的事情是，Azure在2014年末关闭时，只有一台服务器首先启动，另外两台服务器则在40分钟后启动。通过复制，任何给定的读取请求都可以由单个服务器整体处理。您的数据结构变得更简单，并且减少了数据丢失的机会。

再次在上面的示例中，对于中等规模的分类站点，绝大多数数据属于单个集合...对其进行搜索并从该集合中进行显示。在这种用例下，文档存储比结构化/规范化的数据要好得多。对象的存储方式与它们在应用程序中的表示非常接近。认知脱节少了，而且很有效。

事实是，SQL JOIN操作会降低性能，尤其是在跨这些联接聚合数据时。对于单个用户的单个查询，即使有十几个查询也没关系。当您与成千上万的同时用户进行数十个联接时，联接开始崩溃。此时，您有几种选择...

缓存-缓存始终是一种很好的方法，数据更改的频率越少越好。从一组memcache / redis实例到使用MongoDB，RethinkDB或ElasticSearch之类的东西来保存复合记录，它可以是任何东西。这里的挑战归结为更新或使您的缓存数据无效。

迁移-将数据迁移到更好地表示您的需求的数据存储中也是一个好主意。如果您需要处理大量写入或非常大量的读取情况，则没有SQL数据库可以跟上。您永远无法在SQL上处理Facebook或Twitter之类的内容。

介于之间-在需要扩展时，取决于您在做什么以及您的痛点在哪里，这将是给定情况下的最佳解决方案。许多开发人员和管理员担心会将数据分解到多个位置，但这通常是最好的答案。您的分析数据是否真的需要与核心运营数据位于同一位置？为此，您的登录名是否需要紧密耦合？您是否在进行大量相关查询？真的要看

提前发表个人意见

对我来说，我喜欢SQL提供的安全网。将它作为核心数据的中央存储是我的首选。我倾向于将RDBMS视为愚蠢的存储，我不喜欢被绑定(bind)到给定的平台。我觉得很多人都试图对数据进行过规范化。通常，我会在表中添加XML或JSON字段，以便可以存储其他数据而不会膨胀该方案，尤其是在不太可能查询该方案的情况下……然后，我将在应用程序代码中的对象中包含属性存储在这些字段中。一个很好的例子可能是付款...如果您当前正在使用一个或多个系统(其中一个用于CC以及Paypal，Google，Amazon等)，那么交易的详细信息确实不会影响您的记录，为什么要创建5个以上的表格来存储此详细数据。您甚至可以将JSON用于主要存储，并具有从该JSON派生并保留的计算列，以提供更广泛的查询功能和在需要的地方建立索引。诸如postgresql和mysql(iirc)之类的数据库也提供针对JSON数据的直接索引。

当数据很自然地适合文档存储时，我就说吧...如果您的绝大多数查询都针对更适合单个记录或集合的内容，请进行非规范化。将其作为主数据的镜像非常好。

对于需要大量写入的数据，您需要使用多个系统...这在很大程度上取决于您的需求...您是否需要快速的热查询性能？使用ElasticSearch。您是否需要绝对大规模的水平刻度，HBase或Cassandra。

这里要害的关键是不要害怕将其混合在一起……实际上并没有一种适合所有人的尺寸。顺便说一句，我觉得如果PostgreSQL提供了一个很好的解决方案(对于开源版本)，那么即使是复制和自动故障转移，它们的位置也比大多数情况下要好得多。

我并没有真正接触过，但是我应该提到，有许多SaaS解决方案和其他提供混合SQL系统的提供程序。您可以在本地针对MySQL / MariaDB进行开发，并在分布式存储集群之上使用SQL部署到系统。我仍然觉得HBase或ElasticSearch更适合记录日志和分析数据，但是顶级解决方案上的SQL也很引人注目。

更多: http://www.mongodb.com/nosql-explained