今天客户做系统升级，从原先的Oracle 8.1.7.4升级为Oracle 9.2.0.8 RAC，并且将应用系统从1.1版本升级为2.0版本，是一个很大的举动。

其中牵涉到数据转换，软件开发商用简单的insert into xxx select … from yyy@dblink a, zzz b where a.ccc=b.ccc这样的语句完成数据转换，之前已经在测试环境中多次运行过，但是今天却仍然发生了问题，本来在测试环境中只需要运行100秒的转换过程在生产环境中运行了将近1个小时也没有结束，因为转换过程是大量顺序执行的insert语句，因此其中一个语句堵塞了，下面的语句也无法运行。

包括客户、软件开发商在内的十数人站在身后，为什么测试环境中运行如此快的SQL在产品环境中变得如此缓慢？该如何解决？如果在已经严格计算过的时间窗口内无法解决，是否需要回退整个升级工作？情况看上去很紧急。

因为牵涉到dblink，因此检查网络，没有发现问题。

让软件开发商在测试环境中重新跑这个SQL，速度仍然很快，检查执行计划，发现在测试环境中是Full table scan + Hash Join，而生产环境中却是Index range scan + Merge Join，检查互相Join的表，一个只有几千条记录，一个有几十万，很明显Hash Join应该是明智的选择。

没有时间去检查为什么产品环境中Oracle选择了更差的执行计划，加Hint先去解决问题。

添加了/*+USE_HASH(C,B) ORDERED*/提示，重新检查执行计划，已经是想要的Hash Join了，再次执行SQL，40多秒就完成了数据转换。

不同的执行计划差异就是如此之大，CBO任重道远。

我看到的top 10地区是： 美国 德国 英国 法国 加拿大 中国 巴西 土耳其 日本 西班牙

作者: robbin  链接：http://robbin.javaeye.com/blog/206026  发表时间: 2008年06月20日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

OpenSocial只不过是Google的公关骗局发布以后，好像捅了马蜂窝，我看有人说我在给facebook写软文；有人说我在扯淡，有人说我根本不懂OpenSocial，不一而足。总的感觉是国内开发人员对facebook的了解太少，对Google又崇拜的丧失了起码的判断能力和怀疑精神，其实我自己也算是一个G粉，用Google Search，Gmail，Google Docs，Google Reader。

我为什么鼓吹facebook？

经常关注我的人应该知道，我从去年下半年就开始推崇facebook，时不时发表一些关于facebook的评论，到现在也快一年了。在这么长的时间里面，我断断续续花了不少时间了解facebook网站和facebook平台。但是我发现一个奇怪的现象：虽然这一年来facebook经常是互联网媒体上面的焦点，但是似乎国内的开发人员从来没有想过要去研究一下它，以致于我现在发现很多拉着我和我争辩OpenSocial的人，对facebook都缺乏起码的认识。我觉得对于那些ruby on rails程序员来说尤其不可以原谅，因为facebook平台支持的所有API当中，用RoR去开发facebook app是最简单的事情，有现成的插件做了良好的封装，你只需要处理一下登陆验证，注册一下api key和callback URL就全部弄好了。

1、从网站运营的角度来看，facebook是网站成长的翅膀

一个网站站长运营网站最困难的问题是什么？是推广！特别是在网站刚刚成立不久的时期，你怎么让更多人了解你的网站使用你的网站这是一个非常困难的事情。即便是很多已经很成功的网站，在早期的推广过程当中也是很幸运的遇到了非常好的机遇，才得以迅速成长起来的。推广是网站早期发展最大的瓶颈。但是由于有了facebook，你的网站推广就迎刃而解了。我来举个例子：

http://friendfeed.com

friendfeed是现在国外非常火爆的一个网站，可以订阅朋友的最新消息和动态。那么你说friendfeed当初是怎么推广的呢？怎么才能迅速积累这么多用户的呢？其实很简单，就是去注册成为一个facebook app就行了。所需要的额外开发工作量只是简单的登陆验证，用以和facebook实现统一认证而已，极少的代码量，如果在RoR里面，只是几十行代码的工作量。

好了，当friendfeed把自身的网站注册成为一个facebook app以后，在facebook里面的7000万注册用户就可以在facebook里面添加这个app，成为自己在facebook里面的一个tool来使用了。也就是说作为一个用户，你既可以在facebook里面使用friendfeed，你也可以直接访问friendfeed网站。例如我就是通过facebook才知道friendfeed，进而在facebook里面添加了friendfeed的账户，现在我往往直接访问friendfeed，而不见得每次都通过facebook访问friendfeed。

我们想想看，如果friendfeed不借助facebook平台的威力，他自己一个用户一个用户的去推广，他需要花多少推广的费用，需要发展多少年的时间？而通过facebook平台的威力，你就可以迅速成长为一个大网站。friendfeed具体的用户数字我不知道，facebook平台上面的Friend for Sale这个app的数字是三个月时间从零增长到每天1000万PV，60万注册用户，而仅仅是两个人在业余时间开发出来的网站。作为一个对比，JavaEye网站用了5年时间发展了15万注册用户，每天80万PV。这就是自己积累用户，和借助平台发展网站的巨大差别。

有了facebook，你做网站根本就不需要操心网站推广的问题，你只需要下功夫把网站功能做好就行了，插上了这样的翅膀你还担心网站发展不起来吗？

2、从商业回报角度看，facebook让你创业赢利变得很容易

前面提到了Friend For Sale这个app，两个人业余开发的，但是为了支撑每天1000万PV的访问量，他们买了12台服务器，请了DBA顾问，租用了一个机柜和100MB独享带宽，然后他们两个人辞职自己成立了公司。这些钱都从哪里来？很简单，就是广告费！他们在friends for sals里面嵌入了banner广告，访问量越大，点击量越大，赚钱越多。1000万PV是什么概念？在中国的网站里面差不多可以排进前50名的网站。

facebook开放平台以后，到现在一年多涌现了24000个app，这就相当于有24000个网站把他们的访问入口点注册到了facebook这里，从facebook这里分享网站流量、用户和广告，也就是说facebook现在养活了24000个网站，这24000个网站要依靠facebook来混口饭吃。这一成就是Google，Microsoft到现在都没有做到的，Google赚钱也只是自己一个公司赚到了钱，而facebook赚钱，则是让一整个网站产业链都赚到了钱。这就是为什么有那么多网站要到facebook去注册app，为什么有那么多公司要专门给facebook开放app的根本原因。在这一点上面，只有阿里巴巴有点像，他也是和很多很多网商的切身利益捆绑在了一起，我觉得这种制造一个产业链的网站才是真的很难被击败的，因为你要击败的不是一个网站，而是千万万万个利益绑定在一起的网站。

我们试想一下，如果全球有几十万个网站都注册了facebook app，从facebook那里分享流量、用户和广告的话，这个互联网究竟是谁说了算？ 当然谁是衣食父母谁说了算。即便facebook崛起之前，Google也没有统治互联网，网站并不受Google的直接威胁，但是facebook对网站的控制力要超过Google，这一点很好理解：用户通过Google搜索快速进入网站就脱离了Google的控制范围，但是通过facebook访问app，则一直在facebook的控制之下。

从今年年初开始，我就一直在说，现在最好的互联网创业就是开发facebook app，特别是开发一些web game类型的app，很容易就积累大批用户了，你有一个好的创意和好的开发执行力，已经可以成功了，大伙看看现在facebook上面火爆的火炬接力这个app就可以明白。

我为什么唱衰OpenSocial？

有人说我只研究了一个晚上的OpenSocial，没资格否定OpenSocial，说我根本不了解OpenSocial可以跨域进行AJAX调用，胡乱下结论。

1、从技术角度来说，OpenSocial限制的太死

其实我不需要学习OpenSocial一个月才能下结论，我只需要确定一点，即OpenSocial本质上是在用户的浏览器端通过JavaScript来运行，这就足够了。那些做过复杂企业应用，特别是用EXT/dojo做过One Page One Application应用的人，应该比我更清楚用纯AJAX做网站，和传统的服务器端web方式究竟有什么不同吧。

理论上来说，AJAX调用可以完成大多数网站服务器端同样的功能，如果开发商自己架设服务器，在widget的JS里面调用自己服务器暴露出来的服务的话，也可以做很多事情。但问题是成本不一样，用户体验不一样。

打个比方来说吧：eBay网站扔掉全部的JSP页面和Web框架，全部都改成静态页面，只在服务器端通过DWR提供AJAX调用接口，然后静态页面里面的 JS在浏览器端执行，通过DWR调用服务器端的服务，全部页面渲染都在浏览器端完成。最后做成一个One Page One Applicaion的网站。

你说从程序角度有没有实现的可能性呢？答案当然是可以，但问题是eBay不会这样去做，任何一个成功的互联网网站都不会这样去做，因为这样做其开发成本太高，其用户体验太差，只有一些操作非常复杂的企业应用才会采用这种OPOA方式。

OpenSocial 要做复杂的交互性应用，他也只能通过这种One Page Oone Application方式，这种方式是非常受限的。如果说Facebook给了开发人员无限的可能性，仅仅要求你实现登陆验证的话，那么OpenSocial则个开发人员施加了强大的限制，逼你只能在JavaScript里面翻筋斗，练梅花桩，其结果就是很多创造性的应用无法实现或者很难实现。事实上我现在看到的稍微复杂的高交互式OpenSocial应用示例都是用flash做出来的。你都被逼得用flash的时候，那就已经是另外一回事了，和OpenSocial没啥球关系了。你不用你OpenSocial，我一个flash也可以随便哪个网站去部署没一点问题。就是JavaEye的发贴也可以嵌入flash，是不是也可以算一个OpenSocial容器阿？

2、从网站运营角度来说，OpenSocial不能给开发商带来推广效应

还是拿friendfeed举例，我们设想一下，friendfeed怎么去使用OpenSocial才能带来同样的好处呢，答案是impossible！

friendfeed 必须按照OpenSocial的规范去写这样一个XML文件，把这个XML文件发布到某个OpenSocial容器网站，例如MySpace上面去。好了，现在问题来了，MySpace的用户能不能仅仅通过MySpace页面嵌入的这个friendfeed的widget来使用friendfeed网站的全部功能呢？答案当然是不可能，除非Friendfeed的开发人员在这个xml里面用JavaScript来重写一遍整个friendfeed网站的功能，嘿嘿，用一句通俗的话来说就是： 你必须把一头大象给我装进冰箱里面去。

3、从商业利益角度来说，OpenSocial无法保护开发商的利益，代码剽窃没有任何障碍

OpenSocial开发出来的gadget是在XML里面写JS和HTML，而这个XML还是一个在互联网上面可以访问到的URL，不需要任何授权就可以访问，这等于是代码完全暴露在光天化日之下。我们可以假设一下，某个公司投入研发力量开发出来的一个优秀的gadget很受欢迎，在很多OpenSocial容器网站都有很多人使用，那么一个很可能出现的后果就是别人可以把你的源代码直接拿过来，稍微改改，也发布为一个gadget去赚钱，而你没有任何办法去阻止他。

有人会说，我的gadget会通过AJAX调用我自己服务器的资源，你抄走了gadget，抄不走我服务器提供的Web服务，那我就要说了，如果你的gadget真的有商业价值，别人直接拿走你的gadget代码，然后自己架一个服务器，把你提供Web服务的接口也实现一遍，这并不什么困难的事情，而我相信一个有商业价值的gadget，在gadget本身的研发投入已经非常巨大了，这些投入被别人白白的拿走，毫无障碍的利用OpenSocial网络到处发布，一定会对你造成巨大的商业损失。

所以一个稍微有点理智的开发商，都必须慎重考虑投入到OpenSocial是不是值得的问题。


4、从商业模式的角度来说，OpenSocial无法形成一个简单有效的价值链，忽视了app开发商的利益

facebook的商业模式是简单而清晰的，参与商业博弈的就是facebook和app网站，1:n的关系，而且是利益共同体，互相依存。但是OpenSocial的商业模式参与博弈的关系过于复杂，是一个m:1:n的网状关系，m彼此之间还有强烈的竞争关系，而n和m的对应关系还不是线性的，你需要针对不同的m开发不同版本的gadget，而这个1是Google，他还分别和两边发生关系。我们知道商业模式越简单越有效，这个商业模式当中环节实在太多，而且彼此相互制约，哪一个环节出了问题，整个商业模式就走不下去。这一点在前面文章当中已经分析过了，不详细剖析了。总之关于这个问题我只想强调一点：

别看facebook平台上面有那么多活跃的开发商贡献app好像花团锦簇的样子，你深入研究一下facebook的app就会发现，facebook上面真正火爆的app根本就不是程序爱好者写的，全部都是专门的公司开发出来的。

你做开放平台，永远也不要指望软件开发人员作为业余爱好给你开发app，指望像开源社区那样踊跃的程序员贡献者，这些东西根本就不靠谱。真正靠谱的就是你的开放平台本身是具有商业价值的，能够给开发商带来商业利益，那么自然就会吸引大批的公司、网站和创业者专门给你开发app。而facebook之所以能够有今天，也就是因为这个原因。

Facebook战略之所以正确，是因为他从一开始就是立足于让app开发商赚到钱，所以app开发商就会趋之若鹜、前仆后继；而OpenSocial战略从一开始就是错误的，是因为Google搞OpenSocial的出发点不是让app开发商赚钱，而是让app开发商可以实现：“开发一次，处处部署”。

OpenSocial这个出发点就错了：只要能让我赚到钱，别说开发一次了，让我开发n次都愿意；但是赚不到钱的事，你就别指望我白白给你开发了，所以说程序员开发量多大根本就不重要，重要的是你Google有没有为app开发商设计有效的赚钱方式。而遗憾的是OpenSocial整个战略的侧重点都在拉拢SNS网站对抗Facebook上面，根本就没有关注app开发商的利益。所以现在的OpenSocial对于开发商来说，没有任何商业吸引力，你光指望在程序员社区推广推广，搞搞编程大赛，拉几个程序员作为兴趣爱好给你开发gadget，不如趁早洗洗睡了吧。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐

• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 立刻报名，免费获取门票，参加SOA技术论坛(广州6月19日)

I wasn't really looking for a new job a few months ago when I received an email from Eric Scheide (see Team Bios), the CTO at craigslist. He mentioned that they were looking for someone with MySQL experience and asked if I knew anyone. This sort of thing happens all the time.

But this time it was different. Over the course of about three seconds, something clicked in my little brain and I realized that craigslist is a pretty unique combination of things: a small company with a solid financial base, a great service that I use myself, a focused groups of people who really care about doing things well, and an open-source friendly environment.

I replied that I might be interested myself and things kind of took on a life of their own from there. In the weeks that followed, I got the chance to meet much of the team (including CEO Jim Buckmaster and Craig himself). Each time I came away liking more and more about the team. I've also been impressed at how well the company takes care of its people and how thoughtful they are about making important decisions.

So after taking a few weeks off for some planned travel and unplanned relaxation, I'll start assimilating myself into the craigslist engineering culture and lending a hand wherever I can. Yes, some of that will entail going back to my MySQL roots.

The site is growing like a weed (still!), the people are great, and the focus is on providing a great service that anyone can use. At the same time, there are a lot of technical challenges (they get a ton of page views) and great opportunities to grow the site and give back to both the open source community and all the communities around the world that craigslist serves--a list that's growing all the time.

Not that I really care much what other people think, but the reactions I've had so far when telling people have been universally positive. Very positive. That tells me I'm on the right track.

The only real downside is that crigslist is in San Francisco and I'm in San Jose. So if you have thoughts on getting to the vicinity of 9th and Judah using public transit, let me know. I won't be commuting up every day, but I suspect I'll be trying a few options before settling on what works best.

Previously: Leaving Yahoo!, and The Aftermath.

Related

• Zawodny Joining Craigslist In July WebProNews
• Yahoo's Open Source Developer Lands at Craigslist Wired
• Pilgrim’s Picks for June 19 - Back Home Edition Marketing Pilgrim
• Yahoo’s Executive Structure Crumbles: Lu, Garlinghouse and Makhijani To Leave TechCrunch
• Yahoo evangelist moving to Craigslist CNet
• Three More Managers Leaving Yahoo New York Times

(comments)

What started as an effort to package software not included in Red Hat Enterprise Linux has grown to be the most interesting part of Fedora for some ISVs. Extra Packages for Enterprise Linux, or EPEL, is not a mass rebuild of all Fedora software for Enterprise Linux. It is a disciplined set of packages with a maintenance philosophy that aligns with Enterprise Linux.

Today I am presenting at the Red Hat Summit in Boston on the topic of “Fedora Packages for Red Hat Enterprise Linux”. This article is derived from that talk.

There are two aspects of EPEL that are important to note. EPEL packages first provide system administrators with a proven, trusted set of packages that are dependency complete. This means that every piece of software needed to let that package build and install is already within the repository or part of Red Hat Enterprise Linux (RHEL). Because of this, EPEL packages do not replace or duplicate RPMs that ship in RHEL or any add-on RHEL solutions, such as Red Hat Cluster Suite or Red Hat Application Stack.

The other aspect of EPEL is the way it can help software vendors and open source projects improve the quality of their applications, while lowering costs, and making it easier to get certified to run on the next version of RHEL. Fedora EPEL is a major reason to participate in the open source process, with all the subsequent benefit.

ISVs and projects benefit through packaging their applications as part of Fedora, gaining the thousands and millions of testers and users, learning and using Fedora best practices for software production and maintenance. Since all this work occurs six, twelve, or more months in advance of the next RHEL alpha cycle, it is a significant jump on the certification process for an ISV. The more the ISVs participate in the open source process, the lower their certification costs can be, as they improve the software incrementally toward a ready-for-RHEL state through the Fedora community.

The benefit is not limited to ISVs. Anyone who has extra software they want available for their RHEL subscription can use or contribute to EPEL. This could be an IT or applications group in an enterprise, academic, or other institution. It could be a small coding boutique or a start-up, looking to ride the social connection toward a larger audience and a stronger code base.

One of the best practices that EPEL teaches is to create a job description for your Fedora package maintainers, and have this job description baked in to a role in your organization. This separates the individual who may have championed the original package creation from the ongoing role of package maintainer. Individuals change jobs and duties, and an integrated job description allows them to pass on the tasks. This overall improves longevity across EPEL.

If you are interested in learning more about EPEL, there is a useful FAQ, and you want to be sure to join and learn more about packaging in Fedora.

Starting off this year’s Red Hat Summit was a triplet of keynotes: a Red Hat leader (CEO Jim Whitehurst), a Red Hat partner (Jim Stallings of IBM), and an open culture visionary (Dr. John Halmaka, CIO of Harvard Medical School.) This ordering of keynotes is representative of how the Red Hat commmunity is structured–a balance between enterprise and open communities, with Red Hat in the lead. (These keynotes will be available in their entirety from the Red Hat Summit page.)

Leadership keynote: Jim Whitehurst

Jim Whitehurst focused on how Red Hat enables customers to gain value by entering the open source ecosystem. As examples, he talked about SELinux/www.amqp.org">AMQP. The Advanced Message Queue Protocol (AMQP) was developed internally at JP Morgan for fast messaging. Whitehurst described the visionary CIO of JP Morgan, who realized JP Morgan could improve the code and reduce their maintenance commitment over the long term.

Whitehurst encouraged customers to look at the code they develop internally. “The waste in IT software development is extraordinary,” he said. By bringing that coding effort into the open and building a community around it, enterprises can look at millions in savings.

Visionary keynote: Dr. John Halamka

Continuing the discussion of the value of open culture, Dr. John Halamka, CIO of Harvard Medical School, talked about healthcare IT. In modern medical IT, he said, “Open and transparent is good, closed and proprietary is bad.” Dr. Halamka’s talk focused on the millions of Eastern Massachusets medical records handled by their Red Hat cluster, placing that in the context of national work on open medical IT standards.

Dr. Halamka works as part of the American Health Information Community (AHIC). One of his main projects with AHIC is improving medical record standards. He describes it as “500 groups working to harmonize standards.” The AHIC defines a number of use cases to drive their work. One of their projects, for example, might be making it possible to get your medical records in a totally portable way.

In Massachusetts, the IT group Dr. Halamka oversees has put this planning into action. Patient records are transmitted on an entirely open source architecture, with edge servers at all the medical providers and payers. As an example, Dr. Halamka pulled up his own record, then joyfully showed his mostly-IT audience the underlying XML source.

By using open standards running on an open source infrastructure, they move patient data wherever it needs to go without delay. In the process, they have saved over $20 million a year by not having licensing and fees for a slower clearinghouse to ship records.

As a call to the innovative open IT audience, Dr. Halamka listed the items that keep him awake at night: Electronic health records for doctors; storage as a utility; e-Prescribing; data sharing for clinical care among a community of caregivers; security; RFID and bar-coding; providing remote decision support; compliance requirements; internal and external websites that provide social tools for end-users; and disaster recovery.

Partner keynote: Jim Stallings

Jim Stallings from IBM presented the partner keynote, which served to bring home some of these open source lessons from the big infrastructure/large enterprise/data center perspective. What are global CEOs/CIOs worried about? Globalization, scale, complexity, security, and energy. In particuar, Stallings explained how energy has been the surprise concern that is going to change how data centers operate in the future.

In this transformation of the data center, one area of cost savings includes dealing with heat. As a global concern, power and cooling are going to drive data center changes, with Linux at the center because of flexibility, speed, and a history of caring about these matters.

Stallings describes an average achievable energy savings of 40%, with an average payback of less than two years. For every dollar of energy savings, there is an average additional six to eight dollars in operational savings.

关系数据库并不是企业中的 Python 程序员唯一可用的解决方案。通常，对象数据库可能更适合解决某些问题。本文将讨论 ZODB，ZODB 是一个可扩展和冗余的对象数据库，其专注于存储可扩展的对象，而没有天生的“对象-关系”不匹配情况；在尝试将面向对象的语言与关系查询系统映射对象建立关系时，可能会出现这种不匹配情况。