关于 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

关于移动 Web 设计的闲言碎语

前几天 3G 牌照下来，一时间 Buzz 信息很多，不过关于 3G 对 Web 技术影响的分析倒是并不多见。今天再次读了一遍这篇 2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009)，加上这几天在分析使用 iPhone 上的某些 App 设计，还是记录一点笔记吧。

这篇文章提到了如下五点：

简单的可选项(Simple options) 如无必要，勿增实体。基本的、核心功能就行了。
留白(White space) 我觉得 UCWeb 针对 iPhone 的设计就很一般，完全是把 iPhone 当成小屏幕显示器设计的。堆砌的网址站看起来不方便，点击起来并不方便，倒是应该弄个 LOGO 或许更好。
少用图片(Lack of images) 这倒是和上一条矛盾。能少用就少用，而不是不用。而用了图片，如果方式不合适，还不如不用。
用子域名而不是用 .mobi 域名(Sub-domains instead of .mobi or separate domains) 精简域名长度，精简！用 “i.” 就很好，别用 “mobile. “。
内容优先(Prioritized content)

只有设计是没有用的。

我的额外建议：

可点击的目标锚点一定要大。因为你的手指肚更大 :) 如果一个手指尖范围内还有其它可点击目标，很容易误点。最简单的方式就是看看 iPhone 自己桌面菜单设计。而我之所以说 Taobao 商城 iPhone 版设计的不错，也是因为这一点考虑得很地道。Gmail for iPhone 的设计上，用户浏览邮件内容的时候，那个 “Inbox” 的按钮就设计的非常不好。很容易误点击到 “Archive” 按钮上。
分页设计 对于分页的链接，一定要隔开一些，如果”上一页”、”下一页”挨在一起，用户会很困扰。毕竟，手持设备没有鼠标，用户不可能具备”精确点击”的能力。
登录框设计 在 iPhone 上登录某些站点是非常痛苦的一件事情。可考虑的事情：如果用户 ID 是邮件地址的话，是否考虑无需用户输入”@” 字符? [iPhone 2.2 固件已经改进了许多]

另外，2009 移动 Web设计趋势 (Mobile Web Design Trends For 2009) 还提到了设计中的常见挑战以及需要慎重考虑的地方，这篇文章信息量还是挺大的。

–EOF–

唠叨完了，发现基本上是针对 iPhone 说事儿的，我还不是标准的移动互联网用户。

Cookie, iframe 与 P3P 的那点事儿

且说我使用有些网络服务的时候常常能遇到比较怪异的问题。昨天在某个页面遇到个 Redirect Loop 错误提示：

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

同样的问题，同样的页面，同样是 Firefox 浏览器，以前就遇到过，提交给相关负责人之后没了响应，后来也忘掉了。同事说是我浏览器版本的问题，后来发现这和”是否接受第三方 Cookie” 的设置有关：

[x] Accept cookies from sites
[ ] Accept third-party cookies

我的浏览器不接受第三方 Cookie。设置接收后该页面显示正常。

搜索了一下，发现之所以该页面是这样，还是因为页面用了 iframe 而导致的问题，比较通用的办法是设置 p3p http header 。

这个 P3P(Platform for Privacy Preferences Project)，要搞明白，可真是有点小孩没娘，说来话长。简单的说，就是个协议，通过其声明它是好人，允许我收集浏览器用户行为吧… 可现实中，大家都可以说自己是好人，背地里没准儿干啥坏事呢。这就是其分歧所在。[参考] 国内多数网站，都不关注这个 P3P。隐私问题可能没国外(微软的隐私声明)重视吧。

再说 Firefox ，过去的几个大版本中，对 Cookie 的处理方式还是有很大变化的。

这个问题影响最大的还是 Facebook 等开放平台的应用，使用了 iframe 就会遇到(eg: FriendFeed 遇到过，估计还比较头疼)。

对于浏览器来说，第三方 Cookie ，默认情况下，浏览器接受与否，是个大问题。如果不接受，会给很多用户带来混淆，如果接受，则在隐私问题上，有很大的挑战。

实际上，Firefox 的开发者在这个地方的处理方式也在摇摆当中(参见), 不过能确定的是 “the ability to make decisions based on p3p policies was removed for firefox 3″。

各家浏览器在这个地方都可能有 Bug。比如 IE7 曾经有的 Cookie 问题，IE8 Beta 也有类似问题。

或许，最好的办法就是别去种这个 Cookie 了… 网站开发者，你们愿意么?

–EOF–

另请参见文本后面 axis 同学的留言。

豆瓣新九点

看到了豆瓣内测中的新的九点服务。从老的九点，到广场，再到重新上阵的九点，我们多少能看出豆瓣团队在去中心化路上的挣扎。豆瓣对中心化的内容非常反感，但任何一个网站，必然要存在中心化内容，如何把这部分内容让有需求的用户有效获取才是网站设计者需要做的地方，人为的打造或者误导用户看到一些伪中心化内容则是不可取的–这也是国内其他站点所一贯采取的方式，美其名曰–网站运营。

新的九点直接划了四个频道: 文化、生活、科技、趣味，代替原来需要猜谜的四套、二套等是个不算改进的改进，对于任何功能，不应该挑战用户理解力，好的应用必须能适应 80% 的大众用户，另外的 20% 所谓高端用户其实会有自己的玩法。

新的九点，我建议应该把读者对内容的反馈(如推荐语, 评价)有效展现出来。这也是旧版九点我一直不太满意的地方。比如如果有人推荐了某篇文章，并留下了评价的话，我期待的是这个交互内容能被用户有效的获知。但旧版九点基本上只能看到推荐人数，看不到推荐语–推荐语在广播那边，这就抑制了用户的互动性质。现在的九点，看上去仍然像一份电子报纸。我期待能更好玩一点。

今天在奇遇花园咖啡馆和詹膑、郝培强聊天也提到了豆瓣新九点，说起抓虾和鲜果的类似页面，我也表达了同样观点。网易的新闻其实是个很好的借鉴模式。尽管这个聚合页面是抓取来的内容，但是应该允许用户进行方便无痛的反馈，这部分内容如果要提供给内容提供者也并不复杂，开发一个 Widget 脚本就几乎可以了。这样的做法其实也会给 Blog 作者带去一定的流量，如何判断一个聚合应用是否会受到内容提供者欢迎? 能给他们带去流量才是王道。

新九点似乎也在尝试增强阅读器的功能：

我更愿意把这个功能看作九点对用户关心内容的另一个角度展现。

豆瓣去年的每次改版都引起用户不小的反弹，这或许某种程度上说明对产品不同方向的尝试。这次新九点应该骂声会小很多。或许，现在的九点仍然还在继续进化中，但不管怎样，还是期待能有一个适合国内用户的 Digg + Techmeme 产品的出现。

–EOF–