分类归档: Tech.Memo

关于信息的五分钟问题

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

最早注意到这个现象是每次我 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 的五分钟问题是不搭界的。

关于 IM 工具的”群”

在我看来，如果要评选一个IM 工具的功能「更影响沟通的有效性、更能浪费生产力」的话，恐怕非「群」莫属。

昨天在 Twitter 上发了一句对「群」这个玩意儿的牢骚，引来了不少朋友的回复，大部分朋友对「群」还是深恶痛绝的，云风随后写了一篇《关于「群」的那些破事》叙述网易泡泡的群功能出炉的来龙去脉。

经常看到有讨论技术的人会开很多 QQ 群，然后一大堆人加入，我最不屑这样的讨论技术的方式，我不相信有谁通过 IM 群学会了很多东西，当然，他们浪费了很多宝贵时间我倒是深信不疑的。所以不乏偏激的说：

喜欢用群的人都是喜欢用开会来消磨时间的。他们享受群，认为那东西理所当然的是「群」的沟通工具。我也赞同群里面90%都是一些垃圾信息的说法。小笑话、新闻链接、有趣的小图片占据了这 90% 的大部分内容。

这样的说法如果也在内部会议上提出的话，估计也要像 Tim Yang 那样遭受一片嘘声。（我不排除有人把「群」用的出神入化，比如昨天就有一位互联网大佬给我讲述他当年用群的功能做推广的案例，但这只是个例）。Twitter 上就有不少人不同意我的说法：

“吾之蜜糖彼之砒霜，QQ 群用的人那么多，凭什么说人家烂？不适合罢了”

也有朋友给出了建议:

  • 建议用临时会话，说完正事就退出。(refer)
  • 群的成员不应该是固定的。（refer)
  • 做个Twitter进化的桌面IM…

现在的群，如果非要继续沿用的话，改进的余地还有很大。产品经理请注意，下面是可以给你带来业绩的地方：学习 Twitter 风格的对话模式，针对每一条信息有上下文，便于群内的参与者能够知道信息的指向(这是非常关键的一点，否则就是乱七八糟胡乱抢话筒的会议而已)。第二，设计一个可以将”会议”记录发送到指定电子邮件的功能(这应该并不复杂)。学学 Gtalk 的优点应该不难吧?

欣喜的看到网易已经用不许员工上班时间用群了，这是个伟大的决定。

–EOF–

（注：众多推友对此文亦有贡献)

关于 SSD 的闲言碎语

前不久写给《程序员》的一篇文章里，个人预测在 2009 年，SSD (Solid-State Drive，固态盘) 在企业级市场能大展拳脚。上周参加了 EMC 的一个会议，提及了 SSD ，EMC 存储产品对 SSD 的引入也有一年了，做点 SSD 的科普知识应该是有必要的。

Wear Leveling

很多人对 SSD 的误解是：既然你可擦写次数有限制，比如 200 万次，那么不是没几天不久坏掉了，怎么说使用寿命还比物理硬盘长呢?

Wear Leveling 是有效提升 SSD 的 MTBF (Mean Time Between Failures)的一种技术手段。我们都知道木桶原理，对 SSD 硬盘也是这样，如果不停的对某个 Cell 擦写，那肯定很快就报废。 Wear Leveling 的基本思想就是利用算法保持所有的可擦写单位的次数是近似均匀的，这样就把写次数均匀的分散到各个 Cell 上。

Wear Leveling 翻译似乎还没有统一，有翻做均匀磨损、磨损分级、换位写入等。

对 Wear Leveling 粗略一点的描述大致是：假设更新某个数据块，假定8KB ，而可擦写块(erase block)是 256 KB，那么定位到当前数据位置后，将找个没写过或者写过次数更少的可擦写数据块写入，并不是对原来的位置反复更新。Wear Leveling 算法的效率直接影响 SSD 的寿命。

而 8K 到 256 KB 这个过程实际上是加大了 I/O 操作，称之为 Write Amplification (写放大)。当然 SSD 厂家另有其他技术尽量减少写的频率。

为什么 SSD 写入速度相对较慢?

用一句话解释：擦写块(erase block)比较大。

很明显这样做的目的是减少擦写次数，提升 SSD 寿命。但也影响了数据写入速度。

为什么 SSD 容量是 2 的幂次? 比如 32GB，64GB

这个我也不甚了了，猜测是因为 erase block 多数是 2 的幂次的缘故。物理硬盘的尺寸由来我也不甚清楚。

SSD 的擦写次数是不是致命的瓶颈 ?

这个问题太容易给用户带来疑惑。个人认为要依赖应用的特点和设计。对于合适类型的数据，基本不是问题。但对于某些特定的数据类型，那可能是灾难(比如数据库的 Redo Log)。

SSD 会给数据库应用的银弹么?

是曙光，但不会是银弹。对于密集写入的数据库应用来说，SSD 可能不会带来更多的好处。但是对于密集读的应用，那是有可能带来数量级上的性能提升。在未来若干年内，好的数据库应用仍然严重依赖于设计人员的能力和数据库管理员的优化技巧。

此外，还要期待数据库厂商针对 SSD 进行软件级别的优化。

是否从现在选择 SSD ?

典型的废话答案应该是：这取决于你的具体情况。

要看性价比，EMC 最早引入的 SSD ，性能是普通硬盘的 30 倍，价格大约也是 30 倍。而现在，在企业级市场，SSD 已经降到大约 10 倍普通硬盘的价格。如果再低一些，那绝对是比较有吸引力的。

–EOF–

其中观点仅供参考。SSD 有风险，玩家谨慎操作。而这篇文章中的有些观念有实效性，细节也可能不够准确。

Note: 这里的 SSD ，是说面向企业应用而不是面向个人消费品的。

再增加一个图：
SSD vs. HDD.png

Linux 的一点杂记

Q: 环境变量 LD_ASSUME_KERNE 是干啥的?

A: 动态连接器（dynamic linker）决定使用哪个操作系统 ABI (Application Binary Interface) 库的。LD_ASSUME_KERNE 的值要设定为操作系统版本号。比如 2.4.1 。更多参见 Metalink 文档：433292.1 。

Linux 有些版本的严重 Bug：GLIBC: calloc() Breaks when Application Runs with Locked Process Address Space

补充：在 Glibc-2.5-20 以上版本修复。各发行商有单独的版本。RHEL 4.x 中在 4.7 以上修复。不过 RHEL 4.7 Kernel 也有问题。

RHEL 5 特性几个值得关注的点

其中一个是 Root device MPIO support，尽管可能没有人会在根设备用 MPIO. 另外一个是 I/O-AT 的支持，I/O-AT 是 Intel 的网络加速技术. 第三个是 Dynamically switchable per-queue I/O schedulers 。

零星记录的一点东西，以后想到什么再补充。 另外，推荐一下 hutuworm 同学的 BLOG 。很有嚼头。

–EOF–