星期六, 九月 27, 2008

采访稿:《开放API》

原 文链接。其中我以开放平台实验室创始人身份接受中国信息化杂志的采访。

2008年09月24日  来源:中国 信息化  作者:郭娟

  奥运期间,新浪为网民提供了奥运地图服务。地图界面分别标注了举行赛事的场馆位置、乘车路线和驾车路线。用户如果选择了去哪个场馆观赛,只需输 入出发地点,随后就会有数条出行路线供选择。

  那么新浪能够提供地图服务是否意味着其内部重新组建一支团队,专门负责互联网地图的编程?

  新浪并没有这样做。奥运地图的生成界面虽然是新浪网,但是地图的调用却是图形天下的服务器,而图形天下正是通过开放自己的API,才使新浪完成 了奥运地图的服务。

  图形天下相关人员告诉记者,目前,调用他们地图开放接口的网站达到1万多家。

  其实,除了图形天下,许多网站正在开放API,从新锐的SNS网站如Facebook、校内网等,到传统的大型互联网公司,如Google、 Amazon、eBay等都不约而同地举起开放API的大旗。

  API又叫应用程序编程接口,最初是指用来控制Windows的各个组件的外观和行为的一套预先定义的Windows函数。到了互联网时代,使 用API构建业务成了实现开放式业务结构的开放技术。

  业内专家分析,开放了API的互联网将成为容纳更多第三方应用的平台,而成为了平台的互联网又区别于门户的互联网、搜索引擎的互联网以及电子商 务的互联网。

  开放API是互联网应用的下一个趋势吗?为什么互联网公司都想成为平台?

关系传播

  "开放API在技术和产品上已经不是一个新话题,但是到了今天才开始引爆这一应用",我国开放平台实验室的联合创始人刘青焱先生告诉记者。

  "过去我们有过开放API的应用,如RSS订阅,通过RSS订阅器,我们可以看到定制某类新闻,而不用逐个页面去寻找。"

  "到了目前这个阶段开始关注这一应用,是互联网产业发展累积到了一定程度的必然。而且以前没有一家互联网企业会想到做成平台,Facebook 最先开放API让我国互联网界眼前一亮。"刘青焱告诉记者。

  "Facebook提供了托管平台,开放接口组装成应用,这是其一,那么接下来的问题就是为什么Facebook能够成为一个平台?"

  刘青焱分析,Facebook提供了关系数据,这是一种很关键的数据。新应用在人的关系网上有一种病毒式的传播,"通过关系网络,这些应用能传 递到关系网上的所有好友,这是一种非常高速的应用传播基础"。

  "不是所有业务都适合去做成开放平台。开放API应由业务模式决定,博客发表言论影响别人,以个人为中心,提供信息传播,和提供关系的相比,提 供关系的业务模式也许更适合于开放平台。"

大浪淘沙

  Facebook开放API震动了国内的SNS网站。

  2008年7月8日,校内网宣布开放API。相关媒体评价,如果说校内网是靠模仿Facebook起家的话,那么现在才是真正走出了一条自己的 路。随着应用数量的逐渐增加,校内网会不断做出自己的特色。

  而早在2008年1月,Myspace也宣布开放API,"第三方开发者可以通过开放API来获取用户的个人信息、好友信息、照片、兴趣爱好、 所属群组、状态信息等,结合自己的聪明才智,构建出丰富多彩的社区应用程序,部署在MySpace或开发者自己的服务器上"。

  API平台将给SNS网站的用户带来无穷乐趣,有效增加用户的黏度。

  自Facebook开放API后,引来了大量的第三方应用,如读书、听音乐、看电影等等,用户不用离开Facebook就可以实现这些娱乐功 能。Facebook上已有近4000种游戏程序和音乐共享工具。截止到2008年1月的消息显示,Facebook在过去几个月里的市场份额增加了3 倍。

  国内SNS网站开放API与Facebook的情况不一样。Facebook开放API的一个条件是SNS做得很成功,但是国内SNS网站正处 在摸索阶段。Facebook的方式是否适合中国,这其中的社会文化背景因素是不可忽视的。

  "美国人喜爱聚会,他们很多人通过Facebook的邀请就可以进行,然而,中国人不一定喜欢聚会,国内的SNS如果照搬Facebook的 话,没有坚实的根基。"刘青焱告诉本刊记者。

  "然而,SNS在中国是一个能做起来的应用模式。只有更透彻地了解中国文化,选择中国的方式,才能够成功。"

  刘青焱认为:"现在中国的SNS网站在应用模式尚未清晰的情况下开放API也是有道理的。一项资料表明,Facebook上网民的行为并不全都 是为了参加社交活动,相反,他们有为数不少的行为是在娱乐和聊天。"

砍掉长尾

  随着Google、Amazon、eBay、Facebook相继开放了自己的API。在国内,除了校内、Myspace等网站外,淘宝、搜狐 等网站也采取相应的举动,那么与兴起的Web2.0网站相比,传统的互联网企业又为什么要开放API呢?

  据记者了解,淘宝将开放API视为"一场史无前例的商务之旅",但是为了确保淘宝和阿里巴巴网站上的信息安全,他们采用了渐进的方式开放 API。

  开放平台实验室分析,卖家通过API接口,能够面向终端消费者,去除原始模式中的繁琐的细节和流程,寻找更大的利益节点;对于买家而言,淘宝开 放API能给他们带来更便捷的购物体验。

  "爆炸性的用户需求让互联网不得不选择开放API,从而形成互联网行业新的产业链",这条新的产业链,包括用户、互联网企业和第三方应用开发 者,"理想的模式是这三者进行良性的互动,互惠互利",利益则摊薄在产业链上的各个环节。

  刘青焱分析,与淘宝开放API不同,Facebook、Google开放API则体现了经济学中的投入产出比。"随着用户应用的增多,传统的互 联网企业不可能完全满足他们的需求。"

  "这是因为,一些应用需求在总需求中的比重很小,如果互联网企业为了满足这些需求去投入的话,产生的利润很低。"

  "这些被大企业砍掉的'长尾'对一些小企业来说,足以活命。小企业借助互联网,将那些少量的需求整合在一起,形成为数不小的数量群,这样,他们 通过开放平台上的API接口,开放应用,也能满足这些用户的需求"。刘青焱告诉本刊记者。

[postgresql]切换schema

Q: psql连接到pg数据库如何切换schema?
A: 其实这在pg里叫做设置搜索路径(set search_path to)
\dn 查看有哪些schema
set search_path to schema1, schema2; 设置搜索路径到schema1&2
\dt 查看schema1&2中有哪些表

陆奇动向后续跟踪

9月18日先后的两篇文章《传雅虎搜索广告平台副总裁陆奇跳槽微软》 和《雅虎搜索专 家陆奇可能加盟阿里巴巴》让陆奇同学的去向更加扑朔迷离,让我们平静等待吧。

星期五, 九月 26, 2008

python版开心停车外挂升级,解决acc()计算问题

上次刚说可以用spidermonkey来执行js代码,获得校验码,今天就看到xiaodong 已经实现了,好快手。赶紧跟进升 级了python版,呵呵,不过为了省事,仅支持linux(需要安装spidermonkey,以便使用/usr/bin/js)。想在 windows下用就自己改改吧。

星期三, 九月 24, 2008

做了一个python版本的kaixin停车外挂

前两天看到xiaodong做了一个开心外挂,是php写的。正好我正 在学python,于是就抽空把它改成了python版本的。代 码放在了google code的svn上。使用方法如下:

$ python parking.py -u zzz@a.b.c -p xxxxxx -t
您是 < zzz >
您有 < 1 > 辆车
  分别是:
  < 二手奥拓 > : < 16000 .00> RMB, 目前停在 < xxx > 的车位上
目前您共有 < 10180 .00> RMB
目前您的车共值 < 16000 .00> RMB
目前您的身价是 < 26180 .00> RMB
开始停车了
  成功将车 < 二手奥拓 > 从 < xxx > 的车位 停到 < yyy > 的车位上
成功停车  1  辆

不过,根据最新的消息,kaixin搞了一段js来计算一个校验值以防止外挂, 所以后面还得修改这个脚本才能停车了。
我的想法是找一个js runner,例如spidermonkey来跑这个函数,每次计算校验值。

星期二, 九月 23, 2008

[python] TypeError: 'str' object is not callable

代码:d = f('a'+b.c())

错误:TypeError: 'str' object is not callable

原因:
c是b的成员变量,而不是成员函数,所以变成了:

d = f( ('a'+b.c)() )

假设b.c='x',则 'a'+b.c='ax',就成了 'ax'(),这就相当于要把'ax'这个str当
成函数去call,而str是不能被call的(not callabe),于是出现上面那个很不可思
议的错误。

星期一, 九月 22, 2008

Blogger网页显示空白的问题

Blogger通过FTP发布的博客页面访问不了,打开来是空白。这个问题原因是网页编码被误判成 GB2312,而不是正确的 UTF-8,于是 IE 无法识别,所以显示成空白。

因为在文件头中,声明网页内容编码的那一行标记
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

被放到了 <title> ... </title> 之后,而刚好 title 中有中文,所以 IE 在没有获得指定的编码类型时,用了默认的 GB2312。

解决这个问题还是比较容易:编辑 Blogger 的模版,把"<$BlogMetaData$>"放到"<title><$BlogPageTitle$></title>"的前面,然后重建一下,就不会出现这个问题了。
 
参考:http://blog.windia.net/tech/2006/10/blogger.html

星期日, 九月 21, 2008

修复sphpblog中文问题

保留原英文界面,又能处理中文字符集,可以如下修改。
编辑languages/englist/strings.php:

$lang_string['locale']=array('en_US.UTF-8','en_US');
$lang_string['rss_locale']='en_US.UTF-8';
$lang_string['html_charset']='UTF-8';
$lang_string['php_charset']='UTF-8';

星期六, 九月 20, 2008

[翻译]PostgreSQL性能调优

PostgreSQL性能调优

原作:Frank Wiles
翻译:Evan (Qingyan) Liu, 刘青焱, hmisty [AT] gmail [DOT] com
原文:http://www.revsys.com/writings/postgresql-performance.html

简介

PostgreSQL是当今最先进和灵活的开源SQL数据库。它的强 大和灵活同时也带来一个问题:有这么多人使用PostgreSQL,它的开发者该如何设定缺省配置才能适合所有人的需要呢?不幸的是,答案显然是:他们无 法给出一个适合所有人的缺省配置。

问题是,每一个数据库不仅仅有着不同的设计,更重要的是它们所满足的需求是不同的。有些系统被用来记录海量的数据,但是大部分数据很少被检索。而另 外一些 系统则有着基本静态的数据,频繁的,甚至是疯狂的被检索。然而,大多数的系统对数据库有着不同级别的读写需要[下划线是存疑的翻译, 下同——译者注]。这些许的复杂性,加上完全独特的表结构、数据、硬件配置,希望你开始意识到,调优将会是一件多么困难的事情。

PostgreSQL的缺省配置是非常稳健的,它仅仅是为了满足用户对于一个"处于平均水平"的数据库安装在一个"处于平均水平"的硬件上所能够达 到的最 好期望。本文的目的是帮助PostgreSQL的不同层次的用户们更好的理解PostgreSQL的性能调优这件事情。

理解进程(process)

学习PostgreSQL数据库调优的第一步是理解一次查询(query)的生命周期。下面列出了一次查询的步骤:

  1. 传输查询串到数据库后端
  2. 解析(parsing)查询串
  3. 规划(planning)查询,以优化数据检索(retrieval)
  4. 从硬件上检索数据
  5. 传输结果到客户端

第一步是发送查询串(你输入的或者你的程序用到的实际的SQL命令)到数据库后端。这个步骤中没有什么好调优的,然而如果你有一些能够事先准 备好的[原 文为that cannot be prepared in advance,怀疑说反了——译者注]、非常大的查询,把它们编写成存储过程 (storage procedure)预先放到数据库里,这样可以最大程度的减少网络传输的数据量。

一旦SQL查询到了数据库服务器内,它就会被解析成符号(token)。同样可以运用上面提到的存储过程来通过预编译减少这个步骤的消耗。

查询规划是PostgreSQL真正开始干一些活的地方了。这个阶段要检查一下,看看查询是不是已经解析好了——如果你的客户端库版 本支持 这个特性的话。同时,它还会分析你的SQL,以便决定检索数据的最有效的方式。我们是否应该使用索引(index)呢?如果是,应该使用哪一个?也许那两 个表适合于进行哈希连接(hash join)?在这个阶段,数据库要做出上述这样一些决定。如果查询被预先解析好了,那么这个步骤就可以 省略了。

现在PostgreSQL规划出了它认为是最佳的检索数据的方法了。真正的检索工作就要开始了。尽管此时还会有一些有帮助的调优方法,但是这一步骤 的性能 已经更多是受到硬件配置的影响了。

最后一步是把结果传输到客户端。尽管这一步没有什么实际的调优选项,你仍然要注意,你的返回数据是从磁盘上读出,然后通过网线送到客户端的。因而, 尽量减 少返回的行列数,只保留那些真正必要的,常常可以提高性能。

一般调优

有一些对postmaster程序的设置可以显著影响性能。下面就列出了大部分常用的选项,以及它们对于性能的影响:

  • max_connections = <num> —— 这个选项设置了数据库后端的同时最大连接数。使用这个特性可以保证你不用启动很多后端以至于开始进行磁盘交换、严重影响到子进程的性能。根据你的应用的需 要,也许完全拒绝一些连接要比降低所有人的性能要来的好些。
  • shared_buffers = <num> —— 设置这个选项是提升数据库服务器性能的最简单的方法。因为对于大部分现代的硬件而言,这个选项的缺省值都显得过于低了。一般的建议是,最好把这个值调高到 总物理内存的25%左右。像对于大部分选项一样,我同样在此指出,你可能需要尝试不同的几个数值(高的和低的),然后观察对于你的特定系统最佳的数值。大 多数人发现,当这个数值超出1/3总物理内存的时候,性能开始下降。
  • effective_cache_size = <num> —— 这个数值告诉PostgreSQL的优化器有多少内存可以被用来缓存数据,以及帮助决定是否应该使用索引。这个数值越大,优化器使用索引的可能性也越大。 因此这个数值应该设置成shared_buffers加上可用操作系统缓存两者的总量。通常这个数值会超过系统内存总量的50%。
  • work_mem = <num> —— 这个选项是用来控制在排序操作和哈希表格的时候所用的内存的量的。如果你的应用需要做一大堆的排序,那么你可能会需要增加这个内存用量,但是,请小心。这 不是一个系统范围的参数,而是一个操作粒度的。因此,如果一个复杂的查询,包含了若干排序操作,它就会使用多份大小是work_mem的内存!更不用说多 个后端同时执行类似的操作了。这个查询往往会导致你的数据库服务器频繁进行磁盘交换,如果work_mem选项设置的过大的话。在老版本的 PostgreSQL里,这个选项的名字是sort_mem。
  • max_fsm_pages = <num> —— 这个选项帮助控制可用空间映射表(free space map)。当一个东西被从一张表里删除的时候,它并没有被从磁盘立即删除,而是简单的在可用空间映射表里打上了"可用"的标记。这个空间就可 以在之后向表中新插入数据的时候被重新使用。如果删除和插入操作非常频繁的话,就有必要增加这个数值以避免表的过度膨胀。
  • fsync = <boolean> —— 这个选项决定了是否所有的WAL页面都要在一个事务提交之前通过fsync()调用同步到磁盘。开启这个选项有助于降低数据丢失的风险,但是却会降低写操 作的性能。如果fsync没有开启,那么将会存在数据损坏且不可恢复的风险。请自行决定是否关闭这个选项。
  • commit_delay = <num>commit_siblings = <num> —— 这个选项可以被用于调整一次性提交的事务的数量来提高性能。如果在你的事务提交的时候有commit_siblings个活跃的后端,那么服务器会等待 commit_delay微秒,然后尝试一次性提交多条事务操作。
  • random_page_cost = <num> —— random_page_cost控制着PostgreSQL如何看待非串行化(non-sequential)磁盘读取操作。较高的数值会使得它更偏好 于顺序扫描(sequential scan),而不是索引扫描(index scan)——索引扫描通常意味着你的服务器要有非常快速的磁盘。

注意,上述大部分选项配置都会需要较多的共享内存,因而可能需要增加你的系统允许的共享内存量以使得它们能够生效。

硬件问题

显然,硬件的类型和质量也会显著影响数据库的性能。下面是给你的数据库服务器选购硬件的一些小提示(按照重要性排序):

  • 内存 —— 你有越多的内存,你就有越多的磁盘缓存。这一点是十分影响性能的,考虑一下,内存I/O的速度比磁盘I/O快成千上万倍。
  • 磁盘类型 —— 显然,高速Ultra-320 SCSI磁盘是你最好的选择,然而高端的SATA磁盘也非常不错了。SATA的单块磁盘足够便宜,选择SATA就意味着,你在同样的预算下能够购买更多。
  • 磁盘配置 —— 最合适的配置是RAID 1+0和尽可能多的磁盘。把事务日志(pg_xlog)放到单独的一块磁盘(或者条带(stripe))上。除非你有超过6块磁盘,那么RAID 5不是一个好方法。最新版本的PostgreSQL还允许你使用表空间(tablespace)选项来把不同的表、数据库和索引放到不同的磁盘上以优化性 能。比如,把你最常用的表放在高速的SCSI磁盘上,而把不常用的放到低速的IDE或者SATA磁盘上。
  • CPU —— 越多越好。然而,如果你的数据库不会用到很多复杂函数,你最好把你的钱生下来购买更多内存或者更好的磁盘。

通常,你的系统有越多的内存和磁盘,它的性能就越好。这是因为多出来的内存会减少对磁盘的访问。多出来的磁盘会有助于把读写操作分散到多块磁盘上, 从而增 加吞吐量,减少磁盘驱动头拥堵。

另外一个好主意就是把你的应用程序代码和你的数据库服务器放在不同的硬件上。这不仅为数据库服务器提供了更多独享的硬件,更使得操作系统缓存更多 PostgreSQL的数据,而不会因其他应用程序和系统数据而占用磁盘缓存。

例如,如果你有一个web服务器,一个数据库服务器,你可以用一根双绞线接在一个单独的网口上来专门用来连接这两台服务器,所有的web服务器到数 据库服 务器的流量都走这根单独的链路,这样可以最大程度上减小可能的瓶颈。如果你有多台服务器访问同一个数据库服务器的话,你也可以创建一个完全独立的物理网 络,来跑所有的数据库访问流量。

有用的调优工具

调优数据库最有用的工具就是SQL命令:EXPLAIN ANALYSE。这个命令允许你描绘(profile)你的应用程序执行的每一个SQL查询,以精确查看PostgreSQL规划器将如何执行这个查询。 让我们看一个简短的例子。下面就是一个简单的表结构和查询。

CREATE TABLE authors (
id int4 PRIMARY KEY,
name varchar
);

CREATE TABLE books (
id int4 PRIMARY KEY,
author_id int4,
title varchar
);

如果我们使用查询:

EXPLAIN ANALYZE SELECT authors.name, books.title
FROM books, authors
WHERE books.author_id=16 and authors.id = books.author_id
ORDER BY books.title;

你将会得到类似下面这样的输出:

QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Sort (cost=29.71..29.73 rows=6 width=64) (actual time=0.189..16.233 rows=7 loops=1)
Sort Key: books.title
-> Nested Loop (cost=0.00..29.63 rows=6 width=64) (actual time=0.068..0.129 rows=7 loops=1)
-> Index Scan using authors_pkey on authors (cost=0.00..5.82 rows=1 width=36) (actual time=0.029..0.033 rows=1 loops=1)
Index Cond: (id = 16)
-> Seq Scan on books (cost=0.00..23.75 rows=6 width=36) (actual time=0.026..0.052 rows=7 loops=1)
Filter: (author_id = 16)
Total runtime: 16.386 ms
 

当你分析这个输出的时候,你需要从底往上看。PostgreSQL做的第一件事情就是对books表进行顺序扫描,查看每一个author_id字 段是否 等于16。然后,它对authors表进行索引扫描,因为id字段的PRIMARY KEY属性会导致建表时同时创建一个索引。最后对结果按照books.title字段进行排序。

你在括号中看到的数值是这一个查询步骤的消耗的估算值和实际值。估算值和实际值越接近,一般而言查询性能也就越好。

现在让我们稍微改变一下结构,给books.author_id字段增加一个索引,避免顺序扫描。用下面这个命令:

CREATE INDEX books_idx1 on books(author_id);

如果你重跑查询,你不会看到任何改变。这是因为PostgreSQL还没有重新分析数据,也就不知道新索引对这个查询会有什么好处。通过执行下面的 命令可 以解决这个问题:

ANALYZE books;

不过,在这个小测试中,规划器还是会倾向于顺序扫描,因为books表没有几行。如果一个查询会返回一个表中的大部分数据,那么规划器也会选择顺序 扫描, 因为这样的确会更快。你也可以通过设置配置参数enable_seqscan为off,强制PostgreSQL使用索引扫描。这不会消除 所有的顺序扫描,因为一些表可能没有索引,但是这确实会强制规划器只要索引可用就总是使用索引扫描。可能比较好的做法是,在每次启动新连接的时候,首先发 送一个命令SET enable_seqscan = off过去,而不是在全局配置中设置。这样做,你可以通过你的应用程序代码来控 制什么时候这个设置生效。不过,一般情况下,关闭顺序扫描应该仅仅用于调优你的应用程序的时候,而不应该在日常的操作当中使用。

一般而言,优化你的查询的最佳方法是在频繁使用的查询所对应的特定的字段和字段的组合上使用索引。不幸的是,这往往是通过试错来完成的。 你 也应当注意,增加一张表的索引的数量会增加每一次插入和更新操作的写操作的次数。所以,别做蠢事,把每一张表的每一个字段都加上索引。

你可以通过调整为一张表或一个字段收集的统计信息的量,帮助PostgreSQL做你希望它做的事情,使用下面这个命令:

ALTER TABLE <table> ALTER COLUMN <column> SET STATISTICS <number>;

这个数值可以是一个0到1000的数字。PostgreSQL根据这个数字决定为那个字段收集什么量级的统计信息。这帮助你通过为所有的表格和字段 生成大 量的统计信息,控制生成的查询规划,而不用使用缓慢的vacumm和analyze操作了。

另外一个调优的有用的工具是打开查询日志。你可以告诉PostgreSQL哪些查询是你感兴趣的,你可以通过log_statement配 置选项来配置将它们记录下来。这一点在有许多用户在你的系统里通过一些工具,例如Crystal Reports或者直接用psql,来执行专有查询的情况下,非常有用。

数据库设计和布局(Layout)

有时候数据库设计和布局会影响到性能。例如,如果你有一个雇员数据库,像这样的:

CREATE TABLE employees (
id int4 PRIMARY KEY,
active boolean,
first_name varchar,
middle_name varchar,
last_name varchar,
ssn varchar,
address1 varchar,
address2 varchar,
city varchar,
state varchar(2),
zip varchar,
home_phone varchar,
work_phone varchar,
cell_phone varchar,
fax_phone varchar,
pager_number varchar,
business_email varchar,
personal_email varchar,
salary int4,
vacation_days int2,
sick_days int2,
employee_number int4,
office_addr_1 varchar,
office_addr_2 varchar,
office_city varchar,
office_state varchar(2),
office_zip varchar,
department varchar,
title varchar,
supervisor_id int4
);

 

这个设计非常容易理解,可是在几个层次上它都不太好。尽管这依赖于你特定的应用,然而在大多数情况下,你都不大会需要同时访问所有的数据。在你的应 用中, 处理HR功能能的部分,可能你只是对他们的name, salary, vacation_days, sick_days等字段感兴趣。然而,如果应用程序要显示一个组织结构图,那么它可能只关心表格的department和supervisor_id部 分。

通过把这张表格拆成几张小表,你可以获得更加有效率的查询,因为PostgreSQL可以更少的读取数据,而不会影响功能。下面是一种更好的结构:

CREATE TABLE employees (
id int4 PRIMARY KEY,
active boolean,
employee_number int4,
first_name varchar,
middle_name varchar,
last_name varchar,
department varchar,
title varchar,
email varchar
);

CREATE TABLE employee_address (
id int4 PRIMARY KEY,
employee_id int4,
personal boolean,
address_1 varchar,
address_2 varchar,
city varchar,
state varchar(2),
zip varchar
);

CREATE TABLE employee_number_type (
id int4 PRIMARY KEY,
type varchar
);

CREATE TABLE employee_number (
id int4 PRIMARY KEY,
employee_id int4,
type_id int4,
number varchar
);

CREATE TABLE employee_hr_info (
id int4 PRIMARY KEY,
employee_id int4,
ssn varchar,
salary int4,
vacation_days int2,
sick_days int2
);


 

通过这种表结构,一个员工的数据被打散到几个逻辑组里。主表包含了最常用的信息,而其它的表则存储了其余的信息。这种布局的额外好处就是一个员工现 在可以同时关联多个电话号码和地址了。

另外一个有用的技巧就是在那些查询一个值比其它值更频繁的列上创建部分索引(partial index)。拿上面的雇员表为例。你的应用的主要部分可能只显示在职的员工,在active列上对在职(active='t')的部分创 建部分索引可以加速查询,同时还可能帮助到规划器选择在某些情况下使用索引、某些情况下不用。你可以用下面的命令创建部分索引:

CREATE INDEX employee_idx2 ON employee(active) WHERE active='t';

比如在一些任务跟踪系统里,有的表有一个employee_id列,当某一行不对应任何一个员工的时候该列的值就为空(null)。在这类系统中, 可能有一类"查看未分配的任务"的功能,创建下面这个部分索引能够让这个功能提速:

CREATE INDEX tickets_idx1 ON tickets(employee_id) WHERE employee_id IS NULL;

应 用开发

有很多基于SQL数据库构建应用的方法,但是其中有两种主要的形式,叫做无状态的(stateless)有状态的 (stateful)。在性能方面,它们各自面临不同的问题

无状态通常是基于web的应用所用的一种访问形式。你的软件连接到数据库,执行一系列的查询,把结果返回给用户,然后断开连接。下一个操作时,用户 把上述过程重新来过,新的连接、新的查询集合、等等。

有状态的应用通常是非web的用户界面,应用初始化一个数据库连接,然后在应用运行期间一直保持不关闭连接。

无状态的应用

在基于web的应用中,用户每一次请求都创建一个新的数据库连接。尽管PostgreSQL创建连接所需的时间很短,通常不是一个十分耗时的操作[如 果在高负荷的热门网站上,这个操作的速度仍然是不可接受的,并且很快数据库性能会急剧下降,你的网站速度将非常慢,用户走光——译者注],最好使 用一些数据库连接池技术来获得最大的性能。[其实真正的网站都要承受大量用户的访问,这时候往往需要使用大量的cache技术,例如 memcache,来缓解数据库的压力,提高网站的速度,提升用户体验——译者注]

下面是一些数据库连接池技术的简短列表:

  • Pgpool是一个非常小的服 务器程序,你可以把它和数据库客户端放到同一台服务器上跑,它可以为本地或远程的数据库建立连接池。你的应用程序则连接到pgpool,而不是直接连接到 postmaster。从应用程序的角度来讲,所有的使用方法和以前完全一样。
  • mod_perl的环境里你可以使用Apache::DBI模 块来把数据库连接池内嵌到Apache自身之中。
  • SQLRelay是另外一个数据库连接管理 器,它某种程度上是数据库无关的(agnostic)。它能够工作在除了PostgreSQL之外的若干种数据库之上。
  • 你也可以写一些代码来自己实现连接池,但是我仍然强烈建议你使用一些成熟的解决方案,以减少你调试和除错的工作量。

不过也应当注意到,在一些诡异的情况下,我的确看到使用数据库连接池反而会降低web应用的性能。在一些特定的时候使用连接池的开销甚至比简单的创 建连接要来的大。因而我建议,最好把这两种方法都测试一下,看看对于你的环境哪一种是最好的。

有状态的应用

如果创建有状态应用程序,你可以通过DECLARE命 令来使用数据库游标(cursor)。游标使得你得以规划和执行一个查询,但是仅仅在你需要的时候才真正取回数据,比如一次取一行数据。这可以大大增加你 的UI响应速度

一般应用问题

这些问题通常会对有状态和无状态的应用产生同样的影响。一个好的技巧是,在服务器端对于任何一个经常执行的查询进行prepare。这样就可以通过 把查询规划缓存起来以备后用来减少整体查询的时间。

然而,应当注意,如果使用占位符(例如'column_name=?')来预先prepare一个查询,规划器不会总能够选择到一个最佳的规划。例 如,查询中有一个布尔值字段'active'的占位符,当该列为false的时候有一个部分索引,那么规划器是不会使用这个部分索引的,因为规划器不能确 信当查询被真正执行的时候这个字段的值是true还是false。

显然,你也可以使用存储过程来降低查询生命周期中的传输、解析和规划部分的比重。最好描绘(profile)一下你的应用,找到最常使用的查询和数 据操作,然后把它们写成存储过程。

其他有用的资源

这里有一个简短列表。


Frank Wiles改用PostgreSQL作为他的首选数据库已经超过8个年头了。此间他从未回头。他在一系列的情境下使用PostgreSQL,然而多数情况 下会结合Apache和mod_perl来构建基于浏览器的应用。他发表了若干篇文章,和一本书,涵盖了从系统管理到应用开发的各种主题。他的联系方式是
frank@revsys.com

星期五, 九月 19, 2008

中国境内银行业务原则,供西方国家同学学习

看到有人根据过往案例总结了中国境内银行的几条业务原则,引述如下,以飨众位:

ATM取出假钱——银行无责
网上银行被盗——储户责任
银行多给了钱——储户义务归还
银行少给了钱——离开柜台概不负责
ATM机出现故障少给钱——用户负责
ATM机出现故障多给钱——用户盗窃
广东开平银行行长贪污4亿——判12年
ATM多吐17万给老百姓许霆——被判无期

由此可见,中国的金融安全规范已经远远领先欧美了。

星期一, 九月 08, 2008

淘宝开放平台正式发布了

淘宝正式开放了: http://www.taobao.com/theme/tao_source/

归纳一下要点:
1. 是阿里软件开发的平台
2. 开始就有较为完备的收费模式(参考《ISV接入必备宝典》)
3. 包含了阿里软件SaaS平台的4大类共计9个API、淘宝4大类共计20个API(详见下面的《API参考手册》)
4. 还放出来了旺旺的SDK凑份子,不过SDK不开放源码,鄙视一下。呼吁旺旺的协议开放,这样就可以开发pidgin插件以支持linux旺旺了~

有一些文档放出来,我大概看了一遍,推荐按下面的顺序阅读,可以最快的对这个平台的概貌有所了解:
1. 《SIP White Paper》, pp 16, REST API调用规范:
http://isv.alisoft.com/isv//download/SIPWhitePaper.zip
文档有的地方过于简略,从pp 19开始看会明白参数都往哪里放。
2. 《ISV接入必备宝典》: http://forum.alisoft.com/viewthread.php?tid=3041
3. 《API参考手册》:http://isp.alisoft.com/apidoc/api/apiIndex.html 或者
http://isv.alisoft.com/isv/html/showhtml.jspa?html=/html/alisoft/api/apiliebiao.html
4. 其他的:http://isv.alisoft.com/isv/html/showhtml.jspa?html=/html/portal/newisvguide.html

雅虎执行副总裁陆奇将向何方

有幸在2006年底听过陆奇一堂课,讲panama项目的,深深折服于他对互联网广告市场的精深知识和深入浅出的讲解。而最近雅虎动荡,陆奇也已正式离开,但是却依旧不知所踪。所以搜索、摘编了一些相关资料,希望对陆奇感兴趣的同仁也能够从中管窥一二。有一些时间无从考证,如有纠错或准确信息,请提供给我(hmisty AT gmail DOT com),谢谢!

有关陆奇的线索整理:
不详 中国复旦大学计算机系学士
不详 中国复旦大学计算机系硕士
不详 中国复旦大学留校执教
1992-1996 美国卡内基梅隆大学(CMU)计算机系博士
1996(?) CMU博士后(?)
1997(?)-1998 IBM公司Almaden研究所
1998.8.17 加入雅虎(Yahoo!)
2006.4.14 雅虎,资深副总裁
2007 雅虎,执行副总裁;主持Panama广告系统研发工作
2008 主持Panama升级版Apex系统研发工作
2008.6.19 TechCrunch撰文称路奇将离开雅虎,因为Yahoo-Google达成搜索合作协议后,陆奇的位置就显得不那么重要了 [2]
2008.6.19 Wall Street Journal的BoomTown栏目撰文,透露了路奇与风险投资公司Graylock的David Sze共进晚餐的消息。Graylock是Facebook的VC之一,而且David Sze也直言不讳的说想拉陆奇上船 [3]
2008.8.31 last day at Yahoo! [9]

最后补充两个听吴炯讲的陆奇的小故事:
之一是陆奇工作是如何拼命。陆奇连续一年多每天只睡4~5个小时。出差在外,午
夜,吴炯要睡觉了,陆奇说,我要再开一个电话会议。
之二是陆奇谈到自己为什么要留在雅虎而不是跳到Google,因为在Google只能跟随
别人,而在雅虎则可以打败Google、创造历史。

参考资料
1.
http://www.tektalk.cn/2008/05/06/%E9%99%86%E5%A5%87-%E9%9B%85%E8%99%8E%E6%89%A7%E8%A1%8C%E5%89%AF%E6%80%BB%E8%A3%81/
2.
http://www.techcrunch.com/2008/06/19/yahoos-executive-structure-crumbles-lu-garlinghouse-and-makhijani-to-leave/
3.
http://kara.allthingsd.com/20080619/boomtown-has-yahoos-qi-lu-in-video-sights-and-flubs-it/
4. http://www.kuqin.com/itman/20080407/6113.html
5. http://www.zzchn.com/news/20080620/89550.shtml
6. http://news.xinhuanet.com/internet/2008-06/20/content_8407436.htm
7. http://www.china.com.cn/economic/txt/2008-06/30/content_15907203.htm
8.
http://news.newhua.com/news1/net/2008/624/08624134949B6D21830H24B3D8H7515CG0D823D196KJ36F964HD20B.html
9. http://news.ccw.com.cn/internet/htm2008/20080621_449993.shtml

星期六, 九月 06, 2008

土总赠言

土豆岑之巍箴言相赠:

一、诚心为思想之本。
二,忘我以求道。
三,遍习诸艺。
四,广涉百业之道。
五,了解诸事的利弊得失。
六,培养辨别事物的眼光。
七,洞悉肉眼不可见之事。
八,留心细节小事。
九,不做无功效之事。

句句珠玑,谨记之。