Friendfeed的MySQL key/value存储
这是一篇2009年初的资料How FriendFeed uses MySQL to store schema-less data,相信大部分人已经看过了。如Fenng的中文介绍FriendFeed 使用 MySQL 的经验。本文从不同的角度再补充下。作者几个月前也曾经在广州技术沙龙作过一次Key value store漫谈的演讲，许多参会人员对key...
View ArticleClik here to view.
用Twitter的cursor方式进行Web数据分页
本文讨论Web应用中实现数据分页功能，不同的技术实现方式的性能方区别。 上图功能的技术实现方法拿MySQL来举例就是 select * from msgs where thread_id = ? limit page * count, count 不过在看Twitter API的时候，我们却发现不少接口使用cursor的方法，而不用page, count这样直观的形式，如 followers ids...
View ArticleTwitter停用Cassandra原因分析
Twitter在其7.9一篇官方技术博客Cassandra at Twitter Today提到暂停使用Cassandra来代替MySQL存储feed的计划，这是Twitter一个重要的架构策略调整，因为之前Twitter一直是业界Cassandra方向的领头羊。 For now, we’re not working on using Cassandra as a store for Tweets....
View ArticleRedis容量及使用规划
在使用Redis过程中，我们发现了不少Redis不同于Memcached，也不同于MySQL的特征。 (本文主要讨论Redis未启用VM支持情况) 1. Schema MySQL: 需事先设计 Memcached: 无需设计 Redis: 小型系统可以不用，但是如果要合理的规划及使用Redis，需要事先进行类似如下一些规划 数据项: value保存的内容是什么，如用户资料 Redis数据类型:...
View ArticleClik here to view.
为什么长尾数据的翻页技术实现复杂
今天讨论了一个传统的问题，问题本身比较简单，就是针对key-list类型的数据，如何优化方案做到性能与成本的tradeoff。Key-list在用户类型的产品中非常普遍，如一个用户的好友关系 {“uid”:{1,2,3,4,5}}，表示uid包含有5个好友；一条微博下面的评论id列表{“weibo_id”: {comment_id1, comment_id2……}}，一个用户发表的微博id列表等。...
View ArticleClik here to view.
为什么超长列表数据的翻页技术实现复杂（二）
上文为什么超长列表数据的翻页技术实现复杂提到了超长列表翻页技术设计上一些问题，今天讨论下部分解决思路。 前新浪同事 @pi1ot 最近在程序员杂志发表的一篇文章《门户级UGC系统的技术进化路线》也是超长列表的一个经典案例，在正式展开思路之前，我们也不妨了解一下此文所说新浪评论系统的演进思路。 从文中看到几个版本的列表翻页实现方案 3.0版...
View Article
