为什么键值对的NoSQL数据库比传统关系型数据库更快

18

有人向我推荐使用键值对数据系统来替代我一直在使用的关系型数据库。

但我尚未完全理解这样做如何提高查询效率。据我所知,你只是将结构化数据库转换成一个大而长的键值列表,从而抛弃了许多有助于提高查询效率的信息,这样做真的会更高效吗?

难道我完全错了吗?


你为什么想要“替换我一直在使用的关系型数据库”? - Mitch Wheat
由于即将存储的数据量(当新加入的组开始自动提交来自其仪器的数据)显然会使系统变得非常缓慢。 - Ankur
2
一个配置合理的关系型数据库,在良好的硬件上将能够应对大多数负载。 - Mitch Wheat
4个回答

25
关系型数据库的关键优势在于能够关联和索引信息。大多数“NoSQL”系统没有提供关系代数或出色的查询语言。
你需要问自己的是,切换是否对我的预期使用情况有意义?
你有点错过了重点。重点是,有时你没有索引(无论如何,与一般关系型DB不同)。即使你有索引,将它们联系在一起的能力也很困难,而这正是关系型数据库擅长的地方。 NoSQL解决方案具有许多新颖的结构,可以使许多用例变得轻而易举,例如Redis是一个面向数据结构的DB,非常适合快速构建任何具有队列或其发布-订阅架构的东西。 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,则可能适合科学家的需求(使用适当的行键设计--时间戳不能在第一位,可以查看OpenTSDB)。我知道许多公司通过使用随机排序分区器和传感器的UUID将传感器读数存储在Cassandra中,以便将读数汇总到每日的大行中。每天都会围绕特定用例创建新的数据库,因此答案可能会改变。对于特定的用例,您可以使用特定的数据存储库获得巨大的回报,但代价是灵活性和工具的降低。


11

效率来自三个主要方面:

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

在我看来,如果有人向您提出“我们的新数据对关系型数据库管理系统来说太多了”,就应该有数字支持这种说法,否则他们只是想尝试新的闪亮物。NoSQL 是毫无价值的吗?可能不是。它是否像 Java 1.0 一样被炒作,颠覆世界?可能不会。

调查新事物没有坏处,只是不要押注于50年历史、既成的、深入理解的技术而不是新技术。


9

在这里,我假设您希望优化一个特定的查询,即通过关键字查找记录。其中一个例子可能是通过用户名查找用户信息记录。对于某些系统,这样的查询必须非常快速,而其他所有查询都不重要。

数据库性能中最大的因素将是读/写数据所需的I/O操作数量。大多数数据库系统使用类似的数据结构(即B树),可以在O(log(n))I/O中检索未缓存的数据。为了提供持久更新,数据将必须写入磁盘:大多数系统会按顺序执行此操作,这是最快的方法。

那么,key-value存储在哪里可以获得效率?

  1. 非规范化数据。将所有数据放入一行中意味着没有连接。
  2. 低CPU开销。key-value存储避免了查询处理/优化、安全检查、约束检查等CPU成本。
  3. 更容易让存储器处于进程中(而不是作为单独服务运行的SQL服务器),这消除了IPC开销。

大多数关系型数据库管理系统都建立在类似Key-Value存储的基础上,因此您可以将其视为去掉中间商。


2
上面有很多好的观察,有时候双方都有点过于热情。让我们回到你最初的问题。假设你在Cassandra上进行设计,并在关系型数据库上进行相同的设计。假设在Cassandra中有一组KV对,并在关系型数据库上执行相同的KV对操作(实际上可以这样做-例如,在关系型数据库上完全去规范化名称值对)。即使如此,由于关系型DBMS的开销-日志记录、目录访问、完整性检查、事务原子性等,关系型将运行得更慢。此外,在列族数据存储中,数据是按词典顺序排序的;而在关系型数据库中则不是。我认为一些社交网络网站就是这样做的,他们在两个系统上构建了相同的结构,但关系型数据库运行得更慢。需要记住的是,在用户查询产品数据库之后,查看谁也购买了这个或那个商品,构建他们的购物车和愿望清单,所有这些都将在NOSQL上完成,当用户点击结账按钮时,事务将在关系数据库上运行。为什么我们所谓的专家不能意识到在这个数据库辩论中并不是一个对另一个,而是关系型、NOSQL、图形、反向列数据库、多维等各有其用,甚至是文件。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接