随笔分类 -  分布式

摘要:对Megastore做了简要的笔记,语言通俗易懂些,只关注了一部分,比如数据模型,如何解决应用对数据的需求,join的处理,事务机制等。摘要开发Megastore是为了满足现在的交互式在线服务的需求。它混合了NoSQL的可扩展性和RDBMS的方便性,从而既提供了强一致性也提供了高可用性。它在数据分区内实现了完全的串行化的ACID语义。This partitioning(分区方法) 允许我们在不同的数据中心之间同步的复制每次写,并且有较好的延迟,同时能够支持数据中心之间的无缝故障恢复。这篇文章描述了Megastore的语义和复制算法。也描述了google在使用Megastore方面的经验介绍交互 阅读全文
posted @ 2012-01-08 14:49 吴镝 阅读(706) 评论(0) 推荐(0)
摘要:转载自:http://timyang.net/architecture/yahoo-pnuts/在分布式领域有个CAP理论(Brewer’s CAP Theorem) ,是说Consistency(一致性), Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点,没法三者兼顾。所以架构设计师不要把精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍,选取最适合应用需求的其中之二。比如MySQL 5.1 cluster设计前显然不知道有CAP理论这样的经验, 所以MySQL cluster表面看来尽管可提供所有分布式特性 阅读全文
posted @ 2012-01-07 15:42 吴镝 阅读(516) 评论(0) 推荐(0)
摘要:疑点已标红BigTable 是的数据模型类似于mysql中的表,只是每个cell可以有多个版本。(rowkey,column key, timestamp) 唯一的决定一个 value,每个value就是一连串的Bytecolumn key的结构是column family:qualifier,co... 阅读全文
posted @ 2012-01-06 21:31 吴镝 阅读(2311) 评论(0) 推荐(0)
摘要:疑点已标红,基本都是多客户端并发追加相关。设计假设:1 系统构建在成百上千台机器上,节点故障是常态2 系统需要存储很多大文件,大概百万千万级别,每个文件大约100MB或者更大。GB级别的文件很常见,应该被有效管理,需要支持小文件,但是不必做优化。3 workload主要由两种读操作组成,1.小量数据随机读,每次从文件的某个偏移开始大概读几KB2.单次读操作 读上百KB甚至1MB或更多,来自同一个客户端的连续读通常读文件的某一个连续的区域。对性能敏感的应用程序通常batch它们的小量随机读操作,对读操作进行排序,offset由小到大4 workload还有两种写操作组成: 1.追加写,大小和读差 阅读全文
posted @ 2012-01-05 17:34 吴镝 阅读(2276) 评论(1) 推荐(0)
摘要:用户编写Map和Reduce函数,Map函数的调用是针对一对<k,v>的,即如果输入有5对<k,v>,那么Map函数就会调用5次。对于每一次: 输入一对<k,v>,然后进行某些用户定义的操作,可以emit 出 一对或者多对的<k,v>这些Map函数输出的<k,v>写到本地的内存中,周期性的,这些内存中的数据对被写到本地磁盘上。Reduce函数的输入是< k,list<v> > ,即相同的key的value会被串在一个list里面。然后Reduce函数对于每条这样的输入进行某些用户自定义的操作,典型情况下,对于一 阅读全文
posted @ 2011-12-25 22:27 吴镝 阅读(853) 评论(0) 推荐(0)
摘要:原文地址:http://dbmsmusings.blogspot.com/2011/12/replication-and-latency-consistency.htmlCAP:在出现网络分区的时候,在consistency和availability之间做tradeoff而在系统处于正常状态的时候,我们也需要对consistent和latency之间做tradeoffagreement也叫做consensus有三种做replication的技术:1.数据的更新同时被送到所有的replicas。 如果更新不是首先通过一个预处理层或者通过某种agreement协议,那么replica之间就会出现不 阅读全文
posted @ 2011-12-25 21:04 吴镝 阅读(649) 评论(0) 推荐(0)