原文地址:http://project-voldemort.com/design.php
翻译:陈臻 http://www.54chen.com 我是陈科学院
版本:1.0
日期:2009-8-25
Key-Value存储
为了实现高性能和高可用性,我们只允许非常简单的键值数据存取。key和value可以是list和map的复杂类型,但美中不足的是只有以下的查询是有效的:
value = store.get(key) store.put(key, value) store.delete(key)
这可不是解决了所有的问题,其实做了许多的取舍:
缺点
没有复杂的查询过滤器
所有的联合查询必须在代码实现
没有外键的结构
没有触发器和视图
优点
只有高效的查询可用,性能是可想像的
容易分布到集群
不管怎样,面向服务常常不允许外键的结构,并且强制在代码中实现联合(因为和数据相关的key这个关系 在另一个服务中维护着)
使用关系型数据库你必须要有一个缓存层用来扩展读操作,不过这个缓存层很典型地强制你使用了key-value的存储系统
为了性能,最后不得不使用xml或者是其他不够正规的一砣文本
使逻辑和存储分离清晰(出于性能原因,SQL鼓励将商业逻辑和存储操作混在一起)
没有对象-关系数据的丢失匹配问题
数据模型的详细的讨论将在下面给出。