最好在Protobuf消息或嵌套消息中拥有许多字段

我试图在网络上找到一些建议，但找不到任何相关的建议。

假设我正在创建一个协议缓冲消息，该消息将包含许多字段(50 (。是否最好将所有领域保持相同的水平或以子消息的形式组织它们？对一种或另一种方式的表演有任何影响吗？

示例：

message myMessage{
 string field1 = 1;
 string field2 = 2;
 ....
 string fieldn = n;
}

message myMessage{
 SubMessage1 groupedfieldsbasedonsomebusinesslogic1 = 1;
 SubMessage2 groupedfieldsbasedonsomebusinesslogic2 = 2;
 message SubMessage1{
  string field1 = 1;
  string field2 = 2;
  ... 
  string fieldx = x;
 } 
 message SubMessage2{
  string fieldxplus1 = x+1;
  ... 
  string fieldn = n;
 }
}

我在这里不考虑可读性，因为在避免使用平坦的数据或嵌套数据时有利弊。我的问题确实专注于技术影响。

没有"最佳" - 一切都是上下文，只有您拥有大多数上下文。

但是！对性能的一些小想法：

嵌套方法需要更多对象；通常这很好，除非您的卷很大
一种嵌套的方法可能使了解对象模型以及数据的某些部分之间的关系变得更加容易
扁平的方法需要更大的场数；场数1-15取一个字节标题；字段编号16-2047需要2个字节标头(等(；实际上，这个针对几个领域的额外字节不太可能伤害您，并且被替代方法(嵌套(方法的开销所抵消：
嵌套方法需要每个子观测值的长度前缀，或者需要一个启动/结束令牌(协议中的"组"(;这并不是额外的大小，而是：
- 长度预订需要序列化器才能提前知道长度，这意味着双处理(" compute length"扫描(或缓冲；在大多数情况下，这不是一个大问题，但是对于非常大的子图案来说可能是有问题的
- 开始/结束令牌是Google一直试图杀死的东西，并且在所有库中都不得到很好的支持(并且IIRC在" Proto3"架构中不存在(；不过，我仍然真的很喜欢它，在某些情况下：( Protobuf-net(来自标签(支持编码任意sub-data作为组的能力，但是如果您以后需要X-Plat，它可能会很尴尬

在所有这些事情中，如果是我，我将重点关注的是第二个。。

也许是从看起来可用的东西开始，然后对其进行衡量的数据量；它可以接受吗？

相关内容

最新更新

热门标签：