proto缓冲区的局限性 - 加载部分数据和共享字符串

我想检查proto buffer是否是我使用的最好的序列化程序，我的研究发现没有其他的东西接近。我正在研究java后端和android（java）移动应用程序，但是有可能在不太遥远的未来创建其他客户端，所以我想要跨平台的东西。数据结构的草图：proto缓冲区的局限性 - 加载部分数据和共享字符串

message All { 
    repeated Line lines = 1; 
    Common common = 2; 
}

有一对夫妇数百行的对象，每一行是相当复杂的，需要自行〜100 KB。

两个问题我看到原缓冲 - 在应用程序启动时，我需要对现有数据的只是一部分 - 只是“普通”和“行”的基本信息。是否可以加载部分数据？ - 每个Line对象都包含数百个字符串，但在几个Line对象中会出现相同的字符串，所以我想尽力在这些对象之间共享它们。它可能在原型buf级别上，还是需要成为应用程序级别的一部分？

谢谢！

来源

2017-02-18 MichalMa

您是否考虑过使用多个分隔邮件？ –

“是否可以加载部分数据”否。您需要将它们存储在单独的消息中。 –

我会认定：您可以跳过部分有线格式的协议缓冲区，因为消息的大小是已知的。但是这听起来像是你必须阅读'Line'消息才能确定要阅读的相关内容。也许你可以有另一个领域，比如'重复Line basic_lines';但你仍然需要编写一个自定义解析器来提取你感兴趣的东西。 –

从您提供的有限规格中，很难给出适当的反馈。你说，对于你的问题，最好的解决方案似乎是protobuf，但我们不能从所给的信息中重新评估。根据你写的内容，我甚至会说，一个简单的GZIPped字节数组（或大多数JSON是可打印的（你说他们是String s））可能对你更好（“重用”了很多东西跨线对象=> GZIP将摇滚）。

正如其他人所说：使用protobuf是不可能加载“部分数据结构”（实际上你不会是一个部分数据结构，只要“重复”部分是例如Collection，因为protobuf将采取关心在结构中分段数据）。

我会把我的两美分放在GZIPped JSON流（例如，与杰克逊），当然在这种情况下，你会减少带宽与CPU周期的成本。

来源

2017-02-28 07:53:31

你是对的，我应该扩展我的为了证明我的要求，我应该尽快这样做。然而，我有几点不同意你的观点：字节数组是我目前的方法，我可以告诉你，这实际上不会扩展，并且非常容易出错。我计划gzip protobuf的结果，所以json会变得更大。加上在旧手机上反序列化json会增加显着的延迟（CPU周期），再加载同一个字符串的多个副本会增加内存压力。我的结构也有多维数组，这会占用json比protobuf多得多的空间。 – MichalMa

与杰克逊也有可能使用对象引用⇒相同的字符串将不会在编组字符串中两次;）但是，我同意，它确实取决于你的确切用例。 –

回答我自己关于加载部分数据的问题。我还没有在实践中尝试过，但我不知道下面是行不通的：

message All { 
    repeated Line lines = 1; 
    Common common = 2; 
} 

message All_partial { 
    Common common = 2; 
}

正如proto3所有领域都是可选的，我们可以有我们的结构的第二个定义，“部分”领域。如果我们保持相同的字段编号，我希望我们会没事的。

来源

2017-03-02 17:04:52 MichalMa

proto缓冲区的局限性 - 加载部分数据和共享字符串

回答

相关问题