2008-01-26 Sat
作者:AnySQL, 发布在anysql.net
不是今天明天后天的那个后天, 而是指美国电影《后天》, 随着全球变暖的加剧, 引起了天气短时间内的急剧降温, 从而进入的冰期. 这几天全国范围内的大降雪, 天气变冷, 原来很少下雪的地方, 都下起了厚厚的雪, 京九线上很多电力线结冰或冻断, 从而电动力火车无法运行, 几十万人滞留不能准时到达终点站, 上百万人出行受影响, 千万人因为没有准备而受灾, 更可怕的是通信设施也没能顶得住考验. 这年还怎么过? 至少怎么和谐地过? 想知道西伯利亚的火车是什么作动力的?
从记忆中, 小时侯天气还是很冷的, 后来一年一年地变暖, 年年下雪变成偶儿下一下雪. 我们只是忘了过去, 默默地接受了不计环境成本带来的经济发展. 当厦门人民成功地移走了一个工厂时, 在南京早就偷偷地建了一个一模一样的, 离我现在住的地方也就20公里, 距长江也就2到3公里, 居民们根本就不知道有这回事, 当然出了事后, 领导作作秀, 说句对不起, 问下温暖, 也就够了.
看来买不到票还不算什么, 很多买了票上了车的正被堵着呢! 公路是行不通了, 飞机也停不下来, 火车也不可靠, 如果春节放得长一些, 还是骑马或驴回家过年吧.
能不回家过年的就别回家了?
相关文章 | Related Artiles
Author:NinGoo posted on NinGoo.net
EMC最新的企业级高端存储DMX4据说将支持SSD(Solid State Drive)固态硬盘,而联想也在最近发布了一款新的ThinkPad X300计划,要和Apple的超薄Macbook Air一争高下,也将采用SSD作为硬盘。看来不管是企业存储还是个人电脑,SSD都开始抢占地盘了。
SSD的单个硬盘的IOPS据称可以超过5w,而目前一个15000转的机械硬盘只能到达150个IOPS左右。当然,5w只是厂家宣传值,在实际应用中肯定是达不到的。据EMC的人说,一个SSD在IO性能上可以相当于30多个机械盘。对于高并发的OLTP系统来说,SSD的诱惑力可不一般了。而且在能耗方面,由于没有机械马达了,SSD也具有天生的优势,在倡导绿色
SSD的寿命受制于擦写次数,据说是200w次,不知道这个数字是说同一个存储位置,还是说整个盘,如果是同一个位置200w次,那没什么问题,如果是同一块盘,对于写入比较密集的系统就有点危险了,毕竟现在SSD盘的价格那还是相当的贵啊。在读密集操作的应用中,SSD应当是比较适用的了,谁有在Oracle生产系统中实际使用的案例么?

Related Articles
I’ve been reviewing our settings for innodb prior to testing our new SSDs drives later this week.
Here are some initial thoughts:
* Both sync_binlog and innodb_flush_log_at_trx_commit should both be enabled. The extra seeks required isn’t really an issue on SSD and the extra reliability is worth the slight performance hit.
* Read ahead for Innodb and the underlying block driver should probably be disabled. There’s no sense reading another 512 blocks in SSD. You can get the IO quick enough so why slow yourself down potentially reading content you don’t need? Innodb use a heuristic algorithm for read ahead but the best it can do is equal the same performance as SSD. At the very minimum disabling disk based read ahead is probably a good idea.
* If your database is primarily small fixed size rows it might make sense to recompile using a smaller block size. SSD performance seems to be a function of write size. If you constantly need to write 16k where 90% is re-written content you’re going to see an effective 4x slowdown. Jeremy Cole mentioned that changing this would bloat the DB. I’ll have to experiment. I’m also going to have to figure out if O_DIRECT can be used with less than 16k block sizes. I don’t think it can.
* The new thread concurrency stuff in MySQL 5.1 is probably going to be very important. There’s no reason multiple concurrent threads shouldn’t be able to mutate and access the DB in parallel since we’re no longer really bound by disk seeks. Letting the DB go full out seems like a big win. This is going to require MySQL 5.1 though which should be available any year now (*cough*).
Given all this, I think performance will still be outstanding for Innodb on SSD but probably a good deal of variability in performance.

2007年12月27日的日本报纸《每日新闻》报道了一则奇闻:福冈县佐贺町一位名叫福岛学的71岁老农,花了15年时间,用嫁接的方法,让一棵30岁的柠檬树结出了11种不同的水果,但这位老农仍不满足,还想继续往上嫁接新品种,把“百果树”的名头发扬下去。
如果这11种水果包括香蕉、葡萄、苹果、草莓等多姿多彩的种类,那么这真可算得上是奇迹了,因为就像马和驴杂交能生骡,马和羊就没法杂交一样,植物中也只有亲缘关系密切的种类才能嫁接成功。事实是这11种水果和作为砧木(被嫁接的母树)的柠檬一样,都是柑橘类水果,比如其中的凸椪(dekopon)是一种橘,晚白柚(bampeiyu)是一种柚,八朔(hassaku)则是一种橘柚杂交品种……那么这还能不能算是奇迹呢?
柑橘类水果都属于芸香科(作调料用的花椒和作草药用的两面针也是该科植物),它的种类很多,除了上面提到的柠檬、橘和柚,还有柑、橙、葡萄柚和枸橼等等。这么多的种类固然大饱了世人的口福,可是却把植物学家愁坏了。到底应该把这一堆统称为“柑橘类”的东西分成几种呢?植物学家为了这个问题争吵了上百年,形成了两种截然相反的观点。美国的施永格(W.
T.
Swingle)是一位农林学家,但对文史也很有研究,曾给美国国会图书馆搜集了不少中国的地方志,在农学界和史学界都算得上名人。在他看来,柑橘类中除了枳(就是成语“南橘北枳”的枳)和金橘之外,剩下的只能划分成16个种,其中还要包括一些野生种。日本的田中长三郎则相反,一口气把枳和金橘以外的柑橘类划成了159个种,光是宽皮橘(就是皮好剥的橘子)就有36种之多!
如此说来,柑橘类有多少种岂不成了公说公有理、婆说婆有理的事了?好在科学的发展总是能出乎意料地解决先前的棘手问题,就好比法国哲学家孔德曾感慨人类永远也不可能知道恒星的化学成分,可是过了还不到三十年,德国科学家基尔霍夫和本生就用光谱分析法分析出了太阳表层的元素组成。同样,在上世纪90年代DNA分析法广泛应用之后,许多以前争论不休的分类学问题都逐渐得到了解决。柑橘类的分类和起源,也慢慢有了初步定论,答案是令人惊奇的——不管是施永格还是田中,都高估了柑橘类的物种多样性,因为除了枳和金橘,剩下的所有柑橘类也许都只是三个野生种的后代!
这三个野生种是枸橼、野生柚和野生宽皮橘,起初只生长于中国南方的茂密森林中,用它们美味的果实吸引动物来吃,为之传播种子。后来,同样沉醉于其美味的人类开始有意地栽培它们。当两个种被栽培在一起时,出于偶然,它们会因相互授粉而发生杂交,把杂交而成的种子种下去,再长出来的果树就会结出口味和原种不同的果实。那些口感独特而优良的杂交品种被心细的农夫保存下来,便形成了新类型的柑橘类水果。受到启发的农夫也会有意进行人工杂交,这使柑橘类的品种愈加丰富多彩。就这样,柚和宽皮橘的杂交产生了橙,所以橙子既有像柚子那样难剥的皮,又有像宽皮橘那样的甜酸味而没有柚子的苦味;宽皮橘和橙的杂交又产生了柑,所以柑皮的难剥程度介于橘和橙之间;枸橼和酸橙或柑的杂交产生了各种柠檬,它们的果汁青出于蓝而胜于蓝,在酸度上达到了极致;柚和甜橙杂交则产生了西方的上层人士酷爱的甜酸苦香齐备的葡萄柚……
为什么柑橘类水果这么受青睐,被培育出了如此众多的品种?这大概是因为柑橘类水果含有大量的果汁,色泽、气味、口感和营养俱佳,而且很容易压榨。人们对柑橘类水果的果汁的酷爱,使这类水果成了世界上产量第一的水果。1997年全世界柑橘类水果的总产量接近8000万吨,而现在,已经超过了1亿吨。其中,巴西是世界上产柑橘类水果最多的国家,年产量在1800万吨左右;我国排第二位,年产1400万吨;排在第三到第五位的则是美国、墨西哥和西班牙。
所以事情很明白了。在一棵柠檬树上嫁接11种柑橘类水果,其实是很容易的事情,因为在嫁接中涉及的真正种类可能只有三个,而这三个种彼此之间显然是高度亲和的。虽然如此,这位孜孜不倦的日本老农,仍然是值得我们敬佩和学习的榜样。
2008.01.22初稿
2008.01.23修改
(《新京报》2008年1月27日,有删节。)
主要参考资料:
1. Situation and Outlook for Citrus.
2. 胡春根. 柑橘遗传多样性的分子评价及起源、分类研究. 博士论文. 武汉: 华中农业大学. 1998.
3. 接ぎ木:レモンの木に11種類の果実実る. 每日新闻. 2007年12月27日.
4. 方舟子. 让我们接近星星. 载方舟子. 方舟子带你走近科学. 陕西师范大学出版社. 2007: 227-229.
It looks like there’s another competitive SSD on the market. The Stec Zeus IOPS.
I foolishly dismissed this drive before because I thought they weren’t disclosing their write rate (which all the other vendors are doing to lie about their performance).
Turns out they’re claiming 200MB/s with 100MB/s write throughput. If these numbers are accurate the then this would be 2x faster then the Mtron SSDs.
Storage Mojo has additional commentary. They’re comparing these drives to the RamSan which is not a fair comparison since this is a DRAM based SAN device. The RamSan-500 should trounce everything on the market but the pricing is astronomical.
The key win for SSDs is that they’re cheap and will soon be commodity. By mid-2008 I imagine 20% of the laptop market will be using SSDs and vendors like Toshiba, Samsung, Stec, and Mtron will be feverishly attacking each other in the enterprise market.
The key here with the Zeus will be price per GB. The Mtrons are about $15 per GB which is the price point I’m looking at for real world horizontal/diagnol scaled applications.

好不容易见到了同学,在北航毕业以后就没有见到了, 真想不到还能在圣安东尼奥遇到,看来世界还真是不大啊。 在他们家吃了烧烤, 然后就睡他们家了。 第二天去看了看那里据说很有名的riverwalk, 同学还特地给我从网上搜索了介绍打印了出来给我看, 还是中文的, 上面写着: “圣安东尼奥的river’walk, 旁边有很多餐馆和酒吧, 其实就是一条小破河……”
不过去了以后发现其实还是挺好的, 完全不像美国的城市, 颇有欧洲的感觉, 美国人都说这个地方是美国的威尼斯。 同学都已经来了这里一年半了, 还没有来过这个著名的riverwalk玩过呢, 跟我以前的北京的同学在北京住了二十年都没有去过长城估计是一个道理, 但是也有可能是收到了“小破河”介绍的影响, 哈哈。 后来上了一条环绕小破河一周的小船, 开船的人为了小费, 从一上船开始就玩命的讲笑话, 拼命逗大家开心。 但是我就总是感觉他和新东方的老师一样, 一个笑话都讲过150多遍了, 每天在这个小船上对不同的人说同样的笑话。

其中一个真实的故事最牛逼, 让我这样不懂艺术的人尤其开心。 他说到了岸边上一个火炬, 实际上是个雕塑作品, 据说是象征着墨西哥人民和美国人民的友谊 。 他说, 以前每次都将这个火炬, 也没有什么特别的, 但是有一次一个大概七八岁的小男孩在听完后, 怯怯的把手举了起来, 他就问: 小孩, 你有什么问题吗? 小孩说: 其实我也没有什么问题。 然后又不说话了, 开船人就问小孩, 那你为什么举手呢。 小孩终于吞吞吐吐的说, 其实, 其实我就是想告诉你, 上个学期我在学校的手工课上就做了一个火炬, 跟这个一模一样, 结果, 结果只得了一个D!
说到这个小小的世界, 还记得上次说到我们公司在日本招聘了一个京都大学橄榄球队的学生, 然后这个学生一高兴出去和另外一个男生还有女生喝酒结果两个人把自己的女同学强奸的事情。 这次在我们这里的training center, 到了午餐的时候, 见到了一个日本人, 他说他也是京都大学的。 我就说起了这个八卦, 他说, 其实我也是京都大学橄榄球队的, 他是我最好的朋友之一, 我们是一起被招聘到公司的……
考,世界真是疯狂, 由于害怕他就是那天晚上和那个人出去喝酒的男生了, 赶快转换了话题。
作者:Fenng 发布在 dbanotes.net. 订阅 DBA notes
又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下 Yupoo!(又拍网) 的创建人之一的 阿华(沈志华)同学,了解了一些小道消息。
作为国内最大的图片服务提供商之一,Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下:
带宽:4000M/S (参考)
服务器数量:60 台左右
Web服务器:Lighttpd, Apache, nginx
应用服务器:Tomcat
其他:Python, Java, MogileFS 、ImageMagick 等
首先看一下网站的架构图:
该架构图给出了很好的概览(点击可以查看在 Yupoo! 上的大图和原图,请注意该图版权信息)。
关于 Squid 与 Tomcat
Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问,对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统,原来命中率的确很差,后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去,所以命中率彻底提高了"
对于应用服务器层的 Tomcat,现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代,而 YPWS/YPFS 现在已经用 Python 进行开发了。
名次解释:
- YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器,提供基本的 Web 服务外,可以增加针对用户、图片、外链网站显示的逻辑判断,可以安装于任何有空闲资源的服务器中,遇到性能瓶颈时方便横向扩展。
- YPFS--Yupoo File System 与 YPWS 类似,YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。
图片处理层
接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick,在上次存储升级的同时,对于锐化的比率也调整过了(我个人感觉,效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务,可以安装在任何有空闲 CPU资源的机器上,类似 Memcached的服务方式。
我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的,后来被雅虎收购后处于版权原因而不用了;EXIF 与 IPTC Flicke 是用 Perl 抽取的,我是非常建议 Yupoo! 针对 EXIF 做些文章,这也是潜在产生受益的一个重点。
图片存储层
原来 Yupoo! 的存储采用了磁盘阵列柜,基于 NFS 方式的,随着数据量的增大,”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“,看来 Yupoo! 系统比较有信心,也是满怀期待的,毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道,一张图片除了原图外,还有不同尺寸的,这些图片统一存储在 MogileFS 中。
对于其他部分,常见的 Web 2.0 网站必须软件都能看到,如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件,一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。
非常感谢一下 Yupoo! 阿华对于技术信息的分享,技术是共通的。下一个能爆料是哪家?
--EOF--
相关文章|Related Articles
评论数量(7)|Add Comments
本文网址:http://www.dbanotes.net/arch/yupoo_arch.html
最近作者还说了什么? Follow Twitter / Fenng
2008-01-25 Fri
2008-01-24 Thu
AnySQL.net
DBA notes
Oracle & Starcraft
eagle's home
给你点color see see
AnySQL.net English
Oracle Scratchpad
Oracle Life
OracleDBA Blog---我不在江湖,江湖却有我的传说!
Photos from dbanotes
Chanel [K]
xzh2000的博客
Oracle Security Blog
ERN空间
Eddie Awad's Blog
MySQL Performance Blog
The Tom Kyte Blog
del.icio.us/fenng/oracle
O'Reilly Databases
Red Hat Magazine
DBASupport
Pythian Group Blog » Log Buffer
车东[Blog^2]
blue_prince
玉面飞龙的BLOG
此生 今世
人生就是如此
Orange Tiger 木匠 的 移民生活
生活帮-LifeBang
Hey!! Sky!
dba on unix
Oracle Notes Wiki
Welcome to brotherxiao's Home
柔嘉维则@life.oracle.eng
Fenng's shared items in Google Reader
jametong's shared items in Google Reader
缥缈游侠-logzgh
Tanel Poder's blog: Core IT for geeks and pros
DBA Tools
ilonng
yangtingkun
NinGoo@Net
Oracle & Unix
Inside the Oracle Optimizer - Removing the black magic
Ricky's Test Blog
DBA@Taobao
存储部落
Think in 88
