2008-07-10

你会用Protocol Buffers吗？

关键字: google, protocol buffers

这两天在我常去的网站上都有关于Protocol Buffers的新闻，光看新闻里吹嘘得这么好，感觉有点不过瘾，于是抽了点时间来了解整个项目。下面是我个人对Protocol Buffers的理解和看法：

 

1、项目背景

我觉得该项目的主要目的是用于处理复杂数据结构定义，这是XML文件所不能满足的；而数据文件大小和读写速度并不是那么重要；再说google并没有给出这个测试报告，具体有多大的优越性，这个还得打个问号（当然，我是相信google声称的文件的大小要小3-10倍，解析速度要快20-100倍）。

 

2、项目初探

Protocol Buffers的确很轻量级，拿Java来说，除了protocr外，源代码也就20来个；定义数据结构的描述文件也很简单易懂，基本上不需要注释说明；通过描述文件生成的源码会将数据结构封装成类，同时会提供一个静态Builder类，数据结构和数据组装的Builder都有明确的情况下，数据解析装配的数据应该会有所提升，还不需要其它工具的辅助。看来自己了解自己才是王道！对于文件大小这一点，对比一下两类文件就很明显，少了XML文件的复杂节点信息，存储的数据量小了，当然文件大小也就小了。

 

3、Protocol Buffers数据语言不是标准

现在在用Protocol Buffers的也就是google，用户群很小，外加不是标准，其它的一些组织还不一定卖google的帐；即使它有这么多优势在这里，但它是不是项目比不可少的，还值得讨论。

拿当前软件开发现状来说，配置文件已经是满天飞了，每个项目都有一大堆的配置问题，Java这边的趋势是用Annotation来替代配置，而ROR也是用约定来消除一些不必要的配置；Protocol Buffers还能在那些地方派上用场呢？

a.配置文件——感觉大材小用，一般的配置信息的数据结构都不复杂，对读写时的性能要求也不高；

b.数据文件——应该还是与数据库无法比，安全性，可操作性，可靠性都存在不足。

 

因此，除非是一定要在项目中处理复杂的数据结构文件时，可以考虑Protocol Buffers；否则，观望……

评论
menlong999 2008-07-13
为什么只做配置文件用？我想google来使用Protocol Buffers，主要是作为数据交换格式，而非配置文件，用作配置文件仅仅是附加的功能而已。
比如rpc，比如在socket中做数据协议，并且提供跨语言。如果一个c++的服务端和java的客户端，用socket来通讯，传统的方式会定义基于c结构体的私有协议（当然也可以用webservice之类，或者基于xml的私有的文本协议），而改用Protocol Buffers，不仅协议简单，易于描述，二进制数据量极小，没有大坨大坨的xml标记，定义为optional的字段可以非常便于扩充和兼容老的协议，并且google所宣称的比xml高的多的效率等等因素，个人认为还是非常不错的数据交换格式。
menlong999 2008-07-13
为什么只做配置文件用？我想google来使用Protocol Buffers，主要是作为数据交换格式，而非配置文件，用作配置文件仅仅是附加的功能而已。
比如rpc，比如在socket中做数据协议，并且提供跨语言。如果一个c++的服务端和java的客户端，用socket来通讯，传统的方式会定义基于c结构体的私有协议（当然也可以用webservice之类，或者基于xml的私有的文本协议），而改用Protocol Buffers，不仅协议简单，易于描述，二进制数据量极小，没有大坨大坨的xml标记，定义为optional的字段可以非常便于扩充和兼容老的协议，并且google所宣称的比xml高的多的效率等等因素，个人认为还是非常不错的数据交换格式。
Sam1860 2008-07-13
引用
XML是对机器友好的,着你都读得懂,还怕读不懂Protocol Buffers么


2进制才是机器友好的，其他数据格式都是向人类友好过度
hax 2008-07-13
Protocol Buffers好像是一个二进制协议。自Web Services出现以来，一直有人搞二进制协议，但是始终不成气候，我觉得Google这个也悬。
neodoxy 2008-07-12
引用
虽然Protocal buffers可能效率上会好一点，但是它的配置文件结构不如xml清晰，可读性效差！

XML是对机器友好的,着你都读得懂,还怕读不懂Protocol Buffers么
soartju 2008-07-11
不过在网络上传输数据，数据的大小，解析速度是很重要的，尤其是大量的数据的情况下
sunny_ljiang 2008-07-11
呵呵，我看最关键的问题还是在交互上面，XML文件现在已经成了交互文档事实上的标准，例如两个系统集成，必然涉及数据的相互转换，在这个领域XML已经是被公认了的格式，而google的这个格式即使是性能再好，也代替不了XML文件。
numenzq 2008-07-11
引用
说白了，就是不知道他想取代谁！


我觉得google把内部数据交换格式的protocal buffers开源了，出来也是给大家多一个选择，而拿XML文件做比较也是因为XML是当下的主流；对于取代谁谁谁的说法，目前还没有感觉到，也没必要想这么复杂，什么能满足我们的需求，我们就用什么呗。
stray 2008-07-11
Protocol Buffers我最不看好的一点就是缺少数据校验的能力，就像xml的xsd，而对于网络数据交换的载体来讲，校验却是必不可少的。如果仅仅作为配置文件，我想他绝对比不上xml，因为作为配置文件来讲，解析速度和文件大小就显得不是很重要。对于那些完全不需要校验的场合，我不清楚他相对于json有什么竞争力。
说白了，就是不知道他想取代谁！
numenzq 2008-07-11
引用

Protocol Buffers 是不是文本形式?
谁能贴个示例上来啊?
我没google到
Protocol Buffers到底什么样??


不是纯文本形式，就拿google自带的例子来说，输入的数据为：
Enter person ID: 211
Enter name: numenzq
Enter email address (blank for none): numenzq@javaeye.com
Enter a phone number (or leave blank to finish): 86-23-12345678

用UE打开该数据文件，内容为：

.
numenzq?numenzq@javaeye.com"
86-23-12345678

输入的Id不见了，其他信息都还能看见，中文也没问题，不过中间多了些无法识别的符号，转换成16进制就能看出这些符号是一些标示，比如说第一组数据每个字段后面两字节为10 01，第二组就为10 02，类似这样的东西。
numenzq 2008-07-11
引用
虽然Protocal buffers可能效率上会好一点，但是它的配置文件结构不如xml清晰，可读性效差！


不会吧，可读性差？比如下面的例子，你可以看作是定义个Person类，有两个必填字段id和name，还有一个可选字段email，然后定义了一个枚举类型PhoneType，还有一个PhoneNumber类及相应属性。

引用

message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;

enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}

message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}

repeated PhoneNumber phone = 4;
}
zhxp791008 2008-07-11
第一次看见。好东东。
在SOA越来越热的今天。我想这个东东，终有一天会大有用途。
有时间研究下，在项目中取代xml。
snsnx 2008-07-11
虽然Protocal buffers可能效率上会好一点，但是它的配置文件结构不如xml清晰，可读性效差！
fins 2008-07-11
Protocol Buffers 是不是文本形式?
谁能贴个示例上来啊?
我没google到
Protocol Buffers到底什么样??
lilee84 2008-07-10
网络交换的协议数据啊。
thinkx 2008-07-10
最适用于大批量结构化数据传输交换，这方面主要看两个因素：冗余数据多少和编解码效率，综合看来Protocol Buffers好像是比xml强很多。
galaxystar 2008-07-10
用文件做IPC用 protocol buffer好像不错
numenzq 2008-07-10
恩，如果用Protocol Buffers作为数据交换的载体，它的语言和平台无关性，以及文件小等优势都很明显，这一点很重要，我当时没想到：）
robbin 2008-07-10
在不同的系统之间进行数据交换，这个时候Protocol Buffers就可以发挥非常大的作用了。

例如现在的Web Services普遍使用XML进行数据交换，我知道的是有些电子商务网站在使用Web Services进行服务调用的时候，由于XML数据量比较大(XML里面有上万个节点)，很容易就造成了应用程序的内存溢出。

所以很多非常依赖Web Services的软件厂商都开始用json来取代XML，问题是json并不能够表示非常复杂的数据结构，这种场景Protocol Buffers是非常合适的。而且这种场景现在越来越多。
发表评论

您还没有登录，请登录后发表评论

numenzq
搜索本博客
存档
最新评论