假设我可以在单个机器上安装我的STRUCTURED数据，或者对sql有一个有效的“自动分片”功能，任何Nosql选项都有哪些优势？我确定了以下内容：
>基于文档(MongoDB，Couchbase等) – 除了“自动分片”功能之外，我很难理解其中的优点。链接的对象与sql连接非常相似，而嵌入式对象会显着影响文档大小，并对复制造成挑战(注释可能属于后置和用户，因此数据将是冗余的)。此外，ACID和交易的损失是一个很大的缺点。
>基于键值(Redis，Memcached等) – 提供不同的用例，非常适合缓存，但不是复杂的查询
> Columnar(Cassandra，HBase等) – 似乎这里的最大优点是数据如何存储在磁盘上，而且对于聚合而非一般性使用
> Graph(Neo4j，OrientDB等) – 最有趣的是，边缘和节点的使用都是一个有趣的价值主张，但是对于高度复杂的关系数据而不是普遍使用来说，这是非常有用的。
我可以看到特定用例(缓存，社交网络关系映射，聚合)的Key-Value，Columnar和Graph DB的优点，但是看不到任何理由使用MongoDB这样的结构化数据之外的“auto-分片“功能。
如果sql具有类似的“自动分片”能力，那么sql对结构化数据来说是一个没有意义的事情？好像对我来说会是，但我想要社区的意见
注意：这是关于典型的CRUD应用程序，如社交网络，电子商务网站，CMS等。
>基于文档 – 如果您的数据适合少量的小数据量，那么面向文档的数据库。例如，在分类广告网站上，我们以用户，帐户和列表为核心数据。搜索和显示操作的大部分都是单独列出的。使用遗留数据库，我们必须执行近40个连接操作才能获取单个列表的数据。使用Nosql是一个单一的查询。使用Nosql，我们还可以针对嵌套数据创建索引，再次查询没有连接的结果。在这种情况下，我们实际上将数据从sql镜像到MongoDB，用于搜索和显示(还有其他原因)，现在正在进行更长期的迁移策略。 ElasticSearch，RethinkDB等也是很好的数据库。 RethinkDB实际上对数据采取了非常保守的方法，ElasticSearch的开箱即用的索引是首屈一指的。
>键值存储 – 缓存是一个很好的用例，当您运行大量读取数据的中等大容量网站时，单独的良好缓存策略可以让您由单个服务器处理的用户的4-5倍。
> Columnar – Cassandra特别可以用于分配大量的负载甚至单值查找。 Cassandra的缩放与使用的服务器数量非常线性。非常适合重读写和写入场景。我发现这对于实时搜索来说不那么有价值，但是当您拥有非常高的负载并且需要分发时，这是非常好的。它需要更多的规划，可能不太适合你的需要。您可以调整设置以满足您的CAP需求，甚至可以处理分发给盒子中的多个数据中心。注意：大多数应用程序强调不需要此级别的使用。在大多数情况下，ElasticSearch可能更适合您考虑使用HBase / Hadoop或Cassandra。
图表 – 我不太熟悉图形数据库，所以在这里不能评论。
鉴于您随后对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作为愚蠢的存储来处理，我不喜欢被绑在给定的平台上。我觉得很多人试图过度规范他们的数据。通常我会向表中添加一个XML或JSON字段，这样可以存储更多数据的数据，而不会使程序发生膨胀，特别是如果不太可能被查询，那么我将在应用程序代码中的对象中具有属性存储在这些领域。一个很好的例子可能是付款…如果您正在使用一个系统或多个系统(一个用于CC以及Paypal，Google，Amazon等)，则事务的细节真的不会影响您的记录，为什么要创建5个表存储此详细数据。
当数据对于文档存储来说是一个非常适合的时候，我会说：如果绝大多数的查询都是适用于单个记录或集合的东西，则可以将其归一化。将此作为您的主要数据的镜像是伟大的。
对于重写数据，您希望多个系统正在运行…这在很大程度上取决于您的需求…您需要快速的热查询性能？和ElasticSearch一起去你需要绝对的大规模水平尺度，HBase或Cassandra。
关键在这里带走是不要害怕混合起来…真的没有一个适合所有的尺寸。除此之外，我觉得如果Postgresql提供了一个很好的框架(对于开放源代码版本)解决方案，即使是复制和自动化故障切换，它们比大多数在这一点上要好得多。
我没有真正进入，但是我应该提到有许多SaaS解决方案和其他提供混合sql系统的提供商。您可以在本地开发MysqL / MariaDB，并在分布式存储集群之上部署到具有sql的系统。我仍然觉得HBase或ElasticSearch对于日志记录和分析数据来说更好，但顶级解决方案上的sql也很有吸引力。