- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【求助】翻译出版一本书，求译者 -- 邓侃
人民邮电出版社，想找人翻译一本书，
Next Generation Wireless Application
书比较长，590页，所以最好几个人分工合作。
有意者，请给我发个短信。
谢谢。
有个小算盘。
这本书的内容或许比较有趣，是否可以这样，谁担当翻译，不妨把翻译的内容先贴到河里来，
1. 让河虾们先过过瘾。
2. 发动河虾检查一下内容是否正确，翻译是否贴切。
大家意见如何？
昨天抱着娃打字，邮打成油了
邮电出版社自己提议的。
我看大家闲着也是闲着，与其相互掐，不如干点正事儿。
每个人翻译一章，甚至几节，河里交流一下。纠错，并统一翻译的用词什么的。
然后邮电出版社负责出版，在序言里说明，这不仅是几个译者的作品，而且得到了西西河广大河蟹河虾的帮助。
于河，于译者，于出版社，于中国，都是好事儿，共赢的局面。
这是个好办法
做成可下载版本，就当宣传，吸引一部分潜在读者，全放出来不适合，尤其关键核心几章，这个点子不错，有点西西译言版的感觉，不过人邮怎么总进这么大厚部头
这片偶不熟，嘿嘿，不过友情顶。
我刚刚瞄了一眼，内容不是很技术，而是谈产品定义，市场营销之类。
O'Reilly 和 Manning 出书前，会邀请活跃的读者和相关专业人士参与校对。这样讨论几轮以后，质量就很扎实。
早年干过一次，预先得到有关章节看了看。
但是也有义务，想抢先看书可以，但是要有回馈。否则，下次就不好意思了。
我看，我们可以搞个私版。全部章节，在私版里讨论。
公版放几个样章，吊吊大家胃口，随便做点宣传。
正想学习这方面的东西呢。
Paul Golding在业界得到的评价如何呢？
首先非常感谢大家。感谢每一个回复的人。
现在这本书有这样的情况：时间要求比较紧，希望最好能在10月底就翻译完，最晚不要超过11月10号。所以，希望能找到在这段时间里比较空闲的译者。希望多找几个译者，每个译者选取自己最有把握的部分，这样来分配全书。
还有，通常情况下对于还没有译著的译者，我们都是要求试译的。现在由于时间比较紧迫，希望参加翻译的朋友，如果没有译著的话，最好能把自己翻译过的文章发给我们看一下，有那么几段就可以。
另外，我们的封面上上的译者，一般来说不宜超过三个，个别情况下也可以多一些，但如果太多了封面设计上就不好看了，所以封面署名可能就写某某某 某某某 某某某等译，其余的朋友，可能要放在译者序里分别交代一下，都是谁，翻译了哪些内容。总之，每一个参加翻译的朋友，他的劳动一定会在书中得到体现的。
暂时说这么多。谢谢大家！！
请注意这是发表在网络上面的，而且是翻译论文，所以文字比较随意，还有自己的发挥（没办法，学校里面seminar习惯了，读论文一定要评论的）
大表(Bigtable):结构化数据的分布存储系统
http://labs.google.com/papers/bigtable-osdi06.pdf
｛中是译者评论,程序除外｝
{本文的翻译可能有不准确的地方,详细资料请参考原文.}
摘要
bigtable是设计来分布存储大规模结构化数据的，从设计上它可以扩展到上２^50字节，分布存储在几千个普通服务器上．Ｇoogle的很多项目使用ＢＴ来存储数据，包括网页查询，google earth和google金融．这些应用程序对ＢＴ的要求各不相同：数据大小（从URL到网页到卫星图象）不同，反应速度不同（从后端的大批处理到实时数据服务）．对于不同的要求，ＢＴ都成功的提供了灵活高效的服务．在本文中，我们将描述ＢＴ的数据模型．这个数据模型让用户动态的控制数据的分布和结构．我们还将描述ＢＴ的设计和实现．
１．介绍
在过去两年半里，我们设计，实现并部署了ＢＴ．ＢＴ是用来分布存储和管理结构化数据的．ＢＴ的设计使它能够管理2^50 bytes(petabytes)数据，并可以部署到上千台机器上．ＢＴ完成了以下目标：应用广泛，可扩展，高性能和高可用性（high availability）. 包括google analytics, google finance, orkut, personalized search, writely和google earth在内的60多个项目都使用BT.这些应用对ＢＴ的要求各不相同，有的需要高吞吐量的批处理，有的需要快速反应给用户数据．它们使用的ＢＴ集群也各不相同，有的只有几台机器，有的有上千台，能够存储2^40字节(terabytes)数据．
ＢＴ在很多地方和数据库很类似：它使用了很多数据库的实现策略．并行数据库［１４］和内存数据库［１３］有可扩展性和高性能，但是ＢＴ的界面不同．ＢＴ不支持完全的关系数据模型；而是为客户提供了简单的数据模型，让客户来动态控制数据的分布和格式{就是只存储字串，格式由客户来解释}，并允许客户推断底层存储数据的局部性｛以提高访问速度｝．数据下标是行和列的名字，数据本身可以是任何字串．ＢＴ的数据是字串，没有解释｛类型等｝．客户会在把各种结构或者半结构化的数据串行化｛比如说日期串｝到数据中．通过仔细选择数据表示，客户可以控制数据的局部化．最后，可以使用ＢＴ模式来控制数据是放在内存里还是在硬盘上．｛就是说用模式，你可以把数据放在离应用最近的地方．毕竟程序在一个时间只用到一块数据．在体系结构里，就是：locality, locality, locality｝
第二节描述数据模型细节．第三节关于客户ＡＰＩ概述．第四节简介ＢＴ依赖的google框架．第五节描述ＢＴ的实现关键部分．第6节叙述提高ＢＴ性能的一些调整．第7节提供ＢＴ性能的数据．在第8节，我们提供ＢＴ的几个使用例子，第9节是经验教训．在第10节，我们列出相关研究．最后是我们的结论．
２．数据模型
ＢＴ是一个稀疏的，长期存储的｛存在硬盘上｝，多维度的，排序的映射表．这张表的索引是行关键字，列关键字和时间戳．每个值是一个不解释的字符数组．｛数据都是字符串，没类型，客户要解释就自力更生吧｝．
(row:string, column:string,time:int64)->string {能编程序的都能读懂，不翻译了}
我现在要去顺义参加一周的国际通信展，22号结束。这段时间恐怕没时间上网。等我回来跟您交流。
我的联系方式：
[email protected] (MSN)
Tel:13671179091