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

七彩极 · 发表于 2021-10-13 12:42

Doris232 · 发表于 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 。

HuldaGnodim · 发表于 2021-10-13 12:51

我相信你看看 flatbuffers 的 api 就知道这玩意儿是有多难用了。

Ylisar · 发表于 2021-10-13 12:57

不推荐。
flatbuffers更新数组和字符串类型字段相当麻烦，有可能会重新分配空间和复制整条消息的数据。
实际场景里面，即读也写的情况是非常普遍的，调整数组长度也相当常见，然而这些都是fb的软肋。
相比之下，pb在多个因素间取得了较好的平衡，是个比较好的方案。
目前我做实时性要求较高的应用，针对股票市场行情做高频分析，用的格式是pb，瓶颈并不在这里。互联网应用不要求特别高实时性的话，更不用过于担心了。

NoiseFloor · 发表于 2021-10-13 13:00

实际项目中有大规模使用，缺点大家有说更新的问题，这个也就是fb为什么要包装一层 delta & mutable 的缘故，我说说优点吧，我们在 Java 项目读多写少的情况，利用 FlatBuffers & FlexBuffer 再加上 DirectByteBuffer pool 取得了非常惊人的效果， codec速度非常棒，GC问题也大规模降低 ... 技术在于场景而已

		自动登录	找回密码
密码			立即注册