Hunter的大杂烩 技术学习笔记

2009-01-17

A Word on Scalability

Filed under: 架构 — hunter @ 11:19 pm

from: http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html

Amazon CTO对伸缩性的解释

What is it that we really mean by scalability? A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to resources added. Increasing performance in general means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.

   — 简单说,系统的吞吐和性能能随着投入的服务器资源数量的增加而成正比的增加

(more…)

2009-01-08

优化使用BigTable的原则与方针

Filed under: 架构 — hunter @ 8:53 pm

BigTable的使用原则处处透着Web 2.0的设计原则,也是BASE原则的体现(牺牲一致性),BASE原则是Web 2.0设计的高度抽象

 ================================================

从围绕着Google App Engine的大量讨论中,Todd Hoff总结出了一组优化使用分布式及高可伸缩性存储系统——如BigTable——的指导原则Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价,只有在以下情况下使用BigTable才能带来益处:a)需要伸缩到巨量的用户数,b)更新与读取操作相比比例很小。Todd还着重强调为了“优化读取速度和可伸缩性”,所采取的理论路线与关系数据库中的做法存在根本的分歧,很可能初看起来是违背直觉甚至相当冒险的。关系数据库的世界是以防止错误为根基的;以正规化(normalization)为工具消除重复和防止更新异常。为了提高可伸缩性,数据应该重复而非正规化。Flickr久悬着了这种路线,决定让“评论重复出现于评论者和被评论者两个用户数据分片中,而非单独建立一个评论关系”(hunter:绝!),因为“如果把用户数据分片作为可伸缩性的单元,就没有地方放置这种关系”。因此,虽然去正规化(denormalization)违背了“关系数据的伦理”,但它是BigTable数据范式不可缺少的组成部分。

(more…)

2008-10-23

构建的可伸缩性和达到的性能:一个虚拟座谈会

Filed under: 架构 — hunter @ 11:52 pm

from: http://www.infoq.com/cn/articles/scalability-panel

简摘:

问题1:许多人把性能和技术混为一谈。你们怎么回应这种误解呢?

…性能是服务于一个单独请求时的资源使用问题。可伸缩性是当要服务更多(或更大)请求时资源消费量如何随之增长的问题…

 — 这里可能有一个笔误,应该不是“技术”,而是“可伸缩性”

问题2:当你碰到性能瓶颈时,你如何开始调查是什么导致了这一问题?

通常是一个搜集观测资料(即,与许多人进行交谈)并缩小问题范围的过程..

…直觉(快速但不可靠,而且容易产生错误)和监测(需要预先的工作,但是这能让你随心所欲地分析问题)..

  — 我们一般会做较多的log和监控

(more…)

可伸缩性原则

Filed under: 架构 — hunter @ 11:03 pm

from: http://www.infoq.com/cn/articles/scalability-principles

来自Simon Brown的笔记:

1. 减少处理时间

    并置(含义):将相关数据放到一起

    缓存

    池化

    并行化

    分区处理

    远程处理:

          减少访问远程服务所花费的时间,比如可以通过更粗粒度地划分接口。远程还是本地是明确的设计决策,不能随意来回更动,这一点应当牢记。还要考虑分布式计算的第一准则——不要分布你的对象

            ^^^^^^^^^难难难,如何平衡,还在探索中 

          …尤其是在每层的数据表示之间都需要转换的情况下…

                                       ^^^^^^^^^^^^PO 2 DO ?

(more…)

2008-07-15

Federation at Flickr: Doing Billions of Queries Per Day

Filed under: 架构 — hunter @ 11:28 pm

近期highscalability上有一篇文章,介绍了由flickr的数据库高人撰写的flicker的数据库设计,作者说,如果你想知道自己的sharding是否做对,一定要拜读该文。(ppt的title中赫然见到”Federation”一词,难道又会创造一个Federation热吗?) (另,这个ppt里其实没有很多有用的内容,可能更多是通过口头表达的)

flickr架构就不多说了,可以参见highscalability.com的文章 dbanotes上的介绍

ppt主要介绍flickr 遇到的几个问题,以及是如何解决的:

1. mysql master-slave 拓扑问题

将数据sharding分布

建立master-master ring来解决写入的问题

 — 据作者说是为了解决写入点的问题,但是master-master ring可能会使得数据库的写请求量过大,影响读请求的服务

(more…)

« Newer PostsOlder Posts »

Powered by WordPress