找回密码
 立即注册
查看: 367|回复: 4

国内有什么大公司使用flatbuffers吗?它和protobuffer之间如何取舍?

[复制链接]
发表于 2021-10-13 12:42 | 显示全部楼层 |阅读模式
国内有什么大公司使用flatbuffers吗?它和protobuffer之间如何取舍?
发表于 2021-10-13 12:50 | 显示全部楼层
之前写的一篇对比JSON、FlatBuffers (下文用 flatbuf 指代) 和 Protocol buffers (下文用 protobuf 指代) 的文章,测试是在 Android 下做的:
在Android中使用FlatBuffers | WolfcsTech从几个角度来讨论,
1. 接口的易用性:protobuf 的 API 易用性比 flatbuf 方便的不是一点点。flatbuf 的接口比较难用,看一下 demo 就可以大概了解。
2. 编码性能:flatbuf 的编码性能要比 protobuf 低得多,前者的性能大概只有后者的一半。在JSON、protobuf 和 flatbuf 之中,flatbuf 编码性能最差。
3. 编码后的数据长度:由于通常情况下,传输的数据都会做压缩,因而又分两种情况,编码后未压缩和压缩后的数据长度。flatbuf 编码后的数据,无论是压缩前还是压缩后,都比 protobuf 的数据长得多,前者的大概是后者的两倍。
4. 解码性能:flatbuf 是一种无需解码的二进制格式,因而解码性能要高许多,大概要快几百倍的样子。
综上,protobuf 在个方面的平衡要比 flatbuf 要好得多。但如果使用场景是,需要经常解码序列化的数据,则有可能从 flatbuf 的特性获得一定的好处,就像 Facebook 之前那样。
不过我们还是抽离了 flatbuf 的 java 库代码,并写了 Android Studio 的 gradle flatbuf 编译工具,GitHub 地址为  hanpfei/flatbuffers 。
发表于 2021-10-13 12:51 | 显示全部楼层
我相信你看看 flatbuffers 的 api 就知道这玩意儿是有多难用了。
发表于 2021-10-13 12:57 | 显示全部楼层
不推荐。
flatbuffers更新数组和字符串类型字段相当麻烦,有可能会重新分配空间和复制整条消息的数据。
实际场景里面,即读也写的情况是非常普遍的,调整数组长度也相当常见,然而这些都是fb的软肋。
相比之下,pb在多个因素间取得了较好的平衡,是个比较好的方案。
目前我做实时性要求较高的应用,针对股票市场行情做高频分析,用的格式是pb,瓶颈并不在这里。互联网应用不要求特别高实时性的话,更不用过于担心了。
发表于 2021-10-13 13:00 | 显示全部楼层
实际项目中有大规模使用,缺点大家有说更新的问题,这个也就是fb为什么要包装一层 delta & mutable 的缘故,我说说优点吧,我们在 Java 项目读多写少的情况, 利用  FlatBuffers & FlexBuffer  再加上 DirectByteBuffer pool 取得了非常惊人的效果, codec速度非常棒,GC问题也大规模降低 ... 技术在于场景而已
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-11-24 19:00 , Processed in 0.090820 second(s), 25 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表