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

Question

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

Answer 1

键值，层次，地图缩减或图形数据库系统更接近实施策略，它们与物理表示密切相关。选择其中之一的主要原因是，如果存在令人信服的性能参数，并且它非常符合您的数据处理策略。请注意，即席查询通常对这些系统不实用，您最好提前决定查询。

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

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

Answer 2

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

一个简单的测试：你能将你的数据及其所有关系表示为链表或哈希表吗？如果是，KVS可能有效。如果不是，则需要RDB。

您仍然需要找到适合您环境的KVS。对KVSes的支持，即使是主要的KVS，也远远不及PostgreSQL和MySQL / MariaDB。

Answer 3

传统的关系数据库存在超出某一点的问题。这一点取决于你想要做什么。

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

但是，如果您的应用程序具有合理大小的应用程序，并且使用关系数据库，则可以降低开发成本。

Answer 4

根据我的经验，如果你甚至提出是否使用传统与深奥的做法的问题，那么就去传统。虽然深奥的实践性感，挑战性和趣味性，但99.999％的应用程序需要采用传统方法。

关于关系与KV，你应该提出的问题是：

  

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

由于您尚未描述该方案，因此任何人都无法告诉您为何不使用该方案。 KV的“全部捕获”原因是可扩展性，现在这不是问题。你知道优化规则吗？

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

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

Answer 5

IMO，当基础数据非结构化，不可预测或经常更改时，键值对（例如NoSQL数据库）效果最佳。如果您没有结构化数据，关系数据库将比其价值更麻烦，因为您需要进行大量架构更改和/或跳过环以使您的数据符合结构。

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

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

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

Answer 6

如果要基于键对值进行O（1）查找，则需要KV存储。就是说，如果您具有k1={foo}, k2={bar}形式的数据，即使这些值是较大的/嵌套的结构，并且想要快速查找，您仍需要KV存储。 即使使用正确的索引，也无法在关系数据库中实现任意键的O（1）查找。有时这称为“随机查找”。

用另一种说法，如果您只查询一列，则检索“剩余主数据”，然后使用该列作为键空间，将其余数据用作值。 KV商店是执行查询的最有效方法。

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