44

什么时候会选择键值数据存储而不是关系数据库？在决定其中一个或另一个时会考虑哪些因素？什么时候混合最好的路线？如果可以，请提供示例。

4

6 回答 6

32

键值、层次结构、map-reduce 或图形数据库系统更接近于实现策略，它们与物理表示密切相关。选择其中之一的主要原因是是否有令人信服的性能论据，并且它非常适合您的数据处理策略。请注意，临时查询通常对这些系统不实用，您最好提前决定查询。

关系数据库系统试图将逻辑的、面向业务的模型与底层的物理表示和处理策略分开。这种分离是不完美的，但仍然很好。关系系统非常适合处理事实和从事实集合中提取可靠信息。关系系统在即席查询方面也很出色，而其他系统则出了名的不擅长。这非常适合商业世界和许多其他地方。这就是为什么关系系统如此流行的原因。

如果它是一个业务应用程序，那么关系系统几乎总是答案。对于其他系统，这可能是答案。如果您有更多的数据处理问题，例如一些需要发生的事情的管道并且您拥有大量数据，并且您预先知道所有查询，那么另一个系统可能适合您。

于 2009-10-01T06:02:03.230 回答
7

如果您的数据只是一个事物列表，并且您可以为每个项目派生一个唯一标识符，那么 KVS 是一个很好的匹配。它们是我们在大一计算机科学中学到的简单数据结构的紧密实现，不允许复杂的关系。

一个简单的测试：您能否将您的数据及其所有关系表示为链表或哈希表？如果是，KVS 可能会起作用。如果没有，您需要一个 RDB。

您仍然需要找到可以在您的环境中运行的 KVS。对 KVSes 的支持，即使是主要的，也远不及它对 PostgreSQL 和 MySQL/MariaDB 的支持。

于 2014-09-07T16:26:20.287 回答
2

IMO，键值对（例如 NoSQL 数据库）在底层数据是非结构化的、不可预测的或经常变化的情况下效果最好。如果您没有结构化数据，那么关系数据库将比它的价值更麻烦，因为您将需要进行大量架构更改和/或跳过箍以使您的数据符合结构。

KVP / JSON / NoSql 很棒，因为对数据结构的更改不需要完全重构数据模型。将字段添加到您的数据对象只需将其添加到数据中即可。另一方面，KVP / Nosql 数据库中的约束和验证检查比关系数据库少，因此您的数据可能会变得混乱。

关系数据模型具有性能和节省空间的优势。规范化的关系数据可以更容易地理解和验证数据，因为有表键关系和约束可以帮助您。

我见过的最糟糕的模式之一是试图同时拥有它。试图将键值对放入关系数据库通常会导致灾难。我建议使用最适合您数据的技术。

于 2018-04-09T20:30:48.320 回答
2

如果您想要基于键的 O(1) 值查找，那么您需要一个 KV 存储。这意味着，如果您有表单k1={foo}, k2={bar}等数据，即使值较大/嵌套结构，并且想要快速查找，您也需要 KV 存储。即使使用正确的索引，您也无法在关系数据库中为任意键实现 O(1) 查找。有时这被称为“随机查找”。

头韵表示，如果您只查询一列，如果您愿意，则使用“主键”来检索其余数据，然后将该列用作键空间并将其余数据用作 KV 存储中的值进行查找的最有效方法。

相反，如果您经常通过几列中的任何一列查询数据，也就是您支持更丰富的数据查询 API，那么您可能需要一个关系数据库。

于 2018-10-12T01:26:05.257 回答
1

传统的关系数据库存在扩展超出一个点的问题。那一点在哪里取决于你想要做什么。

所有（大多数？）云计算供应商都在提供键值数据存储。

但是，如果您有一个规模合理且数据结构复杂的应用程序，那么使用关系数据库获得的支持可以降低您的开发成本。

于 2009-09-30T21:05:47.620 回答
-5

以我的经验，如果您甚至问是否使用传统实践还是深奥实践的问题，那就去传统的吧。虽然深奥的实践是性感、具有挑战性和有趣的，但 99.999% 的应用程序需要传统方法。

关于关系与 KV，您应该问的问题是：

为什么我不想在这种情况下使用关系模型：...

由于您没有描述该场景，因此任何人都无法告诉您为什么不应该使用它。KV 的“包罗万象”的原因是可扩展性，现在这不是问题。你知道优化规则吗？

  1. 不要这样做。
  2. （仅限专家）现在不要这样做。

KV 是一种高度优化的可扩展性解决方案，对于您的应用程序很可能完全不需要。

于 2009-09-30T22:21:41.460 回答