18

有人建议我研究键/值对数据系统来替换我一直在使用的关系数据库。

我不太了解的是这如何提高查询效率。据我了解，您将丢弃大量有助于提高查询效率的信息，只需将您的结构数据库变成一个长长的键和值列表？

我完全错过了重点吗？

4

4 回答 4

25

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

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

你有点错过了重点。关键是，您有时没有索引（无论如何，您使用一般关系数据库的方式）。即使你确实有一个索引，将它关联在一起的能力也很困难，这也是关系数据库擅长的。NoSQL 解决方案具有许多新颖的结构，使许多用例变得非常简单，例如 Redis 是一个面向数据结构的数据库，非常适合使用队列或其 pub-sub 架构快速构建任何东西。MongoDB 是一个自由格式的文档数据库，它将文档存储为 JSON (BSON)，擅长快速开发。BigTable 解决方案的结构比这稍差，但将行的概念扩展为具有列族——每行中包含的键值对在磁盘上有效排列。您可以使用 ElasticSearch 等技术在此之上构建倒排索引。

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

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

你可以把一个基本的键值系统比作一个包含两列的 SQL 表，一个唯一的键和一个值。这是相当快的。您无需对数据进行任何关系或关联或整理。只需找到值并返回它。这是一种过度简化，NoSQL 数据库除了简单的 K、V 存储之外，确实有很多有趣的功能和应用程序。

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

于 2010-03-01T06:52:49.750 回答
11

效率来自三个主要方面：

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

在我看来，有人向你提出“我们的新数据对于我们的 RDBMS 来说太多了”的要求，要么应该有数字来支持这一断言，要么承认他们只是想尝试新的闪亮。noSQL 是无用的吗？可能不是。是否会像 Java 1.0 大肆宣传那样颠覆世界？可能不是。

研究新事物并没有坏处，只是不要把农场押在它们身上，而要支持 50 年历史、成熟、易于理解的技术。

于 2010-03-01T07:13:31.813 回答
9

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

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

那么，Key-Value 存储在哪里可以提高效率呢？

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

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

于 2010-03-03T08:36:25.380 回答
2

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

于 2014-01-09T14:40:16.060 回答