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

如果你是在一台服务器上开始,那么NoSQL的许多优点就会消失.最受欢迎的NoSQL的最大优势是高可用性,停机时间更短.最终的一致性要求也可以带来性能改进.这真的取决于你的需求.

文档为主 - 如果您的数据非常适合少量数据,那么就是面向文档的数据库.例如,在分类广告网站上,我们将用户,帐户和列表作为核心数据.大部分搜索和显示操作仅针对列表.使用遗留数据库,我们必须进行近40次连接操作,以获取单个列表的数据.使用NoSQL,它只是一个查询.使用NoSQL,我们还可以创建针对嵌套数据的索引,同样在没有连接的情况下查询结果.在这种情况下,我们实际上是将数据从SQL镜像到MongoDB以进行搜索和显示(还有其他原因),现在正在进行长期迁移策略.ElasticSearch,RethinkDB等也是很好的数据库.RethinkDB实际上对数据采取了非常保守的方法,而ElasticSearch'

键值存储 - 缓存是一个很好的用例,当您运行中等到高容量的网站时,数据主要被读取,单独一个好的缓存策略可以让您获得单个服务器处理的用户的4-5倍.

Columnar - 特别是Cassandra可以用于分配大量的负载,甚至可以进行单值查找.Cassandra的缩放与使用中的服务器数量非常线性关系.非常适合繁重的读写场景.我发现这对于实时搜索来说不那么有价值,但是当你有非常高的负载并且需要分发时非常好.它需要更多的计划,可能不适合您的需求.您可以调整设置以满足您的CAP需求,甚至可以处理框中多个数据中心的分发.注:大多数应用程序都强调不要需要这个级别使用.在您考虑HBase/Hadoop或Cassandra的大多数场景中,ElasticSearch可能更适合.

图 - 我不熟悉图数据库,所以不能在这里发表评论.

鉴于你然后专门评论MongoDB与SQL ...即使两个自动分片.特别是PostgreSQL在获取非限制数据(JSON/JSONB类型)方面取得了很大进展,更不用说PLV8之类的功能,它可能最适合处理你可能抛出的负载类型一个具有NoSQL优势的文档存储.它恰好倒下的地方是复制,分片和故障转移都是用固定在盒子里的解决方案上.

对于中小负载,分片确实不是最好的方法.大多数场景大多是读取的,所以如果你有3-5个服务器,那么拥有一个副本集你有额外的读取节点通常会更好.在这种情况下,MongoDB很棒,主节点是自动选出的,故障转移非常快.我见过的唯一奇怪的事情是2014年底Azure出现问题,其中只有一台服务器首先出现,其他两台服务器差不多40分钟.通过复制,任何给定的读取请求都可以由单个服务器整体处理.您的数据结构变得更简单,并且减少了数据丢失的可能性.

同样在上面我自己的例子中,对于中等大小的分类网站,绝大多数数据属于单个集合......它被搜索并从该集合中显示.使用此用例,文档存储比结构化/规范化数据工作得更好.存储对象的方式更接近于它们在应用程序中的表示.没有认知断开,它只是有效.

事实上,SQL JOIN操作会降低性能,尤其是在跨这些连接聚合数据时.对于单个用户的单个查询,它很好,即使有十几个.当你与成千上万的同时用户进行数十次连接时,它开始崩溃.此时你有几个选择......

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

迁移 - 将数据迁移到更能代表您需求的数据存储也是一个好主意.如果您需要处理大量写入或非常大量的读取方案,则SQL数据库无法跟上.你永远不可能在SQL上处理Facebook或Twitter等.

介于两者之间 - 您需要扩展它取决于您正在做什么以及您的痛点在哪些方面对于给定情况最佳解决方案.许多开发人员和管理员担心将数据分解到多个位置,但这通常是最佳答案.您的分析数据是否真的需要与核心运营数据位于同一位置？那么你的登录需要紧密耦合吗？你在做很多相关的查询吗？这真的取决于.

个人意见未来

对我来说,我喜欢SQL提供的安全网.将它作为核心数据的中央存储,这是我的第一选择.我倾向于将RDBMS视为愚蠢的存储,我不喜欢被绑定到给定的平台.我觉得很多人都试图过度规范化他们的数据.通常我会在表中添加一个XML或JSON字段,这样就可以存储额外的数据而不会使方案膨胀,特别是如果它不太可能被查询...我将在应用程序代码中的对象中具有属性存储在那些领域.一个很好的例子可能是支付...如果您当前正在使用一个系统或多个系统(一个用于CC以及Paypal,Google,Amazon等),那么交易的细节实际上不会影响您的记录,为什么创建5个表来存储这些详细数据.

当数据自然适合文档存储时,我会说它...如果您的绝大多数查询都是针对单个记录或集合的更好的东西,那么非规范化.将此作为主数据的镜像非常棒.

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

这里的关键是不要害怕混淆......真的不是一刀切.顺便说一句,我觉得如果PostgreSQL能够提供一个优秀的解决方案(针对开源版本)解决方案,即使只是复制和自动故障转移,它们的位置也比大多数时候要好得多.

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

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