拜读了关于 LinkedIn 几位工程师写的构建 TB 级的 key-value 系统的经验：Building a terabyte-scale data cycle at LinkedIn with Hadoop and Project Voldemort。具体实现过程有大致的描述，就不鹦鹉学舌了。
其实现在很多公司可能都面临着这个抽象架构图中的类似问题。以 Hadoop 作为后端的计算集群，计算得出来的数据如果要反向推到前面去，用什么方式存储更为恰当? 再放到 DB 里面的话，构建索引是麻烦事；放到 Memcached 之类的 Key-Value 分布式系统中，毕竟只是在内存里，数据又容易丢。Voldemort 算是一个不错的改良方案。
值得借鉴的几点:
关于 key-value 应用的解决方案又多了一种。LinkedIn 对此应用案例也还在发展中。如果业务类型类似，不妨关注一下。
–EOF–
阿里巴巴 DBA 团队 简朝阳的大作《MySQL性能调优与架构设计》已经开始正式上市。我刚认识朝阳同学的时候，他还刚刚毕业，短短两三年后，已经能够独当一面，应该说阿里 DBA 团队是个很锻炼人的地方，当然重要的是他的刻苦钻研的劲头儿。早早就看过他的初稿，这本书是他倾力之作，有理由大力推荐。下文是我前一段时间写的推荐序。
时至今日，恐怕已经没有人再把 MySQL 当成一个玩具性质的软件产品，即使是数据库市场执牛耳者如Oracle公司也不得不正式面对来自MySQL的冲击。如果说几年前，还有人对使用MySQL 有所疑虑么? 经过几年来互联网的高速发展，无数大型网站用其成功案例证明，以MySQL为基础的数据层解决方案已经成为互联网应用不可或缺的一个重要组成部分。
当下也是数据库技术应用处于激烈变革的时期。这并不是说传统的关系数据库技术在这两年有了多大的新突破，而是用户的需求在迅速变化。更多时候，用户不再需要单一的软件产品，而是灵活、高效、可靠、可控、低廉的解决方案。很多大型站点甚至根据自己的需求来改进 MySQL，进而回馈给开源社区，这也是开放的魅力所在，对于传统的商业数据库软件商来说，这是不可想象的事情。
MySQL早已不再是单一的数据库软件，以其为基础发展起来的各种开源组件令人目不暇接，而用这些组件构成的解决方案也是层出不穷。如何能够把以 MySQL为核心的这一系列软件充分运用，构建大型可扩展性网站，正是不少LAMP架构体系的网站开发者乃至架构师一直关心的问题。现在中文图书市场上 MySQL相关的书籍并不在少数，但放眼看去，绝大多数是教程类的内容，这本《MySQL性能调优与架构设计》则主要着眼于性能与架构这两个当下大家更为关注的话题，结合作者几年来的实战经验与研究心得，相信能让不少网站少走弯路。
期待这本书让更多人受益。如果读者朋友们也能把自己的心得分享出来，那是再好不过的事情了。经常有即将毕业的学生以及网络上的朋友给我发来邮件，表示对数据库技术有兴趣，但是不知道如何切入，我的建议是，从学习MySQL开始吧！
–EOF–
到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。
如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。
动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。
Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB
层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好(除非内存小)–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。
很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。
因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。
不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。
有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。
这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。
这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：
发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)
有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。
这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。
–EOF–
很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错，但对我来说，其实冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。
不过，eBay 这次的PPT 总算还是有点更新的。
1）数据分片(Partition Everything)
说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文：开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒进。
从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。
2）异步处理(Asynchrony Everywhere)
其实对于任何网站来说，过度追求”同步”化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计，中间可以最大限度用异步来完成。
eBay 的举例的模式有两个，一个是事件队列(Event Queue)，另一个是信息分发(Message Multicast)。前者基本上是个生产者–消费者的模型。后者主要用在搜索的架构上。
注意到图中的消息总线，这才是 eBay 整个架构中的动脉，估计轻易不会批露技术细节
3）自动化(Automate Everything)
这里的自动化举了两个例子，一个是针对运维方面的，另外举了关于机器学习的东西，这是演讲者 Randy Shoup 的强项所在。
eBay 的自动化，在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视，参见：eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。
4）故障检测与回溯(Remember Everything Fails)
更好的失败检测机制: 监控每天超过 2TB 的日志，根据日志中的相关事件得出判断或者预警。这个看起来简单，但实现起来还是需要一点技巧和策略的，重要的是，需要不断根据结果的反馈去改进。
完美回滚: 任何服务都通过服务配置中的标记来识别，无痛回滚。(个人感觉这个非常有难度，尤其是升级的时候)
优雅降级(Graceful Degradation)：能够相对容易的对应用标记”Marks down（下线）”
5）拥抱不一致性(Embrace Inconsistency)
举了 CAP 原则，程立将其形象描述为帽子戏法，非常准确。说起一致性，自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出，基本上不需要再废话了，这就是事务处理的九阴真经，大家回家慢慢参详好了。
eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性，通过异步事件(消息总线?)达到最终一致性。
–EOF–
另外小道消息：Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。
以前的老帖子：eBay 的Scalability最佳实践