作者文章: Fenng

技术出版的危机

这个话题的缘起是今天我在 Twitter 上感慨了一下关于翻译稿酬的事情。我和两位同事一起翻译 Troubleshooting Oracle Performance 这本书(中文版《Oracle性能诊断艺术》),三个人,六个月时间出头,稿酬大约 15000 RMB 多一点。很多朋友可能会把这当成抱怨而非提醒。

对此,图灵出版社刘江先生回应到,”技术出版的危机。此书首印 3000 册,定价75 元(不低),利润空间仅两三万,如果部分滞销或退书,很容易就赔了。” 而且,”这本书如果按5%给版税,还不如千字稿酬。” 这实际上道出了当前英文 IT 图书引入国内的一个困境。国外出版社版权费用本已经不低(所以博文视点更倾向于做原创图书,别搞错,我说的是武汉的那个博文),加上纸张以及印刷成本的上涨,以及图书销量连年受到网络媒体的冲击,做一本纸版书不亏本已经不容易了,现在据说在国内一本技术图书能做到 5000 册的销量就是不错的成绩了,出版社不得不通过一些不得以的手段控制成本。有一次和蔡学镛聊天,他说台湾现在的 IT 图书出版已经萎缩得不成样子,而大陆因为市场太庞大,所以一时半刻还能撑下去。

李笑来老师曾经质疑过”为什么引进书籍的翻译普遍都很差?“,他认为直接原因就是”稿费太低”。对于译者来说,如果只是为了稿费而做技术翻译的的话,绝对是一件收益不大的事情,何况,这事情本身就是一件”瓷器活儿”。翻译得好的话,必然需要投入更大的精力,而译文质量不过关,读者不会饶过你。我相信像余晟这样把翻译当作一种乐趣的人已经凤毛麟角了,而像阮一峰那样偶尔的”头脑发热“一回也是值得我们欣赏的。

国内出版社有的时候自己也扮演杀鸡取卵的事情,据我所知,多数出版社对于翻译时间的限制都比较紧,一本书,一般只给译者 3-6 个月的翻译时间,为了能在既定时间之内完工,要么找更多的的合作者–这会带来翻译风格不统一的问题,译稿质量也难免下降,要么拖延,而拖延,在合同里是写着明确条款的,会根据不同的时间扣除稿费。也就说,如果遇到了不良出版社,而你的合同时间又签得比较不利,那么可能一分钱拿不到。当然,我们这本书总体来说编辑还是比较宽松的,这是非常值得庆幸的一件事。其实话说回来,我认识的几个出版人如果他们转身去做畅销书,至少不会比做 IT 差,或许他们为了理想也在咬牙坚持。

危机,危机,危险之中机遇何在?

EOF

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

MySQL 数据库版本调查与分析

针对 MySQL 数据库的版本也做个调查。分析一下大家使用 MySQL 的趋势与习惯。选择大家都选择的,总不会有更大的错误。而如果使用了一个不太合适的版本,或许会后患无穷。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

现阶段收集到的统计数据:

MySQL_version_chart.png

国内用户用 5.0 的是最多的。如果小版本加起来还是 5.1 的居多。4.1 的版本渐渐推出历史舞台。如果你也在考虑选择 MySQL 的版本,这个数据是否对你有参考性呢?

EOF

Oracle 数据库版本调查与分析

据我所知,很多第三方公司给客户实施的时候,选择的 Oracle 版本 都是非常随意的。数据库软件的版本选择多少是有点技术含量在里面的,毕竟数据库这东西要升级并非易事。这里小范围调查一下大家都在用 Oracle RDBMS 的哪个版本,然后把分析数据和大家分享一下。或许会对新手 DBA 有一定的参考价值。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

统计数据:

Oracle_version_chart.png

出乎我的意料,9.2.0.8 这个版本现在用的人并不是特别多了(没有我预期的多),而10.2.0.4 这个版本现在看起来像是不少用户的选择,这其实也侧面说明着很多用户升级到 11g 还需要一段时间。版本的分散意味着 Oracle 升级的难度的确不小。

不少明显质量不够稳定的版本也有用户在用(比如,10gR1),看来第三方实施的弊端的确不小。Oracle 一般发布的Release 1 其实多少都会有一些问题–否则也不会有后续的 PatchSet 发布了,要知道每个 PatchSet 都是包含几百个 Bug Fix 的。一般来说,在线 OLTP 恐怕少有人用 R1 的版本。

现在收集到大约 100 多份样本,相信还是有点参考价值的。

有的 DBA 对于统计所用的 URL 可访问性有疑问,这侧面验证了我另一个想法:Oracle DBA 对 Web 的熟悉整体上不如 MySQL DBA

EOF

SmugMug 的架构介绍

本文介绍的 SmugMug 是一家提供付费图片托管服务的站点,在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建,最初提供面向游戏的视频服务,随后转型为现在的模式。网站流量现在是全球 1800 多,盈利能力自称良好。

在 MySQL Conf 2009 上,SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris),300 多台 4 核(或更多)的服务器(大多是 AMD 的 CPU) ,分散在四个机房,两个运营的人员。SmugMug 充分运用了云计算服务,是 Amazon 的一个大客户,图片和视频总计达到了 PB 级,托管在 Amazon S3 上,图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速,主要是 JavaScript/CSS 等文件的加速,此外,DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中,存储引擎多数用的 InnoDB,数据超过 2TB 的空间,数据库服务器为 4 核或更高配置,内存多达 64GB。缓存方面,用了 Memcached 做加速,有 1TB 的数据在这里面,平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据,减小对 DB 的冲击。数据库设计思路是尽量做垂直分区,没有 Sharding。不过在反范式(denormalized)方面做得比较彻底,不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键,更新或者删除数据也是单行,依赖主键。InnoDB 引擎打了 Percona 的 Patch,并发能力也有了很大增强。

对 DB 的数据完整性与写能力的要求高,而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方,备份也成问题。ZFS 倒是能满足相关的需求,可惜不支持 Linux(妈的,早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外,对于复制中可能出现的风险,尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后,MySQL 放在 Sun Sushi Toro(Storage 7410,这个东西也支持 SSD ) 上,走 NFSv3 协议。写到这里,发现 SmugMug 的解决方案非常不具有通用行,看起来 Sun 是给了他们不小的硬件优惠,否则一般情况下不会有人这么搞的,用 NFS 协议走数据库,除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走),产品上真的有人跑么?

网站架构的进化,其实也是选定一个方向(比如用开源工具解决),然后一直试错的过程。

EOF