Protobuf，嵌套映射? [英] Protobuf, nested maps?

问题描述

我正在使用 Protobuf 3.从文档来看，似乎无法定义嵌套映射:

I'm using Protobuf 3. From the docs, it seems like it's not possible to define nested maps:

message MyMessage {
  map<string, map<string, string>> nestedMap = 1; // doesn't work
}

我正在尝试创建消息类型来表示期权链的定价信息(买入价和卖出价).对于那些不熟悉这些金融工具的人，基本上，我有一套到期日(YYYYMMDD)".在这些到期日期中的每一个中，我都有一组罢工(浮点数；如有必要，可以表示为字符串，我可以接受)".在每次行使中，我有 2 个选项，一个看跌"和一个看涨"(这称为期权的权利").这些选项中的每一个都将包含一个出价"和一个要价".

I'm trying to create a message type to represent pricing information (bid and ask prices) for an Option Chain. For those unfamiliar with these financial instruments, basically, I have a set of "expiration dates (YYYYMMDD)". In each of these expiration dates I have a set of "strikes (float numbers; could be represented as strings if necessary, I'm ok with that)". In each strike I have 2 options, one "put" and one "call" (this is called the "right" of the option). Each one of these options will contain a "bid" and an "ask" price.

从概念上讲，我想要类似的东西

Conceptually, I would like to have something like

message OptionChain {
  // doesn't work:
  map<Expiration, map<Strike, map<Right, BidAskData>>> whatever = 1;
}

我找到的替代方案是:

message OptChain {
  map<string, OptChainExpirations> expirations = 1;
}
message OptChainExpirations {
  map<string, OptChainExpirationsStrikes> strikes = 1;
}
message OptChainExpirationsStrikes {
  OptBidAsk put = 1;
  OptBidAsk call = 2;
}
message OptBidAsk {
  double bid = 1;
  double ask = 2;
  // any other fields that might be necessary in the future
}

这似乎有效.但这似乎也给我的系统增加了不必要的复杂性，因为它定义了大量中间"消息.

This seems to work. But this also seems to add unnecessary complexity to my system, by defining a ton of "intermediate" messages.

有其他选择吗?

谢谢！

一些额外的上下文:

• 一个期权链通常包含不超过大约 6-10 个不同的到期日，每个到期日通常不会包含超过大约几十个行使价.换句话说，我们讨论的是每个选项链最多占用几千字节的数据.

• an option chain will typically contain no more than about 6-10 different expirations, each expiration will typically not contain more than about a few dozen strikes. In other words, we're talking of about take a few kilobytes of data at most, for each option chain.

我将使用它作为一个 gRPC 调用的返回值.随意为此建议替代设计！

I'll be using this as the return value of one gRPC call. Feel free to suggest alternative designs for this!

推荐答案

对我来说，你的中间消息类型的替代方案似乎很好.稍微简化命名可能是值得的，例如Strike 而不是 OptChainExpirationsStrikes.如果您担心名称冲突，请将其全部放在自己的命名空间/包中.

To me, your alternative with intermediate message types seems fine. It might be worth to simplify the naming a bit, e.g. Strike instead of OptChainExpirationsStrikes. If you fear name collisions, put it all in its own namespace/package.

还要考虑您是要根据字符串键查找罢工，还是作为普通的重复字段会更好.

Also consider whether you will be looking up strikes based on the string key, or if it would be better as a normal repeated field.

这篇关于Protobuf，嵌套映射?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！