一致性和原子性
由于我们给数据库做过分片，并且实体的索引可以被存储在和它本身不同的多个分片之上，这样一致性就成了问题。要是进程在完成对所有索引表的写入前就崩溃了，那该如何是好？
2009年06月 存档
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数量的限制，即使头像数量达不到这个极限，也会大大影响存取效率。