Flatbuffers诉CBOR

Question

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

平缓冲：

优势：

1. 在FlatBuffer、Cap和其他类似的解决方案中严格输入被认为是性能的主要关键，因为不需要额外的编码/解码。
2. 该数据模型允许以紧凑的数据结构和快速访问的方式对类型化对象进行简单偏移。
3. 在访问数据(通常与每个对象的内存分配相耦合)之前，FlatBuffers不需要对辅助表示进行解析/解压缩。

劣势：

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

CBOR

优势：

1. 可以在没有额外内存的情况下在流中创建和处理
2. 不需要预先定义任何模式，因为我们的数据是动态的和可变的。
3. 这是IETF的一个开放的国际标准，使得它比专有标准更好选择。
4. 它专为低内存、非转换、基于流的处理而设计，同时也为其他数据类型提供扩展。

劣势：

1. CBOR说它遵循JSON模型(所以不是严格类型的对象)
2. 它从相同类型的对象(字符串、整数、映射等)开始。

PS：

与平面缓冲区相比，CBOR中的管理类型在性能上将是昂贵的，但由于CBOR是标准化的协议，如果这种差异不是很大，我倾向于选择它。请告诉我你们推荐的两种中的哪一种和为什么。

Answer 1

我想你自己已经说得很清楚了。FlatBuffer的优势在于能够在不解析/解压缩/分配的情况下访问数据，这在某些情况下会给性能带来很大的好处。但是，如果这对您不重要，例如协议缓冲区可能也同样有效。

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

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

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

Answer 2

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

这个CBOR系统几乎没有什么问题，设置起来比FlatBuffers和其他二进制解决方案要容易得多。

Answer 3

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

您有一个CON，类似于JSON的CBOR没有严格的类型，您需要进行一些验证，以确保得到的类型是您所期望的类型。你说得对，这就是模式序列化器带给你的东西。你失去了改变类型的灵活性，但你知道你会得到什么。我的工作是嵌入到C中，而静态类型很重要。

您没有列出的是CBOR‘可以“保持JSON的兼容性。任何有效的JSON都是有效的CBOR，而不是相反。cbor可以有一个1: 2的映射项(object，key/value对)，它的整数1名的值为整数2。这不是一个很好的实践，但可能有一些用途。如果您避免了有意不兼容的事情，CBOR >> JSON转换会非常方便。你什么时候会用这个？我用它做原木。当我的CBOR数据包到达我们的服务器时，它们被转换成JSON，并存储在已经人类可读的分析中。您可以使用任何序列化程序来实现这一点，但是我们认为在紧密转换中出现“解释”差异的可能性要小得多。

对我们来说，最主要的因素是模式太难共享和同步。如果您拥有A到B系统的两个方面，那么模式是很好的！您可以获得大小效率，因为map "Apples“：100只是存储为1,100，但是在完成任何工作之前，您必须在两边获取模式文件并编译(如果使用代码生成)。好吧，但是如果你有一个星型A、B、C、D、E、F、G、H、I、J的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数据的代码。对我来说，这是没有模式的最大痛苦点，我只能自己做这个工作并犯错误。