何时使用键值数据存储与更传统的关系数据库？ [关闭]

Posted 2023-02-16

【中文标题】何时使用键值数据存储与更传统的关系数据库？ [关闭]

【英文标题】：When to use a key-value data store vs. a more traditional relational DB? [closed]

【发布时间】：2010-12-02 19:18:44

【问题描述】：

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

【参考方案1】：

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

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

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

【讨论】：

我要指出这一点非常大，我知道有几个运行良好的多 TB 数据库（它们必须经过适当的设计和管理，并且具有正确的硬件来扩展）。

【参考方案2】：

根据我的经验，如果您甚至要问是使用传统还是深奥的做法，那就选择传统的吧。虽然深奥的做法很性感、富有挑战性且很有趣，但 99.999% 的应用程序都需要传统方法。

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

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

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

不要这样做。 （仅供专家使用）现在不要这样做。

KV 是一种高度优化的可扩展性解决方案，很可能对您的应用程序来说完全没有必要。

【讨论】：

此评论无法回答问题。何时以及为什么有人会选择使用 KV 存储而不是关系数据库？

什么是“传统”？随着 javascript 和 JSON 的兴起，今天有很多程序员从未使用过关系数据库。 noSQL 是许多标准，而关系则不是。此外，这并没有解决最初的问题：什么时候关系更好？

投反对票。当问题正在寻找会使不同数据库类型更合适的特定优缺点时，这是一个包罗万象的答案。此外，键值存储和 NoSQL 数据库变得太流行，以至于不能被视为“深奥”

【参考方案3】：

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

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

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

【讨论】：

这是正确答案。谢谢杰夫

【参考方案4】：

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

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

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

【参考方案5】：

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

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

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

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

【参考方案6】：

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

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

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