Lorawan-stack: 기기 매칭 최적화

더 나은 접근 방식은 일반적으로 성능을 향상시키는 다른 방식으로 이 문제를 해결하는 것이라고 생각합니다. 공간을 많이 차지하는 데이터를 프로토스에서 분리하고 별도로 저장합니다(예: recent_uplinks , recent_downlinks 등, 마샬링된 프로토스 대신 목록에 저장하는 것이 더 합리적입니다. 즉, 실제로 기존 메시지를 쿼리할 필요가 없지만 새 메시지를 추가하면 훨씬 효율적이지만 프로토타입으로 시작해서 거기에서 가봅시다.
필드 마스크가 있다는 점을 감안할 때 proto 분할은 매우 간단하고 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이 될 것이기 때문에 다음 단계로 하는 것이 가장 좋다고 생각합니다.