对于需要按内容搜索的大型数据集，使用NoSQL数据库是否不切实际？

我已经学习NoSQL数据库已有一个星期了。

我真的了解NoSQL数据库的优势以及它们非常适合的许多用例。

但是人们通常会在撰写文章时就好像NoSQL可以代替关系数据库一样。还有一点我无法理解：

NoSQL数据库是（通常）键值存储。

当然，可以将所有内容存储到键值存储中（通过将数据编码为JSON，XML等），但是我看到的问题是，在许多情况下，您需要获取一些与特定条件匹配的数据用例。在NoSQL数据库中，只有一个可以有效搜索的条件-密钥。关系数据库经过优化，可以有效地搜索数据行中的任何值。

因此，NoSQL数据库并不是持久存储需要按其内容搜索的数据的真正选择。还是我误会了什么？

一个例子：

您需要存储网上商店的用户数据。

在关系数据库中，您将每个用户存储为users表中的一行，并带有ID，名称，他的国家等。

在NoSQL数据库中，您将以ID为密钥存储每个用户，并将其所有数据（以JSON等编码）存储为值。

因此，如果您需要从某个特定国家/地区获取所有用户（出于某种原因，营销人员需要了解他们的某些信息），那么在Relational Database中这样做很容易，但是在NoSQL Database中却不是很有效，因为您必须获取每个用户，解析所有数据并进行过滤。

我并不是说这是不可能的，但是它变得更加棘手，如果您要搜索NoSQL条目的数据，我想那不是那么有效。

您可以为每个国家/地区创建一个密钥，以存储该国家/地区中每个用户的密钥，并通过获取存放在该国家/地区的密钥中的所有密钥来获取特定国家/地区的用户。但是我认为这种技术使复杂的数据集变得更加复杂-难以实现且不如查询SQL数据库有效。因此，我认为这不是您在生产中使用的方式。还是？

我不确定我是否会误解或忽略了一些概念或最佳实践来处理此类用例。也许您可以纠正我的陈述并回答我的问题。

尽管我同意NoSQL并非解决所有数据库问题的灵丹妙药的前提，但我认为您会误解一个关键点。

在NoSQL数据库中，只有一个可以有效搜索的条件-密钥。

这显然是不正确的。

例如，MongoDB支持索引。（来自https://docs.mongodb.org/v3.0/core/indexes-introduction/）

索引支持在MongoDB中高效执行查询。没有索引，MongoDB必须执行集合扫描，即扫描集合中的每个文档，以选择与查询语句匹配的那些文档。如果查询存在适当的索引，则MongoDB可以使用该索引来限制它必须检查的文档数。

索引是特殊的数据结构[1]，它以易于遍历的形式存储集合数据集的一小部分。索引存储一个特定字段或一组字段的值，按该字段的值排序。索引条目的排序支持有效的相等匹配和基于范围的查询操作。另外，MongoDB可以使用索引中的顺序返回排序的结果。

沙发床也一样（来自http://docs.couchbase.com/admin/admin/Views/views-intro.html）

Couchbase视图允许索引和查询数据。

视图根据定义的格式和结构在数据上创建索引。该视图由特定字段和从Couchbase中的对象提取的信息组成。

实际上，任何自称为NoSQL 数据库而不是键值存储的东西都应该真正支持某种索引方案。

实际上，正是这些索引方案的灵活性使NoSQL大放异彩。在我看来，用于定义NoSQL索引的语言通常比SQL更具表达性或自然性，并且由于它们通常位于表外部，因此您无需更改表架构即可支持它们。（并不是说您不能在SQL中做类似的事情，但对我来说，感觉像是涉及到更多的跳跳）。

通常，如果您的工作流程非常适合关系数据库查询，那么您会发现关系数据库是最有效的方法。它是重言式的，但却是真实的。

许多NoSQL拥护者会宣称，实际上许多工作流都被压缩为一种关系形式，并且在进行这种按摩之前会更加有效。这项索赔的有效性很难确定。显然，SQL查询对作业进行了很好的描述。我可以根据经验说，使用NoSQL可以以几乎相同的效率（甚至更高）来完成我的特定关系编程任务。但是，这是基于狭窄经验的非常主观的陈述。

我感觉NoSQL方法的销售主要来自大型数据库的假设。数据库越大，您就必须修饰工作流程越多，以支持更大的数据集。NoSQL在支持这种修饰工作方面似乎更好。因此，数据库越大，NoSQL的功能就可能越重要。

要使用该示例，在SQL中按国家/地区查询与对所有用户进行NoSQL扫描一样慢，除非您明确告诉SQL users按国家/地区对表进行索引。NoSQL可以做同样的事情，您可以创建索引的有序键值集合（就像SQL在后台一样）并进行维护。

区别？SQL引擎具有内置表索引的概念。这意味着您要做的工作更少（您要做的就是向表中添加索引）。但是，这也意味着您的控制较少。在大多数情况下，失去控制是可以接受的，以换取SQL引擎为您完成工作。但是，在海量数据集中，您可能需要与典型的SQL ACID模型不同的一致性模型。您可能要使用支持最终一致性的BASE模型。在SQL中这可能非常困难，因为SQL引擎正在为您完成工作，因此必须由SQL引擎的规则来完成。在NoSQL中，这些层通常是公开的，可让您对其进行破解。

NoSQL是一个模糊的术语，因为它基本上涵盖了所有非关系数据库系统。

您所描述的是一个键值存储，它是一种数据库，在该数据库中，一堆数据存储在一个键下，如果您知道该键，则可以快速查找。如果您知道确切的密钥，这些数据库将非常快，但是正如您自己说的那样，如果您需要搜索或筛选数据上的多个属性，它将很慢且麻烦。

在他们的头脑中，没有人会声称键值存储一般可以代替关系数据库。但是，在某些特殊情况下，键值存储非常适合。键值存储通常用于缓存，因为您通常按ID缓存项，但不需要对缓存执行临时查询。例如，＃1位点本身使用的Redis（键值分贝）广泛，但仅用于输出缓存。底层规范数据仍保留在关系数据库中。

因此答案很明显：如果只需要使用一个键来存储和查找，则使用键值存储。否则，请使用其他类型的数据库。并且，如果您有疑问，请使用关系数据库，因为这是最通用的数据库，而NoSQL数据库通常针对非常特殊的用例进行了优化。

您对关系数据库的主张都是正确的，直到您拥有如此多的数据为止，再也无法在单个服务器上容纳它的副本。然后，您开始遇到各种有趣的问题。如何拆分表，以便大多数查询可以在单个服务器上运行？您制作多少个数据副本？您如何处理这些副本之间的不一致之处？您如何将用户的数据保存在地理位置相对较近的数据中心中？

这些目标经常相互冲突。许多Twitter用户关注来自世界各地的人们。Twitter的数据库是否应该在地理上优化以读取或写入推文？

事实证明，当您处理这种规模的问题时，便会开始发明解决方案，添加冗余并施加非常类似于NoSQL数据库的限制。如果您可以将所有数据放在一个盒子中，那么您将得到限制，而无需任何好处。

NoSQL数据库与“ No SQL” 无关。

他们是要承认您不能拥有一个始终如一，支持复杂事务并具有持久性的大规模数据库。

在普通的关系数据库中，所有索引会在事务范围内自动保持更新，因此可用于任何查询。

在NoSQL数据库中，程序员负责维护许多索引，并且假定索引将始终过时。

例如：

• 按税收人数索引可能包含一些从未完成税收注册过程的人员。
• 因此，使用索引的代码必须能够应付不完整的税收注册
• 另一种选择是在某些情况下需要注册的人不在索引中。（因此，您的设计必须处理没有一致的数据，并决定如何使数据不一致。）

举一个真实的例子，亚马逊宁愿给我显示一本书的过时描述，而不是通过等待106台计算机确认已取出正确的锁来延迟网页的显示。

因此.....

如果单个正常的关系数据库可以保存您的所有数据并足够快地处理每个事务，以致锁定不会阻止您的系统执行有用的工作，那么关系数据库是最佳选择。

但是，一旦您开始考虑使用多个关系数据库或拆分事务以避免锁定错误，就走上了使用“ NoSQL”数据库时必须解决的问题。

由于“ NoSQL”数据库不会隐藏这些问题，因此在扩展系统时，它们可能成为最佳选择。 但是请记住，Stackoverflow仍然使用关系数据库来存储其所有数据，并且在缓存层中使用NoSQL的程度有限-因此在被迫使用NoSQL来存储数据之前，您必须非常庞大。

关系数据库经过优化，可以有效地搜索数据行中的任何值。

不要混淆连续搜索“任何”值与连续“每个”值的能力。最有效的方法需要一个或多个索引。您可能使索引包括所有字段，但是您只是阻碍了进行需要更改索引的更改（插入，更新，删除）的能力。您（或您的DBA）必须了解数据，用法，瓶颈等。

已经有很多答案，但是我只想添加我的摘要。

显然，NoSQL概念涵盖了组织磁盘上的数据，内存中的数据以及通过查询语言公开数据的各种不同方法（有些甚至类似于SQL！）。我认为，强大的力量来自于各种系统，因此您可以选择最适合工作的工具。但是仍然希望您可以通过几种不同的解决方案满足多种需求，而您并不想管理多种不同的系统。

关系数据库可以使您走得更远并且是一种可靠的技术，但是就像数据库一样，您可能希望根据每个项目的需求选择编程语言（但也要考虑团队的经验）。

我已经使用两年的沙发床了。它主要用于内容管理和配置。

对于分层关系，当您可以可视化它们时更容易管理。对于大多数读数据，在许多情况下，编辑JSON比编写UPDATE语句更容易。实际上，不需要程序员来编辑JSON。SQL提供行和列，然后您必须将它们映射到某种对象结构中。

您还可以提高性能，因为您不会在复杂查询中加入10-20个表。Couchdb视图非常快，因为它们基于的javascript不会在查询时执行。

大多数程序员都了解Javascript，并且大多数程序员偶尔也会遇到SQL问题。

在Couchdb中，视图可以认为是JSON文档的摘要。视图数据的结构由您决定（不受原始层次结构的约束）。

我不会将Couchdb用于高度事务性的数据，但是对于具有部件爆炸类型结构的半静态数据，它比SQL更容易使用。

但是请注意，没有明确的“规范化”可应用（尽管避免重复数据是一个值得的目标），并且本质上存在类似于乐观锁定的“乐观”更新策略。