何时可以在关系数据库上选择键值数据存储？决定一方或另一方需要考虑哪些因素？什么时候混合最好的路线？如果可以,请提供示例.
键值,层次,地图缩减或图形数据库系统更接近实施策略,它们与物理表示密切相关.选择其中之一的主要原因是,如果存在令人信服的性能参数,并且它非常符合您的数据处理策略.请注意,即席查询通常对这些系统不实用,您最好提前决定查询.
关系数据库系统试图将逻辑的,面向业务的模型与底层物理表示和处理策略分开.这种分离是不完美的,但仍然很好.关系系统非常适合处理事实并从事实集合中提取可靠信息.关系系统在ad-hoc查询方面也很出色,而其他系统则非常糟糕.这非常适合商业世界和许多其他地方.这就是关系系统如此普遍的原因.
如果它是一个商业应用程序,关系系统几乎总是答案.对于其他系统,它可能就是答案.如果您有更多的数据处理问题,例如需要发生的一些事情,并且您拥有大量数据,并且您事先知道所有查询,则另一个系统可能适合您.
如果您的数据只是一个事物列表,并且您可以为每个项目派生唯一标识符,那么KVS是一个很好的匹配.它们是我们在新生计算机科学中学到的简单数据结构的紧密实现,不允许复杂的关系.
一个简单的测试:您能将您的数据及其所有关系表示为链表或哈希表吗？如果是,KVS可能有效.如果不是,则需要RDB.
您仍然需要找到适合您环境的KVS.对KVSes的支持,即使是主要的KVS,也远不及它的用途,比如PostgreSQL和MySQL/MariaDB.
京公网安备 11010802040832号 | 京ICP备19059560号-6 