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

以我的经验,如果你甚至在问是否使用传统与深奥的实践,那么就去传统。虽然深奥的实践是性感、富有挑战性和趣味性的,但99.999%的应用程序需要传统的方法。

关于关系vs千伏,你的问题是 应该 问是:

我为什么要 不 希望对此方案使用关系模型:…

既然你没有描述过这个场景,任何人都不可能告诉你为什么你不应该使用它。Kv的“一网打尽”原因是可扩展性,这现在不是问题。你知道优化的规则吗?

1. 不要这样做。
2. (仅供专家使用)现在不要这样做。

千伏是 高度地 针对可扩展性的优化解决方案,对于您的应用程序来说很可能是完全不必要的。

关键值、继承性、映射减少或图形数据库系统更接近于实现策略,它们与物理表示紧密相连。选择其中一个的主要原因是,如果有一个令人信服的性能参数,并且它非常适合您的数据处理策略。注意,对于这些系统,特别查询通常不实用,最好提前决定查询。

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

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

如果您的数据只是一个事物列表,并且您可以为每个项目派生一个唯一的标识符,那么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,那么您可能需要一个关系数据库。