为什么键值对noSQL db比传统关系DB更快

Question

我建议我调查Key / Value对数据系统来替换我一直在使用的关系数据库。

我不太了解这是如何提高查询效率的。根据我的理解，您只需将结构数据库转换为一个很长的键和值列表，就可以丢弃大量有助于提高查询效率的信息吗？

我完全错过了这一点吗？

Answer 1

关系数据库的关键优势是能够关联和索引信息。大多数“NoSQL”系统不提供关系代数或优秀的查询语言。

您需要问自己的是，切换对我的预期用例有意义吗？

你有点错过了这一点。关键是，你有时候没有索引（就像你对普通关系数据库一样）。即使您拥有索引，也很难将它们联系在一起，并且关系数据库的优势也很大。 NoSQL解决方案具有许多新颖的结构，这使得许多用例很容易，例如， Redis是一个面向数据结构的数据库，非常适合用队列或pub-sub架构快速构建任何东西。 MongoDB是一个自由形式的文档数据库，它将文档存储为JSON（BSON），并且在快速开发方面表现优异。 BigTable解决方案的结构稍微不那么简单，但扩展了行的思想，以便拥有列族 - 每行中包含的键值对有效地排列在磁盘上。您可以使用ElasticSearch等技术在此基础上构建倒排索引。

并非所有内容都需要传统RDBMS的一致性保证或磁盘布局。 NoSQL的另一个主要用例是大规模可扩展性，许多解决方案（例如BigTable - HBase / Cassandra）设计用于水平分片和扩展（使用SQL不太容易！）。特别是Cassandra是为没有SPOF而设计的。此外，面向列的数据存储区旨在通过顺序读取来优化磁盘速度（并减少write-amplification）。话虽如此，除非你真的需要它，否则传统的SQL服务器通常就足够了。

有优点和缺点。就个人而言，我使用两者的混合。使用正确的工具来完成正确的工作，这可能最终成为PostgreSQL或MySQL。

您可以将基本键值系统比作制作包含两列，唯一键和值的SQL表。这很快。您无需进行任何关系或相关性或数据整理。只需找到该值并将其返回。这是一个过于简单化，NoSQL数据库确实有很多有趣的功能和应用程序，超越简单的K，V商店。

我不知道你的科学数据是否适合大多数NoSQL实现，这取决于数据。如果你看看HBase或Cassandra，它可能很适合科学家的需求（使用正确的rowkey设计 - 时间戳不能是第一个，请查看OpenTSDB）。我知道许多公司通过使用随机分区器和传感器的UUID将读数汇总到每日脂肪行中，在Cassandra中存储传感器读数。每天都会围绕特定用例创建新数据库，以便答案可能会发生变化。对于特定用例，您可以以灵活性和工具为代价获得使用特定数据存储的巨大回报。

Answer 2

效率来自三个主要方面：

1. 数据库的功能要少得多：没有连接的概念，也没有减少或缺少事务完整性要求。功能越少意味着工作越少意味着更快，至少在服务器端。
2. 另一个设计原则是数据存储位于服务器云中，因此您的请求可能有多个响应者。这些系统还声称多服务器系统通过复制提高了容错能力。
3. 它完全符合流行语，使用了一堆尚未完全发明的想法和描述。例如，亚马逊目前正在提供他们的服务，以便更好地了解人们如何使用它们并获得改进规范的经验。

在我看来，有人要求“我们的新数据对于我们的RDBMS来说太多了”的人应该有数字支持这个断言，或者承认他们只是想尝试新的闪亮。 NoSQL是无效的吗？可能不是。随着Java 1.0被大肆宣传，是否会让世界颠倒？可能不是。

调查新事物没有坏处，只是不要把农场押在他们身上，转而支持50年历史，知名度很高的技术。

Answer 3

这里我假设您要优化一个特定查询，这只是按键查找记录。其中一个例子可能是按用户名查找userinfo记录。对于某些系统，类似的查询必须非常快，所有其他查询都不重要。

数据库性能的最大因素是读/写数据所需的I / O操作数。大多数数据库系统使用类似的数据结构（即b树），它可以在O（log（n））I / O中收到未缓存的数据。为了提供持久的更新，必须将数据写入磁盘：大多数系统按顺序执行，这是最快的方式。

那么，Key-Value商店可以在哪里获得效率？

1. 非标准化数据。将所有数据放在一行意味着没有连接。
2. 低CPU开销。键值存储避免了查询处理/优化，安全检查，约束检查等的CPU成本。
3. 让商店处于进程中更容易（而不是作为单独服务运行的SQL服务器），这消除了IPC开销。

大多数RDBMS系统都建立在看起来像键值存储的东西之上，因此您可以将其视为切断中间人。

Answer 4

上面有很多好的观察，有时两个支持者对双方都有太多的激情。让我们回到你原来的问题。假设您在Cassandra上进行设计并在RDBMS上执行相同的设计。假设你在Cassandra中有一组KV对，并且在关系上去做一组相同的KV对。 （实际上可以这样做 - 比如，作为关系上的完全非规范化名称值对）。即使这样，关系也会因为关系DBMS的开销 - 日志记录，目录访问，完整性检查，事务原子性等等而变慢。此外，在列族数据存储中，数据是按字母排序的;它不是关系型的。我相信有几个社交网站做到了这一点，他们在两者上构建了相同的结构，但关系速度较慢。重要的是要记住，在用户查询产品数据库之后，查看谁也购买了这个或那个，构建他们的购物车和他们的愿望清单，所有这些都将在NOSQL上完成，当用户点击结账按钮时，交易将在关系数据库上运行。为什么我们所谓的专家不能在这个数据库辩论中意识到它不是唯一的，而是存在关系的地方，如NOSQL，图形，倒列数据库，多维等等甚至文件。