FlatBuffers 与 Protobuf

Question

我的问题是，如果 FlatBuffers 比 Protobuf 快得多，为什么它没有比 Protobuf 更广泛地使用？

它曾经是一个实验性的东西，但现在似乎已经足够成熟，但尚未广泛使用。似乎人们主要将 Flatbuffers 用于移动应用程序/游戏。为什么会这样？

Answer 1

有几个原因：

1. 正如您所提到的，平面缓冲区主要用于应用程序和游戏中。这是因为这是他们最好的应用。由于平面缓冲区速度更快，因此它们的主要应用是在低延迟应用程序中使用它们。它在该领域越来越受欢迎。

2. 当现有技术运行良好时，人们/组织通常不想为新技术投入时间和资源。我个人曾为一家大型组织做过涉及平面缓冲区的概念验证。在做出使用该技术的最终决定之前存在许多障碍。遗留系统仍在使用 xml 和 json，更不用说考虑 protobufs 了。

Answer 2

我认为有多个因素：

1. 如果旧技术有效，人们通常不会费心去切换（除非它成为瓶颈并且必须进行优化）。
2. Flatbuffers 确实非常积极地优化速度，但代价是数据大小膨胀。Protobuf 的优化在速度和大小之间更加平衡。如果使用 protobuf 序列化，同一条消息的大小通常会比使用 Flatbuffers 小得多。如果您的消息是通过网络发送的，则需要考虑到这一点。（不要谈论压缩——压缩可能会比从 protobuf 切换到 Flatbuffers 节省的 CPU 周期多 100 倍。）
3. Flatbuffers 的 API 很难使用。构建和序列化 Flatbuffers 表根本不容易，特别是当它具有数组成员和/或嵌套表时。相比之下，我实际上只花了一两分钟就学会了如何设置 protobuf 消息的字段并将其序列化为字节数组。

Answer 3

我只在工作中使用过 Protobuf。我认为这个问题的答案对于所有新技术的采用曲线都是相同的。“如果我们正在使用的东西运行良好，为什么我们应该转换并必须投资于培训并接受新的固有错误风险”。我还发现，只有极少数的开发人员花费大量时间来学习最新、最好的工具。大多数人找到了一些可行的东西，然后继续使用它，直到他们被迫因漏洞或性能要求而做出改变。