Flatbuffers vs CBOR答案

【问题标题】：Flatbuffers vs CBORFlatbuffers vs CBOR
【发布时间】：2017-12-13 17:53:32
【问题描述】：

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

平面缓冲区：

优势：

FlatBuffer、Cap'n proto 和其他类似解决方案中的严格输入被视为性能的主要关键点，因为不需要额外的编码/解码。
数据模型允许使用紧凑的数据结构和快速访问对类型对象进行简单偏移
FlatBuffers 不需要解析/解包步骤，即可访问通常与每个对象内存分配相结合的数据。

缺点：

新的，不像 CBOR 那样标准化。

CBOR

优势：

可以完全在流中创建和处理，无需额外内存
不必预先定义任何架构，因为我们的数据是动态的和多变的
它是 IETF 的一项开放国际标准，使其成为比专有标准更好的选择。
它专为低内存、非转换、基于流的处理而设计，同时还为其他数据类型提供扩展

缺点：

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

PS：
感觉在 CBOR 中管理类型与 flatbuffers 相比性能成本很高，但由于 CBOR 是标准化协议，如果这种差异不是很大，我倾向于更喜欢它。请让我知道你们会推荐哪两个以及为什么。

【问题讨论】：

标签： json protocol-buffers flatbuffers capnproto cbor

【解决方案1】：

我想你自己已经说得很清楚了。 FlatBuffer 的优势在于能够在不解析/解包/分配的情况下访问数据，这在某些情况下可以带来巨大的性能优势。但是，如果这对您来说无关紧要，例如协议缓冲区也可以工作。

数据中的强类型与动态类型也很重要。如果我想要提前没有限制的通用数据存储，我只会使用后者。

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

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

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

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

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

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

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

相反，我们选择了无模式 CBOR 并适当地命名每个地图项。 “apples”用于 A、B、C 和 J。“bananas”是一个可以用于 C、H 和 E 但从不用于 F 等的项目。每一方都需要知道它应该期待什么，仅此而已。

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

【讨论】：