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

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

传统关系数据库在扩展到某个点之外时存在问题。这一点的位置在一定程度上取决于你想做什么

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

---

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

根据我的经验，如果您甚至要问是否使用传统做法还是深奥做法，那么就使用传统做法。虽然深奥的实践是性感、富有挑战性和有趣的，但99.999%的应用程序要求采用传统方法

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

为什么我不想在这个场景中使用关系模型：

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

不要这样做

（仅限专家）现在不要这样做

---

KV是一个高度优化的可伸缩性解决方案，对于您的应用程序来说，它很可能是完全不必要的。

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

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

---

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

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

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

您仍然需要找到一个可以在您的环境中工作的KVS。对KVSE（即使是主要的KVSE）的支持远不如对PostgreSQL和MySQL/MariaDB的支持。

IMO，当底层数据是非结构化的、不可预测的或经常更改时，键值对（例如NoSQL数据库）工作得最好。如果您没有结构化数据，那么关系数据库将比它的价值更麻烦，因为您需要进行大量的模式更改和/或跳转以使数据符合结构

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

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

我所见过的最糟糕的模式之一就是试图让两者兼而有之。试图将键值对放入关系数据库通常会导致灾难。我建议使用最适合您的数据的技术

如果需要基于键的值的O（1）查找，则需要KV存储。也就是说，如果您有

k1={foo}，k2={bar}

等格式的数据，即使这些值是较大的/嵌套的结构，并且需要快速查找，您也需要KV存储。 即使使用适当的索引，也无法在关系数据库中对任意键进行O（1）查找。有时这被称为“随机查找”

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

---

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

我想指出的是，这一点非常大，我知道有几个多字节数据库运行得非常好（它们确实必须经过适当的设计和管理，并且具有正确的硬件来扩展）。这一评论没有回答这个问题。何时以及为什么有人会选择在关系数据库上使用KV存储？什么是“传统”？随着javascript和JSON的兴起，现在有很多程序员从未使用过关系数据库。noSQL对于许多人来说都是标准的和相关的