原文是：《别为大公司拼命》 作者：Paul Graham 译者：阮一峰 地址：http://www.ruanyifeng.com/blog/2010/08/not_working_hard_for_a_big_company.html

评论：

分三个方面来讲：
1、从常态来说：
事实上，一个正常的公司，应该只期望（或者说只能期望）员工付出正常的劳动（正常的劳动与得过且过，向平均水平看齐大有不同）；
一个不正常的公司，才会期望员工“拼命付出”。

2、从激励来说：
作者这篇文章假设“只有能够精确衡量员工贡献，并给予精确回报的公司，才能够激励员工拼命。”
实际上，真正能够激励员工付出更多的，甚至是不计回报的付出更多的公司，不是靠精确衡量+精确回报；而是靠企业文化与很多理想主义的东西。

3、从策略来说：
这当然是一个博弈论的问题，作者看似采取了一个“最佳策略”——向平均水平看齐。
一个公司内部的员工，如果都在向平均水平看齐，当然是一件糟糕的事情。 因为向平均水平看齐的结果就是平均水平越来越低。
这是任何一个公司，都必须避免的现象，无论公司大小。
一个大公司，如果越是能够避免这样的“最佳策略”，才越是能发展成为更大的公司。
反之，就离破产不远了。

http://bambookbbs.sdo.com/show.aspx?id=7535

最初是因为想给老婆大人找一本女性喜欢的小说，那种种马、YY、历史传奇类的，她都不喜欢，我就在起点搜书里，挑了一本《平凡的清穿日子》给她看。

结果一看之下，她就沉迷了，不但自己沉迷，还反复的向我推荐，真好啊，真好啊。你看看吧，你看看吧。

作为一个从善如流的好老公，我也就勉为其难的看了起来。。。没想到，嘿，还真是不错。作为一个现代人，穿越到清代早期，生在一个中等官吏的家里，然后慢慢的长大，认识很多人，学了很多古代人的本领，然后努力的追求自己的幸福。这部书与一般穿越小说，最大的区别就是：早早的显露出聪慧和先知，是取死之道，动不动就想搞什么发明创造，十有八九要被人当成妖孽和怪物，自保很重要，韬光养晦很重要。

另外一本《春光里》，是目前Loeva正在写的一部小说，我跟我老婆都在追看。前面的一部小说，就有人评价说：再平凡，也是一个满族官员的女儿，命运自然会好很多。结果Loeva就另外写了一本，女主一开始就是一个“家生子”（侯府仆人的孩子），生来就是要当奴仆的。然后，追求能够掌控自己命运的自由，成为小说的主线。

当然，这样的设定也难免会遭人批评，说是“过于虐主，到现在还是没有摆脱奴籍～～”，唉，众口难调啊。

两本书，有一个共同的特点，就是文笔都非常好，这不是那种华丽优美的好，而是清新淡雅的好，不刻意，不做作，不粉饰，不雕琢，平平实实的写来，书中的人物就活在你面前了。

没有什么爆笑的语言，没有什么紧张刺激的情节，没有什么你死我活的爱恨情仇，都是些平平常常的小事，但是就能够让你津津有味的读下去。毕竟，生活就是在平淡中显出精彩来的。

向所有不追求重口味的朋友，推荐这两本书。

国史类之一

国史类之二

《读库》全系列

外国历史类

外国小说类之一

外国小说类之二，最醒目的是村上春树系列，几乎都有了 。

国内小说类之一

国内小说类之二

国内小说类之三

宗教哲学类

经管类

古代文学类

套书类之一

套书类之二

书架全貌。

如果，我早点有锦书可用的话，我们家的书架也许不会堆这么多书。

《Bambook锦书》–盛大创新院出品！8月9日，震撼内测，敬请期待!

http://bambook.sdo.com/

一、舟山跨海大桥组图

二、舟山喜来登绿城酒店

三、大青山自驾游线路

四、老友强海鲜面

http://www.dianping.com/shop/2063446

五、回程时的蓝天

整个会议的视频专辑地址在：

http://v.ku6.com/playlist/index_3811528.html

今天演讲的效果还是不错的，demo也顺利的跑出来了，嗯，不错！

而“云计算”，则是新一轮IT技术大发展的标志性词汇。在云计算的大旗下，汇集了众多的技术分支：并行计算（Parallel Computing）、分布式计算（Distributed Computing）、虚拟化(Virtualization)、效用计算(Utility Computing)、IaaS(基础设施即服务)、PaaS(平台即服务)、SaaS(软件即服务)等等。

在这样的技术大潮之下，有一个方向应该被称之为“云计算”的正宗！“任何一段代码，都可以被分配到任何一台电脑上执行，巨量的、繁复的计算与执行任务，能够被透明的、高效的、均匀的分配到海量的计算资源上执行，充分利用计算机群的计算能力。” 这是一个非常有难度，也非常有价值的研究方向。

目前，盛大创新院，举办了一个“云计算脚本虚拟机”的技术大赛，这次大赛，是2010年“盛大校园牛人”创新技术大赛的一部分，更进一步的，则是整个盛大高校节的一部分。

这个题目，的确非常的难，具有超高的挑战性，因此，大赛组委会设计了一个循序渐进的题目与比赛规则，从最简单的“Hello World”到极度复杂的跨服务器，跨脚本联合定时任务，完全可以任你发挥。作为一个深度和广度都足够的挑战项目，最适合真正的牛人，来展现自己的实力！

优秀参赛者，将会机会获得优越的职业发展前途、来自盛大网络的投资和佣金分红，更有30W丰盛奖金等你来拿！因为有你，技术才真的创新！

参赛地址：http://ic.sdo.com

盛大高校节总站：http://campus.snda.com

1、TCT的存储数据结构

TC的不同的数据类型，有不同的数据存储结构。这里主要介绍TC的Table类型的存储结构。

每个TC的Table，起码有一个*.tct文件。这个tct，是在hash数据库的基础上改进而来的。下面转贴几张张宴的PPT里的图。

TCT的改进，就是在Hash的Key-Value的Value部分，动了一些手脚，将多个字段打成一个大包，都存在一个Value里去了。

另外，TCTDB，有可能会有一个*.tct.idx文件，这个idx，是一个B+Tree结构，将一个table中的各个需要建立索引的字段数据，在TCBDB中建立索引。

TCBDB的结构图如下：

在idx文件里，则是将value与key反过来存放。

2、TCDatabase的存储数据结构

为了解决之前提到过的TCTDB存在的问题，我们设想的TCDatabase的结构，将是这样的：

1、表结构(data.tcb.cfg) TCHDB
table_name1 => {column1=>string,column2=>int}
table_name1_count => 10
table_name1_index => {column1,column2}
table_name2 => {column1=>string,column2=>int}
table_name2_count => 10
table_name2_index => {column1,column2}
2、记录集(data.tcb)  TCBDB
table_name1/pkey1.column1 => value1
table_name1/pkey1.column2 => value2
table_name1/pkey2.column1 => value3
table_name1/pkey2.column2 => value4
table_name2/pkey1.column1 => value5
table_name2/pkey1.column2 => value6
3、索引(data.tcb.idx)  TCBDB
table_name1/column1/value1\0pkey1 => pkey1
table_name1/column1/value3\0pkey2 => pkey2
table_name1/column2/value2\0pkey1 => pkey1
table_name1/column2/value4\0pkey2 => pkey2
table_name2/column1/value5\0pkey1 => pkey1
table_name2/column1/value6\0pkey2 => pkey2

下面做一些解释：

• 增加一个cfg文件，一个Hash DB方式存储表结构信息，包括一个表包含哪些字段，这些字段分别是什么属性，一个表的记录总数，这个表需要建立哪些索引等等。
• 记录集以B+ Tree方式存放，而非原来的Hash DB，这样可以在数据量上亿以后，获得更好的性能
• 在记录集中，一行数据的各个字段的值，分别存在不同的key-value中，因此，如果一个表有3个字段，那么它的每条记录，就要占3个key。
• 在读写数据时，有两种方式可以选择：按行读写，或按列读写
• 所谓按行读写，就是一次读写一个primary key指向的n个字段，具体有哪些字段，由cfg决定。
• 所谓按列读写，就是一次只读写一个primary key指向的那一行中的具体一个字段，这时的读写，不受cfg中的table字段定义的限制。
• 索引数据，以B+ Tree方式存放，因为不同的行(primary key)，在某一个字段，可能存在值重复，因此key的规则为：value\0key。这样保证每一个primary key，会有一个对应的索引key。如果以“table_name/column/value”的方式查询，则可以将同值的多个key，都查出来。

（未完待续）

1、简单介绍

介绍这个，其实价值不大，因为详细的文档都在那里呢：http://1978th.net/tokyotyrant/spex.html#protocol

不过，还是要说一下，因为我对TT的协议，颇有些不满。

TT的协议，各位如果仔细看，就会发现，这是一个典型的未经重构的，临时拼凑起来的协议。最初的TT，只考虑了基本的put、putkeep、putcat、out、get、mget等等命令，每个命令都以0xC8开头，然后再加上一个16位二进制数。

put          0×10

putkeep   0×11

putcat      0×12

putshl      0×13

putnr       0×18

out          0×20

get          0×30

mget       0×31

……

但是，他还有一个misc命令，所有与Table数据类相关的命令，都包含在misc里面，misc的格式是这样的：

[magic:2][nsiz:4][opts:4][rnum:4][nbuf:*][{[asiz:4][abuf:*]}:*]

magic:  0xC8 0×90

nsiz:     name的长度

opts:    option参数

rnum:   后续参数的个数

nbuf:    name

asiz与abuf交替出现，表示每一个参数

因此，我们针对RDBTBL的操作，最终都会调用misc命令。

rdb = RDB::new

rdb.open(“localhost”, 3900)

rdb.put(“foo”, “hop”)

#发出0xC8 0×10 0×0003 0×0003  “foo”    “hop”

#      magiccode ksiz      vsiz       kbuf*   vbuf*

rdb = RDBTBL::new

rdb.open(“localhost”,3900)

rdb.put(“foo”,{“hop”=>”value”})

#发出0xC8 0×90 0×0003 0×0000  0×0003  “put”    0×0003 “foo”     0×0003 “hop”    0×0005 “value”

magiccode nsiz      opts      rnum      nbuf*  asiz1    abuf1*  asiz2    abuf2*  asiz3    abuf3*

看上去非常类似的代码，发出的网络数据流，却完全不同。

2、misc的问题

TT的协议中，最麻烦的，就是这个misc命令，效率最低的，也是这个misc命令，Table型数据，一共支持10个不同的命令，却全部被堆到一个misc里来完成了。

按照某种合理的逻辑，这些命令，应该跟正常的其他命令类似，各自分配到自己的magic code，各自有自己的命令格式和定义，而不是像现在这个样子。

即使是这个misc本身，也非常糟糕，将key与value，放到一个数组里，而且整个数组也没有一个总的长度，使得解析也变得效率低下了。

目前的TCDatabase，因为是在TT的skeleton基础上开发，因此接收的命令与TT完全一致。这当然降低了开发的难度。但是，要想进一步改善TT，或者说要想做出一个TCDatabase，抛弃现有的二进制协议，另起炉灶，应该是一个必然的选择。

3、TCDatabase的协议设想

这个是一个初步的设想，还需要跟riceball详细讨论，才能确定下来：

• 每个命令一个不同的magic code
• [key_size] 如果需要key作为参数的话
• [key_buf*] 如果需要key作为参数的话
• [opts]        选项
• [arguments_size]  参数总长度
• [arguments_length]  参数个数
• [arguments_1_size]  第一个参数的长度
• [arguments_1_buf*]  第一个参数
• ……

相比原来的TT协议，这样应该更容易解析一些，效率也会有提升。

(待续)

他自己也写了两篇blog作介绍。tcdatabase(一） tcdatabase(二)

不过我总感觉写得太像干巴巴的技术文档了，所以我自告奋勇的来帮他另写一个介绍，以下是第一部分：

一、TokyoCabinet、TokyoTyrant简介

我们常说的TC/TT，是TokyoCabinet/TokyoTyrant的简称。这两个开源项目，都是由日本人平林幹雄开发的。（Mikio Hirabayashi’s Homepage twitter: @hirabayashiM）

1、TokyoCabinet

TC，是一个Key-Value的数据库library，你可以通过C语言程序来访问TC提供的各种函数，也可以使用其他各种语言绑定，例如perl、ruby、java、lua。

TC对外的表现形式，无非是一组put/get方法，从内部实现来说，TC一共支持6种不同的数据结构，包括hash数据库，B+树数据库，定长数据库、表格数据库、内存hash数据库以及内存B+树数据库。

以ruby语言举例：

hdb = HDB::new

hdb.open("casket.tch", HDB::OWRITER | HDB::OCREAT)

hdb.put("foo", "hop")

value = hdb.get("foo")

hdb.close

这样就可以创建一个名为casket.tch的Hash数据库文件，并进行put/get的操作。

也可以通过ADB（Abstract database），以完全相同的API，创建并访问不同的数据库。

adb = ADB::new

adb.open(name) 

…

adb.close

其中，如果name为*，则创建一个内存hash数据库；name为+，则是内存B+树数据库；文件名为*.tch、*.tcb、*.tcf、*.tct则分别对应于hash、B+Tree、fixed-length和table类型。

2、TokyoTyrant

至于TT，则是在TC基础上实现的一个server。TT接受来自socket连接的各种请求，作为一个网络服务而存在着。通常我们会这样来启动TT。

ttserver –port 3900 /ttdata/casket.tch

这样，在3900端口，就启动了一个数据库服务，这个数据库的数据，就保存在/ttdata/casket.tch中。

而在client端，也多种不同的语言实现，例如ruby的代码会写成这样：

rdb = RDB::new

rdb.open("localhost", 3900)

rdb.put("foo", "hop")

value = rdb.get("foo")

rdb.close

对于table类型的数据库，则需要创建一个RDBTBL的对象实例，因为它提供了更多的一些访问API，例如：

rdb = RDBTBL::new

rdb.open("localhost", 1978)

rdb.put("1", { "name" => "mikio", "age" => "30", "lang" => "ja,en,c" })

qry = RDBQRY::new(rdb)

qry = RDBQRY::new(rdb)

qry.addcond("age", RDBQRY::QCNUMGE, "20")

qry.addcond("lang", RDBQRY::QCSTROR, "ja,en")

qry.setorder("name", RDBQRY::QOSTRASC)

qry.setlimit(10)

res = qry.search

res.each do |rkey|

  rcols = rdb.get(rkey)

  printf("name:%s\n", rcols["name"])

end

这样的操作，就已经相当接近于对一个传统表的操作了。

二、TCDatabase对TokyoTyrant的扩展

1、skeleton机制

TT对于扩展的支持相当友好，在ttserver中，有一个-skel参数，可以在启动ttserver的时候，挂一个自己写的骨架系统，例如：

ttserver -skel mydb.so -port 3900 myfile.tct

这样，ttserver的功能，就成了一个简单的网络接口，而接收到的各种请求，都为转交给mydb.so来处理。接下来的事情，就海阔天空了。对于client端来说，他访问的是标准的TT接口，而在server端，却完全可以通过自己写的一个扩展，将数据存到mysql里面去。

而tcdatabase，就是TT的一个skeleton实现。所以，他的启动参数是这样的：

ttserver -skel tcdatabase.so -port 3900 db_filename.tcb

2、TCTDB的不足之处

作为最像传统表的Key-Value数据库，TCTDB有很多优点，这成为我们项目选择的主要考虑对象，但是它也存在着诸多问题：

• 一个Table Database仅支持一个表，也就是说value中的字段必须固定一致。假设一个项目中使用了80多个表，这意味着你需要开启80多个 ttserver进程，并为每一个“表”提供支持。
• 功能的增强,也就意味着要牺牲性能。TCTDB 表格型数据库的平均读取速度大约在40万条/秒,相比 TCHDB哈希数据库的180万条/秒和TCBDB B+Tree数据库 的100万条/秒要慢。
• TCTDB虽然可以建立数值型索引,但是它是将所有value数据都当成字符型来处理的,无法区分value类型。
• TCTDB单数据库文件存储的记录数上亿条后,性能会有比较明显的下降。
• 不能单独获取value中的某一个字段的值；
• 不能支持仅更新UPDATE key中某一个字段：必须先取出value的全部字段，再存入；

3、TCDatabase的改进

• 支持多个table从一个端口访问，从table变成真正的database，
• 数据文件改用采用TCBDB(B+Tree Database)进行存储，为了解决数据量上亿后的HashDB性能的问题
• 支持列读写
• 应该还有其它更多改进，不过都还在规划之中

(待续)