Tag Archives: 分布式存储
LinkIn基于Dynamo设计的系统：伏地魔(voldemort)设计中文文档[我是陈科学院译]-完稿
原文地址：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鼓励将商业逻辑和存储操作混在一起） 没有对象-关系数据的丢失匹配问题 数据模型的详细的讨论将在下面给出。 系统架构 代码中的每层实现了简单的put get和delete操作的接口。每一层都会负责一个方法，诸如tcp/ip网络通信、序列化、版本冲突解决、内部结点路由等等。例如路由层负责发起一个操作，比方说是Put，并且分发给N个存储并行执行复制，同是要捕
为人人设计的分布式key-value系统架构[原创]
[作者：陈臻 转载请注明出处：http://www.54chen.com/714-design-for-all-key-value-of-the-distributed-system-architecture-original/ 版本：1.1 2090810] 8.10 增加dev4server组里esx大侠提出的几个代表性问题 这个架构的产生，是为了公司的一个新项目，而后来慢慢变成了解决整个公司的所有问题的一个架构，期间经yahoo的angentZh先生、dev4server组里张立冰先生、盛大的许式伟先生推荐研究了bigtable、Dynamo等很有代表性的分布式架构。 如下图所示： 总体：底层以key-value存储，每个节点内作主主互备，节点以一致性哈希存取，哈希所使用的key为relation-key，非直接存取时的key。 step 0：连接客户端收到一个key为relatioin-key_id的存取请求，取出relation-key进行一致性哈希计算，这里是为了让相关的内容都能存在一个节点上，类似bigtable的tablet； step 1：连接客户端读取最新的配置文件，server.conf。 step 2：根据配置文件寻找正确的节点。 step 3：在B节点之间增加了一个节点A的时候，A前的虚拟节点将寻找不到数据，此时连接客户端会重新读取老的配置文件server.conf.1，根据老的配置，这里的数据会去B节点读取原来的数据，读到的数据会转移到新增加的节点A中。 step 4：增加节点A后，服务器端会同时运行手动的转移脚本，转移脚本直接将B节点中符合A
SEARCH
Update
- 54chen Twitter memo 2012-02-12
- 人肉解析riak_admin join
- go语言安装手记
- 54chen Twitter memo 2012-02-05
- Riak Core说明
- maven库nexus拖不到jar包小记
- 服务接入层小结
- 54chen Twitter memo 2012-01-15
- nginx防hashdos模块使用帮助
- 54chen Twitter memo 2012-01-08
- nginx防hashdos模块释出
- 54chen Twitter memo 2012-01-01
- 水煮鱼杯2011年度不得不总结的十件事
- 年终攻击hashDos-哈希表多碰撞实现拒绝服务-破解办法
- 54chen Twitter memo 2011-12-25