什么情况下会选择键值数据存储而不是关系型数据库？在做决策时需要考虑哪些因素？什么时候混合使用两者是最佳选择？如果可能，请提供示例。
6个回答
39
键值、分层、MapReduce或图形数据库系统更接近实现策略，它们与物理表示密切相关。选择其中一个的主要原因是如果有强有力的性能论证，并且它非常符合您的数据处理策略。但请注意，这些系统通常不适用于特定的即席查询，最好提前确定查询。
关系型数据库系统试图将逻辑上的业务模型与底层的物理表示和处理策略分离。虽然这种分离并不完美，但仍然相当好。关系系统非常适合处理事实并从事实集合中提取可靠信息。关系系统也非常擅长即席查询，而其他系统则以这方面出了名的糟糕。这在商业世界和许多其他场所非常合适。这就是为什么关系系统如此普遍的原因。
如果是业务应用程序，几乎总是使用关系型系统。对于其他系统，则可能是答案。如果您遇到更多的数据处理问题，例如需要发生的一些流水线和大量数据，而且您事先知道所有查询，则可能会选择另一个系统。
- Jeff Davis
1
这是正确的答案。谢谢Jeff。 - Mitch VanDuyn
7
如果您的数据只是一些事物的列表，并且您可以为每个项目派生一个唯一标识符，那么KVS是一个很好的选择。它们是我们在计算机科学专业大一学习的简单数据结构的紧密实现，不允许复杂的关系。
一个简单的测试：您能否将您的数据及其所有关系表示为链表或哈希表？如果是，那么KVS可能适用。如果不是，您需要使用RDB。
您仍然需要找到适合您环境的KVS。即使是主要的KVS支持，也远远不如PostgreSQL和MySQL/MariaDB。
一个简单的测试：您能否将您的数据及其所有关系表示为链表或哈希表？如果是，那么KVS可能适用。如果不是，您需要使用RDB。
您仍然需要找到适合您环境的KVS。即使是主要的KVS支持，也远远不如PostgreSQL和MySQL/MariaDB。
- dmp
3
如果您想基于键进行O（1）查找值，则需要使用KV存储。这意味着，如果您有形式为
换句话说，如果您只通过一列查询，例如“主键”，检索其他数据，则使用该列作为键空间，其余数据作为KV存储中的值是最有效的查找方法。
相反，如果您经常通过多个列查询数据，也就是支持更丰富的数据查询API，则可能需要关系型数据库。
k1 = {foo}，k2 = {bar}等的数据，即使值是较大/嵌套结构，并且希望快速查找，则需要使用KV存储。即使使用适当的索引，在关系型数据库中也无法实现任意键的O（1）查找。有时将此称为“随机查找”。换句话说，如果您只通过一列查询，例如“主键”，检索其他数据，则使用该列作为键空间，其余数据作为KV存储中的值是最有效的查找方法。
相反，如果您经常通过多个列查询数据，也就是支持更丰富的数据查询API，则可能需要关系型数据库。
- Tommy
3
在我看来，键值对（例如NoSQL数据库）最适合处理底层数据是不结构化的、不可预测的或经常变化的情况。如果你没有结构化数据，关系型数据库会带来更多的麻烦，因为你需要进行大量的模式更改和/或跳过许多障碍以符合数据结构。
KVP/JSON/NoSql非常棒，因为对数据结构的更改不需要完全重构数据模型。向数据对象添加字段只需要将其添加到数据中即可。另一方面，KVP / Nosql数据库中的约束和验证检查较少，所以你的数据可能会变得混乱。
规范化的关系型数据模型具有性能和节省空间的优势。规范化的关系型数据可以使理解和验证数据变得更容易，因为有表键关系和约束来帮助你。
我见过的最糟糕的模式之一就是试图两者兼顾。试图将键值对放入关系型数据库通常是灾难的开端。我建议首先使用适合你数据的技术。
KVP/JSON/NoSql非常棒，因为对数据结构的更改不需要完全重构数据模型。向数据对象添加字段只需要将其添加到数据中即可。另一方面，KVP / Nosql数据库中的约束和验证检查较少，所以你的数据可能会变得混乱。
规范化的关系型数据模型具有性能和节省空间的优势。规范化的关系型数据可以使理解和验证数据变得更容易，因为有表键关系和约束来帮助你。
我见过的最糟糕的模式之一就是试图两者兼顾。试图将键值对放入关系型数据库通常是灾难的开端。我建议首先使用适合你数据的技术。
- FistOfFury
1
传统的关系型数据库在扩展到一定程度时会出现问题。这个点的具体位置取决于你想要做什么。
所有（大多数？）云计算供应商都提供键值数据存储。
然而，如果你有一个相当规模的应用程序和复杂的数据结构，那么使用关系型数据库可以降低开发成本。
所有（大多数？）云计算供应商都提供键值数据存储。
然而，如果你有一个相当规模的应用程序和复杂的数据结构，那么使用关系型数据库可以降低开发成本。
- Shiraz Bhaiji
1
我想指出，Point非常大，我知道一些多TB的数据库运行得非常好（必须经过正确设计和管理，并且具备正确的硬件才能进行扩展）。 - HLGEM
-5
根据我的经验，如果你在考虑使用传统方法还是新颖方法，那么就选择传统方法。虽然新颖方法很有吸引力、挑战性和乐趣，但99.999%的应用程序都需要采用传统方法。
关于关系型数据库和KV数据库，你应该问自己的问题是：
为什么我不想在这种情况下使用关系模型：...
由于你没有描述具体情况，所以没有人能告诉你为什么不应该使用它。KV的“万能理由”是可扩展性，但现在并不是问题。你知道优化的规则吗？
- 不要这样做。
- （仅限专家）现在不要这样做。
KV是一种高度优化的可扩展解决方案，对于你的应用程序来说可能完全不必要。
- Alex Papadimoulis
3
41这条评论未能回答问题。什么时候和为什么有人会选择使用 KV 存储而不是关系型数据库？ - aridlehoover
1“传统”是什么？随着JavaScript和JSON的兴起，如今有很多程序员从未使用过关系数据库。对许多人来说，noSQL已成为标准而关系型则不是。此外，这并没有回答最初的问题：何时采用关系型数据库是更好的选择？ - FistOfFury
1被踩了。当问题寻求特定的优缺点以使不同的数据库类型更合适时，这是一个捕捉所有答案。此外，键值存储和NoSQL数据库变得太受欢迎，不能被视为“神秘”。 - user3466773
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接