Lorawan-stack: デバイスマッチングを最適化する

より良いアプローチは、別の方法でこれに取り組むことだと思います。これにより、一般的なケースでもパフォーマンスが向上します。つまり、スペースを消費するデータをプロトから分割し、それらを別々に保存します。つまり、 recent_uplinks 、 recent_downlinksなど、マーシャリングされたプロトではなくリストにこれらを保存する方が理にかなっています。つまり、既存のメッセージを実際にクエリする必要はなく、新しいメッセージを追加するだけで済みます。これははるかに効率的ですが、プロトだけから始めて、そこから始めましょう。
フィールドマスクがあることを考えると、プロトの分割は非常に簡単で、Redisレジストリの実装によって完全に処理されます。

したがって、提案は次のようになります。

• ns:devices:uid:foo:bar:recent_uplinks
• ns:devices:uid:foo:bar:recent_downlinks
• ns:devices:uid:foo:bar:mac_state:recent_uplinks
• ns:devices:uid:foo:bar:mac_state:recent_downlinks
• ns:devices:uid:foo:bar:pending_mac_state:recent_uplinks
• ns:devices:uid:foo:bar:pending_mac_state:recent_downlinks
  ..。
• ns:devices:uid:foo:bar -残りのプロト

非推奨のフィールドがすでにレジストリで処理されているのと同様に、移行は自動的に行われます。

ここのステータスは何ですか？

これは来週の終わりまでにマージの準備ができていると思います。
実装は数週間行われ、それ以来、リファクタリングとテストの適応に取り組んでいます。

デバイスが一致しない場合は、返されたエラーをより明確にすることを検討してください。 たとえば、 https：//github.com/TheThingsNetwork/lorawan-stack/issues/2394を参照して

たくさんの情報を提供することはできませんが、 device_not_foundはデバイスが見つからないことを意味しますが、DevAddrがまったく見つからない、MICが見つかったエントリと一致しない、および/または、FCntがリセットされたが、見つかったエントリでは許可されていない。

良い提案ですが、比較的複雑な機能がたくさんあるレビューするのは巨大なPRになるので、次のステップとしてそれを行うのが最善だと思います