加入我烧网

2009年12月17日

今后大家可以通过我烧网了解我的博客以及我的最新动态。我的我烧网主页是http://woshao.com/Timandes/。欢迎大家关注我!

认证码:8cf3dc776a84d44020a56a07352b4676

把RSS加入了我烧网

2009年11月20日

我已正式把我的RSS加入我烧网,我的认证字符串为(acc9f9e7ccc7cd4e4b515baeb3c7b29b),大家现在也可以通过我烧网实时了解我最新更新的文章了。

把RSS加入了我烧网

2009年08月13日

我已正式把我的RSS加入我烧网,我的认证字符串为(9a681b2748b9f917ca242161099f4508),大家现在也可以通过我烧叨叨实时了解我最新更新的文章了。

FriendFeed如何使用MySQL存储无Schema数据(三)

2009年06月15日

一致性和原子性

由于我们给数据库做过分片,并且实体的索引可以被存储在和它本身不同的多个分片之上,这样一致性就成了问题。要是进程在完成对所有索引表的写入前就崩溃了,那该如何是好?

阅读这个条目剩下部分 »

FriendFeed如何使用MySQL存储无Schema数据(二)

2009年06月11日

详细内容

实体在MySQL存储在类似下面的表中:

CREATE TABLE entities (

added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

id BINARY(16) NOT NULL,

updated TIMESTAMP NOT NULL,

body MEDIUMBLOB,

UNIQUE KEY(id),

KEY(updated)

) ENGINE = InnoDB;

阅读这个条目剩下部分 »

FriendFeed如何使用MySQL存储无Schema数据(一)

2009年06月10日

背景

在FriendFeed中,我们使用MySL存储所有的数据。随着用户数量的增加,数据库也在不断增长。目前,我们的存储条目数量已经超过了2.5亿,除此之外还有大量的其他数据,包括评论和喜好以及朋友列表等。

随着数据库的增长,我们不得不一而再、再而三的处理飞速成长所带来的伸缩性问题。常见的手法,我们都有过实践,例如使用只读从数据库和memcache来提高读吞吐量,以及对数据库进行分片,从而提高写入吞吐量。然而,随着技术的不断发展,通过扩展已有功能来承载更高流量所带来的问题和增加新功能相比,已经是小巫见大巫了。

阅读这个条目剩下部分 »

加快头像读取速度

2009年06月6日

在头像使用极为频繁的网站上,将头像缓存起来是一种节省Web及IO资源的有效途径。一般的做法是使用反向代理软件,比如Squid。

但是,无语用户如何更换头像,头像的文件名却是确定的,比如head_48×48.jpg。这样就与Squid的缓存机制产生了冲突,总不能要求每个更换了头像的用户都等48小时后才能看到自己的新头像吧?^_^

阅读这个条目剩下部分 »

头像文件的处理与保存

2009年06月6日

一般来说,头像文件是各种以用户为中心的网站必须要处理的。建站初期,头像文件大多以

http://www.xxx.com/heads/1.jpg

的形式保存,xxx.com代表网站的域名,1.jpg代表用户ID为1的用户的头像。这样做的坏处显而易见,当用户数量超过heads目录能够有效保存的文件数量极限的时候,对于头像的存取将及其缓慢。所有的操作系统都有directory下file数量的限制,即使头像数量达不到这个极限,也会大大影响存取效率。

阅读这个条目剩下部分 »

随机文章的缓存优化

2009年06月2日

带有随机性展示的文章历来不被网站设计人员喜爱,原因主要在于实现的难度和优化机制的设计。理论上来说,随机性展示的文章列表是不可能进行优化的。但是实际上,很多网站都使用相对短一些的缓存过期时间来尽可能解决随机性与优化之间的矛盾。使用这种方式,访问者在10s(甚至更短的时间)之内,看到的随机文章列表的内容是完全一样的。最近考虑到一种方法,在不缩短缓存过期时间的情况下,使访问者在缓存过期时间之内随机看到更多的文章。

阅读这个条目剩下部分 »