关于OakTable Network –TOP 前言摘录

OakTable Network本身就是一群喜欢相互讨论并和有类似想法的朋友交往的人。更确切地说,是一群致力于对Oracle数据库技术进行科学探讨并爱追根究底的家伙。

这一切都始于1998年的某个时候,那时一帮Oracle专家,包括Anjo KolkCary MillsapJames Morle和其他一大群朋友开始每年以各种借口进行一到两次聚会。每个人都会带来一瓶苏格兰或波本威士忌,作为回报他们也赢得了在我家里某些地方打地铺的权利。
大部分时间我们围着餐桌闲坐,周围布满了电脑、网线、纸和其他一些东西,讨论Oracle,聊聊趣事,使用数据库领域新的并且更优异的方法做实验。在2002年的春天,所有条件更加成熟。一天夜里,我意识到我有16位世界知名的Oracle科学家闲坐在我的餐桌旁。我们三四个人挤在一个房间睡觉,甚至不得不在早上借邻居的淋浴。Anjo Kolk建议我们把自己叫做”OakTable Network”(名字来源于我的餐桌),大约两分钟以后,我们注册了域名http://www.OakTable.net

James Morle 现在和他的妻子Elain一起维护这个网站,虽然或许网站没有像预期的那样保持经常更新,但至少可以用来提供链接、名字等等,这就挺有用了。我们经常在上面进行问答挑战。

挑战是我们在讨论过程中偶尔发生的事情。询问我们任何关于Oracle的技术问题,如果我们不能在24小时内提供答案(不管是对,错或解决办法),提问者都将得到一件T恤,代表他(或她)打败了OakTable。

这个挑战,尽管有时没有像我们想要的那样进行,也许是因为它看起来好像是我们喜欢被自己回答不上的问题挑战。不过它的反面却是真实的,那就是我们的目的是解答任何人的疑问,不管这些问题看上去是多么的”简单”或是”容易”。

注:这是 Mogens NørgaardTroubleshooting Oracle Performance 一书前言中介绍 OakTable 技术组织的来龙去脉。OakTable 是 Oracle 数据库领域最有趣的一个技术组织,他们以运用科学方法(以及科学团体的伦理)从事所有活动。其成员都是顶尖的技术高手,现有大约70位成员,遗憾的是,或许因为语言的隔阂,还没看到来自中国的成员。Ooops , 前言真的不好翻译…

EOF

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

IDC 的电力问题到底有多严重?

最近在不同场合都遇到涉及 IDC 电力问题的讨论。对于这个话题我一直不是特别留意,直到昨天我说了一句比较武断的话之后,感觉到没有调查就没有发言权,所以找了一些数据来。

国内很多互联网公司关心 IDC 电力问题,可能有一部分是受了一些美国公司(尤以 Google 为代表)的影响。根据美国环境保护署的预测数据,到了 2011 年,美国数据中心消耗的电力将达到 1000 亿千瓦–这个数字够惊人的,这个问题如果放到美国的大环境上来看可能又不算什么,因为这个数字占美国总耗电量的比例 大约是 2.625%。那么中国呢? 考虑到中美能源利用效率的差异,我想现在数据中心用电量绝对不会超过 1%。Google 这类公司强调节能、绿色 IDC 之类的说法有他们的理由,且不说提高企业形象 — 在欧美如果大企业不提倡环保,还不被那些环保组织骂死 ? 另外,省钱也的确是硬道理。此外,有一大票鼓吹绿色 IT 的家伙是各色商业公司,当然,宣传的目的是为了多购买他们的”更加省电”的产品。

中美电力使用的一个巨大差异是,美国工业用电与商业用电相对比较便宜,而居民用电反而比较贵。在中国倒是相反,居民用电相对便宜,而工业用电和商业用电是比较贵的(前不久的发改委才要求工业、商用同价格,参考)。考虑到地域差异,以及各种因素,美国居民用电平均大约 10 美分左右(信息来源),而国内的价格,是一笔糊涂账,我所居住的杭州,正常时段的价格要超过 0.55 元,而且根据用电量大小、时间、类型等等有不同的计算价格,以我这个智商恐怕算不清楚的。不管怎么样,中美的居民用电价格是相差不大的,考虑到中美人民的收入,这里面实际差异还是很大的。(国内在 2008 年 7 月 1 日曾经提过一次电价,每千瓦时提价 2 分 5 厘– 看似很小的涨价? 这意味着每年就可以多收近千亿的人民币。嗯,有点跑题了。) 限于这多少算技术贴,其他层面的东西就不说了。

工业用电价格贵,那么似乎的确应该节电了? 在目前国内,有一些数据中心的确已经面临电力问题,但这些问题集中在 IDC 如何抢到电力资源(毕竟不同地区电力资源分配不均衡),而不是如何少用电,更为关键的是,你少用你那么一点点电(本来就没多用多少),可能真的解决不了什么问题,因为如果收费的标准不根据你用了多少电来衡量 — 体现到经济效益上来也就不会有多大,要是新闻联播每天少播 5 分钟,那全国要节省多少电阿… 很少有 IDC 根据电力对用户收费,更多还是根据物理空间、网络带宽等指标收费。作为用户一厢情愿的考虑 IDC 的问题乃至环保,或许还有点早(不是说不重要,而是这个问题不是我们最迫切的事情,当然,有这样的想法还是好的,是值得肯定的)。个人觉得提升计算性能充分发挥机器能力或是提供更好的产品给用户,可能也会节省大量资源,产生更大的经济效益。既然丁磊都说了”企业最大的慈善就是把产品做好”,我们可以套用一句,做好产品、给用户提供更好的体验也是环保…

对了,我那句武断的话是(洁本):

三年内,中国网络公司不用担心电力太贵;五年之内,不需要讨论环保问题。

不是这方面专家,引用的数据或许有误,当然,我的结论也明显有问题,您就对付着看吧。

EOF

电这个问题,如果 IDC 抢到的少,即使你用的少,别人也同样会用得多。经济因素影响真的不是那么大。

更新一下结论,IDC 如果抢不到电力,别的说什么都是收效甚微的事情。

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

或许真的无法帮你什么

时不时的会收到一些的救助邮件,内容特征大致类似,发信人要么是还在校的本科生或研究生,或者是刚走上工作岗位的,都是感到迷茫,不知道如何学什么更有前途,或者是如何学习某项技能才能更快的找份好工作,或者是如何才能进入到某公司工作……

code_guy.jpg

以前收到这样的邮件,基本上我还是愿意回复的(回复的邮件观点在我的网志上其实都能找到,比如 毕业生该怎么找互联网行业的工作 ),不过后来类似的邮件越来越多,看多了,回复也烦了(类似的内容如果重复几十次几百次没人不烦),都快成连岳了,不过连岳还有报社给稿费呢。更多的时候看到这些邮件是感觉到无奈,感觉到悲哀。其实求助人的迷茫我也是感同身受,但是我能真的帮你什么呢? 我短短的一封邮件,几个字儿,能是九阴真经? 能是葵花宝典? 按照我说的能练成神功麽?

再者说来,我也没有给大家指点的资格。 自己其实都还没捣鼓明白呢,给人当指路人不怕被带到沟里去阿? 要打算学技术,网络上能提供给你所有东西,钻进某个专业技术论坛潜水一段时间,可能也比你在学校学一些垃圾课程要好得多;学会看第一手资料,学会找信息来源,而不是到一些垃圾信息堆积站去吸取所谓的”营养”。另外,要是问如何成功之类的事情,可以找一下李开复老师嘛,当然他也是告诉你答案 “做最好的自己” 。学会思考,不要盲从盲信。

没有那么多一蹴而就的事情,每个人的面对的场景不同,所有人的路都是不可复制的,我的建议是还是要靠自己领悟,光靠别人的灌输或者指引是不行的,你需要的信息其实全在那儿,只是你自己没注意到,没重视起来,没实践一下,没坚持下去。

另外头疼的一点是我根本没那么多时间,尤其是一对一的问答(在 IM 上直接以问问题的名字找我聊天的我都会直接 Block 掉),最消耗时间与精力,所以,我更愿意写出来,这样后来人也能看到,效率起码高一点。这篇小文就算对类似求助邮件的统一回复吧。

EOF


下面的读者留言也很有趣,比如 “”努力加专注”…不过做到的人很少”。

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

从 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 用的就是 RRDtoolGangliaMRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是, 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 .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.