FIWARE数据持久化组件选型咨询：STH-Comet、QuantumLeap等的选择及长期存储方案

一、如何选择合适的FIWARE GE持久化上下文信息 #

核心看数据类型、存储周期和业务需求，分场景对应：

• 上下文快照类数据（需保存实体状态的历史版本，比如设备属性的全量变更记录）：选Cygnus。它支持对接MongoDB、MySQL等多种后端，能批量/实时导入上下文数据，适合长期存储结构化的上下文快照，方便后续检索实体的完整状态变迁。
• 短期时序数据（高频更新、仅需查询最近几小时/几天的趋势）：用STH-Comet。它专门针对近期时序数据优化，查询延迟低，后端可选MongoDB或CrateDB，适配实时监控类场景。
• 长期时序数据+分析需求：优先考虑QuantumLeap，其优势会在下文详细说明。

额外需考量扩展性：如果后续要做大数据分析，优先选支持时序数据库的组件；若仅需简单历史查询，Cygnus或STH-Comet已足够。

二、QuantumLeap是否适合长期时序数据存储？ #

完全合适，甚至是这类场景的最优选择之一，和STH-Comet的定位差异明确：

• STH-Comet的设计目标是短期缓存式存储，针对最近的时序数据做了优化，查询速度快，但面对数月甚至数年的大规模时序数据时，存储效率和复杂查询能力会明显下降。
• QuantumLeap专门对接TimescaleDB、PostgreSQL等专业时序数据库，天生支持数据按时间分区、时间范围查询优化、聚合函数（比如按小时/天统计均值），能高效管理超大规模的长期时序数据。同时它还支持与数据分析工具集成，适配从历史数据中挖掘趋势、制作报表分析的场景。

另外，QuantumLeap和STH-Comet一样遵循NGSI接口，能直接从Orion Context Broker接收数据，切换或共存都无需复杂改造。

内容的提问来源于stack exchange，提问作者pirip10