大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
Damien Katz畅谈CouchDB
受访人 Damien Katz 采访人 Werner Schuster，翻译: 郭晓刚 发布于 2009年5月14日 长度 00:19:38
概要
Damien Katz在访问中畅谈CouchDB。CouchDB是由Apache Incubator开发的一个分布式、容错、面向文档的数据库。CouchDB数据库用Erlang编写，通过HTTP/JSON API访问。数据库视图引擎运行在JavaScript上，但也有Ruby、Python等语言的替代实现。
个人简介
Damien Katz曾就职于Lotus、MySQL、IBM。他是CouchDB的创造者。并且在未来相当长一段时间内都将投身于此。
关于会议
Damien Katz在访问中畅谈CouchDB。CouchDB是由Apache Incubator开发的一个分布式、容错、面向文档的数据库。CouchDB数据库用Erlang编写，通过HTTP/JSON API访问。数据库视图引擎运行在JavaScript上，但也有Ruby、Python等语言的替代实现。
个人简介
Damien Katz曾就职于Lotus、MySQL、IBM。他是CouchDB的创造者。并且在未来相当长一段时间内都将投身于此。
关于会议
我是CouchDB项目的创始人和主管。我现在在IBM工作，之前曾在MySQL，再之前又是IBM，当时做的是Lotus Notes项目。
什么是CouchDB呢？CouchDB是一个文档数据库；它是一个支持复制的（Replecated）文档数据库，具有REST接口，也就是说可以在 HTTP上，用标准的GET、PUT、POST动词去访问。而且它用JavaScript作为查询语言去建立数据视图（View）。在SQL数据库里，你要定义各种表和表中的数据类型及大小，CouchDB不一样，它是没有Schema的。在CouchDB里，每个文档都是独立的对象，可以是任意的 JSON结构。这是技术上的表述。那么它的优点在哪里呢？它有利于构建很多协作型的应用，很多Web应用都是围绕着文档、上下文、任务、Bug报告，诸如此类的东西。这些就是CouchDB最擅长的方面。
它和Lotus Notes最接近，毕竟我从事Lotus Notes那么多年。我对整个Lotus Notes平台把握得相当透彻，知道它的真正优点。Lotus Notes上面堆彻了一大堆形同鸡肋的玩意儿，讨厌它的人比比皆是，但它的成功不是空穴来风。它已经活了很长时间，现在还有上亿用户，所以它一定有什么做得好的地方。我自己感觉知道Lotus Notes的力量源自何处，所以我要做的就是把那个核心剥出来，放进CouchDB。这个核心就是文档模型，所以说CouchDB一定很像Lotus Notes。XML数据库里面放的是单个的体型庞大的XML文档，那个模型有点不一样，我说不好。XML数据库我用得不多，但我认为是不太一样的东西。
是的。通常每个文档的结构不是随机的，它会有某种预定义的结构，但数据库不会去强制，而是由应用层去强制。以后我们会有数据库的接口让你强制文档在保存的时候遵从特定的格式或者Schema。但总的来说文档不必遵守什么Schema，那个是应用层的事情。所以它给了你很大的灵活性，看你想怎么去表达数据。比如说你有一个讨论组的数据库，你想显示主贴、显示评论、或者显示某位用户的全部文档，用CouchDB做起来都很简单。
用JavaScript，用它创建视图。如果你知道文档的名字——每个文档都有它的ID，ID可以是任意的原始字符串，也可以是随机生成的——如果你知道文档的名字可以直接问数据库要，Get那个文档就行了。如果想建立一个视图包含某种类型的全部文档，那么就创建一个JavaScript函数，视图引擎会把数据库里的每一个文档都送到这个函数面前，让它全部检查一遍。然后你的函数会确定应该把文档里的哪些信息放进视图，然后把相应的键、值放进视图，并且按键排序。所以函数能决定它遍历过的每一个文档里面哪些是它想要的。接下来你对视图做个Get操作，所有结果就会整整齐齐地放在一个JSON响应里面返回给你。
遍历全部文档，但它保留一个持久化的索引，所以每次运行的时候已经有现成的索引。当更新文档的时候，比如说更新了5个文档，它就不用重新遍历数据库中的全部文档重新建立索引。相反，它只需要找出那些发生了变化的文档，重新计算相应的结果，剔除旧的结果，调整索引，然后你就可以查询了。这个过程是自动发生的，你只要定义视图和访问视图就好了，CouchDB会处理好，帮你完成这些背后的工作。
是的。CouchDB最早是用C++实现的，结果有点碰壁。当时我有了存储引擎、有了视图引擎、有了查询语言，都是C++写的，结果我在并发问题上撞了墙，因为老是要按传统方式去处理线程、锁、消息这些事情。后来我在“Lambda the Ultimate”还是哪里看到Erlang是个非常好的并发语言，所以想看看怎么把它融合进我的代码里头。所以我就下载了Erlang，玩了没多久就认定用它写数据库引擎和服务器简直是天作之合，于是我把原来的C和C++代码扔了，全部用Erlang重写。用Erlang写这个效率高得没法说，它特别适合做这些基础设施类型的东西。它原来是为电信业设计的，电信业面对的问题和数据库有很多相似之处，比如输入、输出量都很大、要保证可靠、平滑地处理失败。所以最后发现Erlang是CouchDB最适合的实现语言。
我们用的是Mozilla Spider Monkey引擎。我们需要的是一个单独执行的命令行进程，通过它连接Mozilla Spider Monkey引擎。进程通过标准的IO与CouchDB通信。所以实际上CouchDB产生这个进程的很多实例，通过标准输出向它发送JSON，然后从建立的管道中得到响应。这样即使JavaScript进程挂起了，或者由于用了过多内存还是别的什么原因被OS杀掉了，Erlang VM都不会受到影响，可以顺利恢复。
就是来回发JSON。先是命令，像动词一样的命令，它就是一个字符串，参数紧跟在后面，就是后续的数组里面的元素。这些都送进管道，送到管道另一边去解析，然后CouchDB解析清楚你想要什么，就计算出结果送回来。像这样基于行的简单协议有个好处，就是我们可以更换语言后端。比如目前标准引擎是 JavaScript的，但我们已经有了Ruby和Python的语言后端，可能还有别的语言，好像有谁写了个PHP的。就是说你想用什么语言写查询都可以。我知道CouchDB在Python社区里面已经很流行了。
并发方面绝对有。有人抢着做了个基准测试，能达到2万个并发连接。很厉害的结果。而我们还没有做过Profiling呢。Erlang在这方面绝对给我们帮了大忙。如果我用传统的线程模型，500个活动连接就算很不错了，所以说Erlang绝对提高了单台机器的可伸缩性。Erlang对多台机器的可伸缩性也会有帮助，只不过我们暂时还没有用到那方面。有很多工具、库等等可以让多台机器的Erlang环境完成自动故障转移、高效率的消息交换等等，我们只不过还没用到那方面而已。
我还没做过Profiling，我想那个做Profiling的人也是用了多处理器，所以我想还没有谁在单进程版的Erlang上做过Profiling。
有的，大多数不满的地方还没变，不过每种语言都会有你不喜欢的地方。Erlang里面有些东西有年头了，要是放在今天去设计，绝对会不一样。而且有些东西是它的编程范型息息相关的东西，要调整就不得不打破另外一些Erlang做得很对的地方，所以说有的地方比较泄气。它的字符串处理非常弱，这是我觉得可以改进的。如果你的问题不适合函数式编程范式，应该考虑用别的语言。
我想字符串处理是挥之不去的问题。现在的字符串处理真是很低效，不但做大量字符串操作的时候非常麻烦——用Ruby或Python之类的语言处理字符串要容易、简洁得多——代码更难写，也更慢。所以说的确是个问题，我们在想办法解决。我们试过Erlang那种特殊风格的字符串，就是把每个字符都作为列表里的一个元素，最终一个字符要用16个字节存储。还有另一种二进制字符串，更接近其他编程语言里的传统字符串，语法当然难看了，不过我想肯定要换成这种字符串，因为会高效得多。
我爱用一个比方来说明什么样的应用才是合理的文档数据库应用：假设你不是在这个程序里面，假设不是在电脑上，在现实世界里你会怎么做？如果结果是有很多份文件要归档和在不同的人手里传来传去，那就说明用文档数据库是对的。如果结果是要画图或者要画一张spreadsheet，整张表是一个整体的，会计用的那种，叫什么来着？就是在纸上的电子表格，它是不可分割的，全部属于一个文档。那种情况可能意味着需要一个单独的程序（而不是数据库）。但如果这种文档有不少，又要频繁接触，像任务列表、Bug列表、客户投诉，这些东西在现实世界里都是一叠一叠的。如果是这样的情况，你就要考虑可能关系数据库才合适，也可能文档数据库才合适。由于CouchDB的本质特点，你可以离线编辑文档，上线的时候再把修改内容复制回数据库，这件事对于关系数据库是非常困难的。所以当你需要离线访问数据的能力的时候，就是CouchDB这样的文档数据库大放光彩的时候。
一开始就这样定位，而在平台上建立的第一个应用是作为面向文档的数据库的email。所以email是Lotus Notes的首要应用，但又仅仅是Lotus Notes平台上的其中一种应用。Lotus上还有很多其他应用，可以完成Bug跟踪、客户报告和CRM一类的任务，很多公司都在用它做这些事情。
Exchange一直以来都有这样的想法，比如Exchange服务器，就有类似的概念；比如共享文件夹让人们在上面搭建应用。但这些从来都没有成功过，没有人那样用Exchange。于是就有了其他类似的尝试。到了什么都搬到Web上面的时代，SharePoint就和Lotus Notes很像，只不过它像是单个实例的Lotus Notes Web服务器，而且客户端变成了浏览器。除了这点差别，它们有很多相同的地方，SharePoint是一个很面向文档的环境。这么多产品里面，我还是觉得只有Lotus Notes真正抓住了问题的关键，即使Lotus Notes在很多别的方面都做错了。我一直认为Lotus Notes是个独树一帜的产品，促使我创造CouchDB的动力也在于认为这个模型我们还探索得不够，还没有真正认识到它的价值。
BigTable——我不太认可它的优点，除了可伸缩性之外。我绝对同意它在可伸缩性方面的优势，但大多数应用都不需要那种程度的可伸缩性。它是个有局限的平台，但我没有真正用过所以不好说，我只是听过一些不满的声音。
对于OA，Lotus确实有优势
发表人
builder free
发表于
Re: 对于OA，Lotus确实有优势
发表人
qiu james
发表于
2 条回复
关注此讨论 回复