Flatbuffers与CBOR

Question

请帮助建议Flatbuffers和CBOR协议的优缺点。这两种二进制格式都声称在它们的网站上是不错的，但是我无法在两者之间做出一些很好的区别。

平面缓冲区：

优点：

1. 严格输入FlatBuffer，Cap'n proto和其他类似解决方案被视为提高性能的关键点，因为不需要额外的编码/解码。
2. 数据模型允许使用紧凑的数据结构和快速访问轻松地对类型化的对象进行偏移
3. FlatBuffers不需要解析/拆包步骤即可生成辅助表示形式，然后您才能访问经常与按对象存储分配相关的数据。

坏处：

1. 像CBOR一样新的和不标准化的

CBOR

优点：

1. 可以完全在流中创建和处理而无需额外的内存
2. 不必预先定义任何模式，因为我们的数据是动态的且可变的
3. 这是IETF的一项开放国际标准，因此比专有标准更好。
4. 它设计用于低内存，非转换，基于流的处理，同时还提供其他数据类型的扩展

坏处：

1. CBOR表示它遵循JSON模型（因此不是严格类型的对象）
2. 它以相同类型的对象（字符串，整数，映射等）开头。

PS：
与平缓缓冲区相比，感觉CBOR中的类型管理将在性能上付出高昂的代价，但是由于CBOR是标准化协议，因此如果这种差异不大，我倾向于使用它。请让我知道你们都推荐两个，为什么。

Answer 1

我为我的网站选择了 CBOR https://kwippe.com选择了 CBOR - 我们使用它来将所有艺术品和关键字数据存储为一个非常小的 JSON 结构中的压缩字符串，仅需要对文件进行分类所需的几个属性。所以文件非常小，并且加载速度非常快。我将其用于超过 30,000 个 SVG 文件，并预先将其转换为 JSON。所有 JSON 都转换为字符串并通过字符串压缩库进行压缩，然后保存为我编码为 CBOR 的较小 JSON 对象的一部分。

我在使用这个 CBOR 系统时遇到的问题很少，而且它比 FlatBuffers 和我研究过的其他一些二进制解决方案更容易设置。

Answer 2

我也有同样的问题，出于几个原因选择了 CBOR。

你有一个缺点，像 JSON 这样的 CBOR 没有严格的类型，确实如此，你需要做一些验证来确保你得到的类型是你期望的类型。你是对的，这就是 Schema 序列化器为你提供的。你失去了改变类型的灵活性，但你知道你会得到什么。我从事 C 嵌入式工作，静态类型很重要。

您没有列为 PRO 的是 CBOR“可以”保留 JSON 兼容性。任何有效的 JSON 都是有效的 CBOR，但反之则不然。cbor 可以有一个 1 : 2 的映射项（对象、键/值对），即整数 1 名称具有整数 2 的值。这不是一个很好的做法，但可能有一些用途。如果你避免故意不兼容的事情，CBOR >> JSON 转换会非常方便。你什么时候会用它？嗯，我用它来记录日志。当我的 CBOR 数据包到达我们的服务器时，它们会转换为 JSON 并存储在人类可读的地方以供分析。您可以使用任何序列化器来执行此操作，但我们认为在紧密转换中出现“解释”差异的机会要少得多。

对我们来说，主要因素是架构太难共享和同步。如果您拥有 A 到 B 系统的两侧，那么架构就很棒！您可以获得大小效率，因为地图“Apples”：100 只是存储为 [1,100]，但您必须在两侧获取架构文件并进行编译（如果使用代码生成），然后才能完成任何工作。好的，但是如果星形图案 ABCDEFGHIJ 有 10 个边，其中 A 和 J 可以互相发送消息，B 和 H 几乎完全聊天，除了发送给 E 并且从不返回的消息，等等...在这种情况下，模式可能会非常困难！也许它正在工作，并且您添加了大量消息，选项是使用旧模式、可选或缺少的定义，或者您同步每个人。对我们来说就是这种情况，并且它会在 4 种以上的语言和我们不拥有的系统中发生。

相反，我们选择无模式 CBOR 并适当命名每个映射项。“苹果”代表 A、B、C 和 J。“香蕉”代表会进入 C、H 和 E，但不会进入 F 等。每一方都需要知道自己应该期待什么，仅此而已。

据我了解，FlatBuffers 确实有无模式模式，但我对此知之甚少。我认为没有正确的答案，但就其价值而言，我们的 Web 开发人员立即接受并理解了 CBOR，因为它在外观和感觉上与 JSON 非常相似。

更新：如果对 CBOR 感兴趣，但确实可以使用一些模式支持和/或清晰的方法来记录预期数据是什么。CDDL (RFC 8610) 看起来正是这样做的。还支持 JSON 的数据定义，因为 CBOR 和 JSON 非常相似。还有适用于各种语言的 CDDL 代码生成工具，它们将接受 CDDL 文件，并帮助生成用于反序列化、解析、验证 CBOR/JSON 数据的代码。对我来说，这是没有架构的最大痛点，我只能自己做这项工作并犯错误。

Answer 3

我认为您已经很清楚地自己阐明了。FlatBuffer的优势在于无需解析/拆包/分配即可访问数据，这在某些情况下会带来严重的性能优势。但是，如果这对您而言无关紧要，例如协议缓冲区也可以正常工作。

数据中的强类型和动态类型也很重要。如果我想事先没有约束的通用数据存储，则只使用后者。

顺便说一句，如果出于某种原因您更喜欢动态类型，但又希望就地访问具有性能优势，那么实际上存在一种将两者结合的格式：https : //google.github.io/flatbuffers/flexbuffers。 html

FlatBuffers不是“专有的”。它可能是由Google设计的，但是它是开源的，并被许多其他公司所依赖。