Tag Archives: Twitter

暂缓迷恋 Cassandra

最近 Twitter 和 Digg 的技术团队都放出话来说要从 Mysql + Memcached 的组合迁移到 Cassandra 环境（Refer 1、2)，这些消息又会让不少人跃跃欲试，恨不得也把自家网站迁移到 Cassandra 下面过把瘾，我相信有些公司的团队又要言必称 Cassandra 了。

Twitter 和 Digg 对数据存储引擎的需求相当独特：写操作密集，基本无修改需求，读操作则多数是分散多次读取汇总展示(想象一下你 Twitter页面上同时显示好友们的 Tweet 内容)。对 MySQL 来说，Sharding 后几乎是被当作简单的存储引擎来用的，即使是加上 Memcached ，对数据读取开销相当大(Refer)，因为这时候即使是最合理用索引，I/O开销也不是最优的–走的是索引范围扫描嘛。Cassandra 则相当于预存了计算结果，这要得益于其 Flexible schema 特性，按照既定规则写入，读取直接取预排序的范围键值结果(这其实是偏 OLAP 的应用，而非 OLTP)。

Twitter 和 Digg 这两家网站的数据结构其实并不复杂，尤其是 Twitter ，相当的简约（当然并不简单）。或许有人说，把 Cassandra 开源的 Facebook 不也在用呢吗 ? Facebook 数据结构不复杂么？没错，Facebook 数据结构很复杂，不过使用 Cassandra 的场景其实和 Twitter / Digg 几乎一致的—只是用在 inbox 这个地方的数据处理而已。

不要迷恋 Cassandra ，如果应用场景不合适，那么对你来说永远都只是个传说。。

–EOF–

企业员工应遵守的 Twitter / 微博 准则

在 Twitter ( @Fenng )上发布了几条关于 “员工应遵守的Twitter 准则” 的建议。如果你也是 Twitter (或微博) 用户，以下这几条准则或许可以用来参考：

准则一：不要发布不为公众所知的和公司相关的业务数据。如果要引用公司的公开数据，不要加主观的断言。对于关注你的人来说，小道消息并非那么有价值。

准则二：不要匿名攻击公司(包括自己的雇主和竞争对手)。尽管”在互联网上没有人知道你是一条狗”，但是，雇主还是很容易知道你是公司里面的哪一位。

准则三：Twitter 上的信息具有不可修改性，被转发后会引来不同的解读。所以发布消息前要衡量是否会对同事或团队造成负面影响。如果回答为”是”，不要发布。

准则四：倾听用户的声音，收集用户反馈而不要和用户争辩，如果能够解释，进行必要的解释，但是记住不要推脱责任，尤其不要攻击或是嘲讽用户。

准则五：如果你的主管或同事不能理解或者认可Twitter会对公司带来的价值，向他们解释，同时最好能证明使用 Twitter 并非是在浪费工作时间–用 Twitter 或许比用 IM 更节省时间。

准则六：必要的时候尽可能转发对用户的警示信息，比如”系统维护公告”或”费用调整”等信息应更快更及时的传递给用户。

准则七：团队的内部规划，正在进行的项目及相关实施细节，未经相关负责人允许也尽量不要披露，以免带来各种不可预期的不利影响。

很多人在 Twitter 上发消息，不可避免的会提及自己的雇主。新用户或许意识不到 Twitter 对消息传播的便捷性会带来的破坏力，如果没有一个类似指导原则的话，可能不经意间就会对雇主造成负面干扰，也会给自己带来一定的麻烦。这里的准则或许不能覆盖所有的情况，所以更多的时候要依赖于常识来判断。

如果你在鼓励同事或者朋友来用 Twitter 或者其它微博，要向他(她)说明这些。( 感谢 @hutuworm 同学贡献了准则七)。

–EOF–

从 Twitter 运维技术经验可以学到什么

没有一个网站的性能像 Twitter 这样这么令人牵肠挂肚，看见那条大鲸鱼总是让人感觉很无奈。Twitter 的运维专家 John Adams 在 Velocity 2009 上做了一篇题为 Fixing Twitter 的技术分享(PDF)，人家也是一直在努力阿。John Adams 在 2008 年七月加入的 Twitter ，对于 Twitter 的站点稳定的确做了不少工作。

Twitter 运维团队的职责：

  • 软件性能(后端) Software Performance (back-end)
  • 可用性 Availability
  • 容量规划 Capacity Planning (metrics-driven)
  • 配置管理 Configuration Management

看完这个接近 50 页的 PDF ，除了满足我们一小部分技术窥探的癖好，或许也可以学到点什么。

不重复发明轮子

对于监控，Twitter 用的就是 RRDtool，Ganglia、MRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是， Twitter 也一直在用 Google Analytics 进行业务分析。

不重复发明轮子，可以打磨轮子，比进行如一些功能脚本定制之类的工作。

发明不重复的轮子

Twitter 开源了他们自己用的一个 Apache 模块 mod_memcache_block（a distributed IP blocking system），这个模块根据 HTTP 代码请求限制访问频率。熟悉 Twitter 的朋友会知道这是针对第三方应用程序的必须的一个功能，否则的话，会产生类似 DDos 的效果 :) John Adams 说这个模块是他多年以来就期待的东西，我相信，如果有人已经做了同样的事情，他们肯定不会自己再写一个。

尽可能的自动化

无论是配置管理还是针对各项功能的”开关”，都尽可能的自动化。依赖于人来控制一些事情容易”规范”，但是流程冗杂，节奏变慢。

更好的理解硬件

拥抱新技术体系，使用更有经济效益的硬件(比如对 8 核 CPU 的选型与更换)会带来更好的收益。而这个要建立在对硬件体系的正确理解上才行。

另外几句话要记住：

  • Disk is the new Tape. (内存是新类型的磁盘. 磁盘是新类型的磁带)
  • Kill long running queries before they kill you. (问题是如何提前发现? 有效的监控!)
  • Use metrics to make decisions, not guesses.
  • “Cache Everything!” not the best policy

或许还应该学到更多…

–EOF–

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

关于信息的五分钟问题

最近一直在考虑这个关于信息的”五分钟”的问题。搜索了一下，发现还很少有人考虑这个现象，思路还没有完全理顺，先抛几个观点等待大家的补充吧，期待能引发一些对信息处理的思考。

最早注意到这个现象是每次我 BLOG 更新之后，在大约 5 分钟左右，通过 Google 的 BlogSearch 就可以看到内容。这个倒很容易理解，因为我用的 Movable Type 在发布文章的时候会自动通知一下 Google 服务器。接到通知之后，Google 能够较快的把信息合并(Merge)到当前的索引中，但是应该还没加上非常严格的排序(Sort)，这是个很经典的处理技巧。

不过，Google 获得信息绝大部分是通过爬虫”抓取”，也就是”拉”(Pull)数据，只有少部分是用户”推送”(Push)的。这就导致 Google 在信息处理上节拍总要慢一点。Google 的目标是处理地球上的所有信息，无远弗届，但信息的及时性或许是最难解决的。

而 Facebook / Twitter / FriendFeed 等具备面向”实时信息流”(Real Time Lifestreaming)功能的网络应用，大部分信息都是用户”推送”上来的，所以也有天然的优势触及这五分钟之内的数据，并经过简单的局部计算之后呈现给用户。得到”即时”信息似乎是人的天性（另一个侧面的印证是人们无法摆脱手机而全部使用 IM 和电子邮件），所以五分钟之内的数据处理能力是对普通用户来说有着难以言明的吸引力。

“五分钟”只是个大致的说法，相信随着技术的发展，会缩短到三分钟，乃至更短。但这部分始终是 Google 无法完全覆盖的地方，技术没办法打败时间，这也是信息暗网的也无法解决的问题。最终我们发现，信息处理的巨人和信息处理的快刀手一起相处的比较融洽。

–EOF–

注：很明显，这个”五分钟”问题和我之前说的关于 I/O 的五分钟问题是不搭界的。