1. 项目概述当图数据库遇上“时间旅行”如果你正在处理金融交易、供应链追溯或者物联网设备状态监控你可能会遇到一个头疼的问题如何同时回答“某个实体在某个特定历史时刻的状态是什么”以及“我们是在什么时候知道这个状态的”。传统的关系型数据库或者图数据库往往只记录了数据的当前快照或者通过简单的版本号来追溯变化很难优雅地处理这种双重时间维度。这正是TGMSTemporal Graph Management System要解决的核心痛点。TGMS一个原生于智能体Agent-Native的双时态图管理系统听起来有点拗口但它的目标非常明确为动态变化的、由智能体驱动的复杂系统提供一个能够完整记录和高效查询“事实时间”与“系统时间”的图数据底座。简单来说它让图里的每个节点和每条边都带上了两块“手表”一块记录这件事在现实世界中实际发生的时间比如交易达成的那一刻另一块记录这个信息被系统获知并录入的时间比如交易数据经过验证后写入数据库的那一刻。这种“双时态”能力对于构建可审计、可解释、能回溯的智能系统至关重要。我最初接触这个概念是在设计一个风控系统的知识图谱时。我们需要追踪一个可疑账户关联的所有实体人、设备、IP在不同时间点的关系变化并且要能区分“我们当时根据什么信息做出了拦截决策”和“事后复盘时发现的实际关联时间”。用传统方法要么需要维护多张复杂的版本表查询性能堪忧要么就丢失了关键的时间上下文。TGMS这类系统的出现直接瞄准了这类场景。它不仅仅是一个存储引擎更是一种面向动态智能体环境的数据建模和管理哲学。接下来我会拆解它的核心设计、实现要点并分享在模拟构建类似系统时的一些实操心得。2. 核心设计思路为何是“Agent-Native”与“Bi-Temporal”2.1 双时态Bi-Temporal的深度解析双时态建模是TGMS的基石。我们首先得把两个时间维度掰扯清楚有效时间Valid Time也称为事实时间或业务时间。它指的是某个事实在现实世界中所属的时间段。例如一份劳动合同的有效期是2023年1月1日至2025年12月31日一次股票交易的发生时间是2024年5月10日上午10点30分05秒。这个时间是客观事实的一部分。事务时间Transaction Time也称为系统时间或记录时间。它指的是该事实被数据库系统所记录、存储的时间段。通常它从记录被插入数据库开始到该记录被逻辑删除或更新为止。例如上述劳动合同的信息可能在2022年12月20日录入系统并在2026年1月5日因合同归档而标记为历史。这个时间反映了系统的认知状态。传统数据库通常只隐式支持事务时间通过日志或系统时间戳而有效时间需要应用层自己管理。TGMS将两者都提升为一等公民为图结构中的每个元素顶点和边都附加了这两个时间区间。这使得我们可以进行四类核心查询当前快照查询查询在“当前”系统认知下“当前”有效的事实即事务时间包含现在且有效时间包含现在。历史追溯查询查询在“过去某个时刻”系统所认知的“当时”有效的事实是什么样即“回溯查询”。“当时未知”查询查询某个事实在现实世界中何时生效而不管系统是何时知道的。“认知演变”查询查询系统对某个事实的认知是如何随时间变化的例如一个用户的地址信息被多次更正的过程。注意有效时间可以是过去、现在或未来如预定的会议而事务时间总是向过去追溯的因为它记录的是系统操作的历史。2.2 智能体原生Agent-Native的设计哲学“Agent-Native”是TGMS另一个关键标签。这里的“智能体”可以是一个软件代理、一个微服务、一个用户甚至是外部系统的一个接口。智能体原生意味着系统的整个架构和API设计都是围绕智能体作为数据变更的发起者和所有者这一核心概念来构建的。这与传统的以“用户”或“会话”为中心的系统有显著区别变更归属明确每一次对图数据的增删改操作都必须与一个明确的智能体ID绑定。这个ID会作为元数据与时间戳一起被持久化。这使得数据血缘和审计追踪变得极其清晰——我们知道是“谁”哪个智能体在“什么时候”改变了“什么”。意图驱动的事务操作不仅仅是“设置属性A为值B”而是“智能体X基于事件Y意图将实体Z的状态更新为...”。系统可以记录更丰富的上下文支持更复杂的冲突解决和一致性模型。支持去中心化与协同在物联网或边缘计算场景中多个智能体可能离线操作本地数据副本并在联网时同步。Agent-Native设计天然支持这种多主体、异步的环境通过智能体ID来协调冲突和合并变更。与图结构的深度融合智能体本身也可以被建模为图中的节点。这样数据变更操作就可以被表示为从“智能体节点”到“目标数据节点”的带有时间和意图属性的“动作边”。整个系统的活动历史本身就构成了一张动态演变的图。这种设计使得TGMS非常适合构建需要高可审计性、多参与方协同、以及复杂事件溯源的系统例如分布式供应链管理、多智能体仿真环境、或者合规要求严格的金融交易平台。2.3 数据模型时态属性图TGMS底层的数据模型通常是时态属性图的扩展。一个标准的属性图包含顶点和边它们都有标签和属性键值对。TGMS在此基础上为每个顶点和边引入了有效时间区间通常用[vt_start, vt_end)表示左闭右开区间。事务时间区间通常用[tt_start, tt_end)表示tt_end为无穷大INF代表当前有效版本。智能体标识符记录创建和结束当前版本的操作者。每一次更新操作如修改一个顶点的属性在TGMS中通常不会直接覆盖原数据而是将原有记录的tt_end标记为当前事务时间即关闭旧版本。插入一条新的记录其tt_start为当前事务时间tt_end为INF并携带新的属性值和/或有效时间。这种“追加写”的模式是时态数据库的典型特征它保证了数据的完整历史不可篡改但也对存储和查询优化提出了挑战。3. 系统架构与核心组件实现拆解构建一个TGMS原型或理解其内部构造可以从以下几个核心组件入手。3.1 存储引擎层如何组织时态图数据存储设计直接决定了系统的性能和扩展性。一种常见的思路是在现有图数据库或关系数据库之上构建时态层但原生系统往往会进行更深度的定制。方案一基于关系型数据库如PostgreSQL这是快速验证概念的可靠方式。可以为顶点和边分别设计表结构CREATE TABLE temporal_vertices ( vertex_id BIGINT, label VARCHAR, properties JSONB, vt_start TIMESTAMP, vt_end TIMESTAMP, tt_start TIMESTAMP, tt_end TIMESTAMP DEFAULT INFINITY, agent_id VARCHAR, PRIMARY KEY (vertex_id, tt_start) -- 组合主键 ); CREATE INDEX idx_v_query ON temporal_vertices (vertex_id, vt_start, vt_end, tt_start, tt_end);优势利用关系数据库成熟的ACID事务、索引和查询优化器。时态查询可以转化为复杂的SQL范围查询。劣势图遍历查询如多跳查询表达起来非常繁琐且性能低下需要多次自连接即使使用递归CTE也难优化。存储空间膨胀较快。方案二基于原生图数据库扩展在Neo4j、JanusGraph等系统上通过自定义存储格式和索引来实现。例如将每个时态版本作为一个独立的节点或边存储并通过特殊的“版本链”边连接。或者将时态信息作为属性存储并依赖高效的属性索引。优势原生支持高效的图遍历操作。可以利用图数据库的本地存储格式优化遍历性能。劣势需要深度修改数据库内核实现复杂度高。时态范围查询的索引设计挑战大。方案三自定义时序图混合存储这是更激进的方案。将“当前图”tt_endINF存放在一个高性能的内存图结构中以支持低延迟的实时查询。而将所有历史版本按时间序列存储在一个优化的列式存储或时序数据库中如Apache Cassandra with TimeWindowCompactionStrategy或ClickHouse。优势读写分离当前图操作快历史查询针对时序优化。存储可以根据访问模式进行分级热数据在内存/SSD冷数据在HDD。劣势系统复杂度最高需要维护两份数据之间的一致性跨时间点的查询可能需要合并两个存储的结果。实操心得在项目初期我推荐从方案一开始使用PostgreSQL的BRIN块范围索引或SP-GiST索引来优化时间范围查询。先聚焦于把双时态模型和Agent-Native API的逻辑做对性能问题可以后续通过分区、分片等手段缓解。过早追求定制化存储容易陷入底层细节的泥潭。3.2 查询引擎时态Gremlin或Cypher扩展用户不可能直接写复杂的SQL来查询时态图。TGMS需要提供一套直观的图查询语言扩展。以Gremlin为例我们可以扩展一些步骤step.asOf(tx_time)指定事务时间点查询系统在该时刻的认知状态。.validDuring(vt_start, vt_end)指定有效时间段查询在该时间段内有效的事实。.biTemporalAsOf(tx_time, vt_time)同时指定事务时间点和有效时间点进行“时间旅行”查询。.history()获取某个顶点或边的所有历史版本。例如一个查询“找出在2024年1月1日系统记录中当时有效且由‘Agent_A’创建的所有用户顶点”的Gremlin遍历可能看起来像这样g.V().hasLabel(user) .asOf(2024-01-01T00:00:00Z) // 事务时间点 .validDuring(2024-01-01T00:00:00Z, 2024-01-02T00:00:00Z) // 有效时间在当天 .has(creator_agent_id, Agent_A) .valueMap()查询引擎需要将这些高阶步骤编译成底层存储引擎如上述SQL或自定义查询能够执行的计划。这涉及到时态谓词的下推、索引的选择以及遍历过程中时间上下文的传递。3.3 智能体API与冲突解决机制这是体现“Agent-Native”特性的关键层。API设计应围绕智能体的操作意图。核心API可能包括class TemporalGraphClient: def __init__(self, agent_id): self.agent_id agent_id def insert_vertex(self, label, properties, valid_from, valid_toNone): 插入一个新顶点由当前智能体创建。 # 生成唯一vertex_id设置tt_startnow(), tt_endINF, agent_idself.agent_id pass def update_vertex(self, vertex_id, new_properties, valid_from, valid_toNone, reason): 更新一个顶点。系统会关闭旧版本创建由当前智能体发起的新版本。 # 1. 验证当前智能体是否有权修改该顶点可选基于业务规则 # 2. 原子性操作结束旧版本插入新版本 pass def resolve_conflict(self, vertex_id, conflicting_versions, resolution_strategy): 当检测到多个智能体对同一事实的有效时间有重叠冲突时调用此方法。 # 冲突解决策略可以是LATEST_WINS, EARLIEST_WINS, AGENT_PRIORITY, MANUAL pass冲突解决是一个核心挑战。当两个智能体同时或离线后同步声明了同一实体在相同有效时间段内的不同状态时就会发生冲突。TGMS需要提供检测和解决冲突的机制乐观锁在更新时检查自读取后是否有其他版本插入。基于规则的自动解决例如总是让后提交的事务胜出可能导致先提交的智能体意图被覆盖或者为不同智能体设置优先级。冲突日志与手动解决将冲突记录到一个特殊区域由管理员或更高级别的协调智能体手动处理。这是最安全但自动化程度最低的方式。注意事项冲突解决策略的选择强烈依赖于业务场景。在金融领域可能需要非常保守的手动审核而在物联网传感器数据同步场景可能采用“最新读数覆盖旧读数”的策略。在设计API时应允许灵活配置冲突解决处理器。4. 实操构建一个简易TGMS概念验证我们来动手搭建一个最小化的TGMS概念验证使用Python、PostgreSQL和NetworkX用于内存图演示重点理解数据流动和查询逻辑。4.1 环境准备与数据模型定义首先我们定义Python中的数据类对应时态顶点。from datetime import datetime from typing import Any, Dict, Optional from dataclasses import dataclass import uuid INF datetime.max dataclass class TemporalVertex: 时态顶点 vertex_id: str # 业务ID或唯一ID label: str properties: Dict[str, Any] valid_start: datetime valid_end: datetime # 有效时间结束INF表示持续有效 tx_start: datetime # 事务开始时间 tx_end: datetime # 事务结束时间INF表示当前有效版本 agent_id: str # 创建此版本的智能体ID def is_current(self, at_tx_time: datetime) - bool: 在给定事务时间点此版本是否是当前认知的版本 return self.tx_start at_tx_time self.tx_end def was_valid(self, at_valid_time: datetime) - bool: 在给定的有效时间点此事实是否成立 return self.valid_start at_valid_time self.valid_end4.2 核心操作插入与更新我们实现一个简单的内存存储管理器模拟“追加写”逻辑。class TemporalGraphManager: def __init__(self): self.vertices: Dict[str, List[TemporalVertex]] {} # vertex_id - list of versions self.edges: List [] # 简化省略边的实现 def insert_vertex(self, agent_id: str, vertex_id: str, label: str, properties: Dict, valid_start: datetime, valid_end: datetime INF) - TemporalVertex: 智能体插入一个新顶点 now datetime.utcnow() new_vertex TemporalVertex( vertex_idvertex_id, labellabel, propertiesproperties, valid_startvalid_start, valid_endvalid_end, tx_startnow, tx_endINF, agent_idagent_id ) if vertex_id not in self.vertices: self.vertices[vertex_id] [] self.vertices[vertex_id].append(new_vertex) print(f[{now}] Agent {agent_id} inserted vertex {vertex_id} (valid from {valid_start})) return new_vertex def update_vertex(self, agent_id: str, vertex_id: str, new_properties: Dict, new_valid_start: datetime, new_valid_end: datetime INF) - Optional[TemporalVertex]: 智能体更新顶点属性或有效时间 if vertex_id not in self.vertices: return None now datetime.utcnow() # 1. 找到当前有效的事务版本 (tx_end INF) current_versions [v for v in self.vertices[vertex_id] if v.tx_end INF] if not current_versions: return None # 没有当前版本可能已被删除 # 假设我们处理最新的当前版本对于简单情况 current_version current_versions[-1] # 2. 关闭旧版本将其tx_end设置为现在 current_version.tx_end now # 3. 创建新版本 new_version TemporalVertex( vertex_idvertex_id, labelcurrent_version.label, properties{**current_version.properties, **new_properties}, # 合并属性 valid_startnew_valid_start, valid_endnew_valid_end, tx_startnow, tx_endINF, agent_idagent_id ) self.vertices[vertex_id].append(new_version) print(f[{now}] Agent {agent_id} updated vertex {vertex_id}. Old version closed at {now}.) return new_version4.3 双时态查询实现实现几个核心的查询函数。def query_as_of(self, at_tx_time: datetime) - List[TemporalVertex]: 查询在某个事务时间点系统认为‘当前’的所有顶点版本 result [] for version_list in self.vertices.values(): # 找到在at_tx_time时刻处于‘当前’状态的版本 for v in version_list: if v.tx_start at_tx_time v.tx_end: result.append(v) return result def query_vertex_history(self, vertex_id: str) - List[TemporalVertex]: 查询一个顶点的完整版本历史按事务时间排序 if vertex_id in self.vertices: return sorted(self.vertices[vertex_id], keylambda x: x.tx_start) return [] def bi_temporal_query(self, vertex_id: str, query_tx_time: datetime, query_valid_time: datetime) - Optional[TemporalVertex]: 双时态查询在query_tx_time时刻系统所知的在query_valid_time时刻有效的顶点版本 if vertex_id not in self.vertices: return None for v in self.vertices[vertex_id]: # 版本必须在查询的事务时间点是“当前”的并且其有效时间包含查询的有效时间点 if v.tx_start query_tx_time v.tx_end and v.valid_start query_valid_time v.valid_end: return v return None4.4 运行一个简单场景让我们模拟一个智能家居场景一个温度传感器Agent_Sensor报告读数一个用户Agent_User手动修正了读数。if __name__ __main__: manager TemporalGraphManager() # 模拟时间 import time def ts(hour, min0): return datetime(2024, 5, 20, hour, min) # 1. 传感器在10:00报告客厅温度为25°C有效时间从10:00开始 manager.insert_vertex( agent_idAgent_Sensor_01, vertex_idLivingRoom_Temp, labelSensorReading, properties{value: 25, unit: C}, valid_startts(10) ) time.sleep(0.01) # 模拟时间流逝 # 2. 在10:05系统事务时间前进。用户发现传感器脏了在10:05手动修正温度为26°C他认为从10:00起就该是26°C manager.update_vertex( agent_idAgent_User_Alice, vertex_idLivingRoom_Temp, new_properties{value: 26, note: manually corrected}, new_valid_startts(10) # 用户认为修正从10:00生效 ) # 3. 查询在10:03这个系统时间点我们当时认为客厅温度是多少 print(\n--- 查询1在10:03的系统认知 ---) for v in manager.query_as_of(ts(10, 3)): print(f Vertex {v.vertex_id}: {v.properties} (valid from {v.valid_start}, recorded by {v.agent_id})) # 应显示传感器报告的25°C # 4. 查询在10:07的系统时间点我们当时认为客厅温度是多少 print(\n--- 查询2在10:07的系统认知 ---) for v in manager.query_as_of(ts(10, 7)): print(f Vertex {v.vertex_id}: {v.properties} (valid from {v.valid_start}, recorded by {v.agent_id})) # 应显示用户修正后的26°C # 5. 双时态查询站在现在10:07之后我们想知道在10:00这个有效时间点事实到底是什么 # 但这里有个关键我们系统在10:00时只知道25°C在10:05之后才知道应该是26°C。 # 所以答案取决于你问的是“系统在何时知道什么”。 print(\n--- 查询3双时态查询 (Tx10:03, Valid10:00) ---) v manager.bi_temporal_query(LivingRoom_Temp, query_tx_timets(10,3), query_valid_timets(10)) print(f 在10:03系统时刻认为10:00有效的温度是: {v.properties if v else Unknown}) print(\n--- 查询4双时态查询 (Tx10:07, Valid10:00) ---) v manager.bi_temporal_query(LivingRoom_Temp, query_tx_timets(10,7), query_valid_timets(10)) print(f 在10:07系统时刻认为10:00有效的温度是: {v.properties if v else Unknown}) # 此时系统认为从10:00开始的有效温度是26°C因为用户修正了历史 print(\n--- 顶点完整历史 ---) for hist_v in manager.query_vertex_history(LivingRoom_Temp): print(f Tx[{hist_v.tx_start} - {hist_v.tx_end}], Valid[{hist_v.valid_start} - {hist_v.valid_end}], Agent:{hist_v.agent_id}, Value:{hist_v.properties[value]})这个简单的演示清晰地展示了双时态的核心数据温度值本身、数据在现实中的有效时间、以及系统认知这个数据的时间是三个独立的概念。TGMS将它们清晰地分离并管理起来。5. 性能优化与生产级考量一个玩具系统与生产级TGMS的差距主要在于规模、性能和可靠性。以下是几个关键的优化方向。5.1 索引策略高效的查询依赖于精心设计的索引。主键(vertex_id, tx_start)是版本表的标准主键支持按顶点ID和事务时间快速检索版本链。时态范围索引对(vt_start, vt_end)和(tx_start, tx_end)建立复合索引以加速如“查找在某个时间段内有效的所有顶点”这类查询。PostgreSQL的SP-GiST索引对范围查询特别有效。智能体索引在agent_id上建立索引支持审计查询如“查找Agent_A做的所有修改”。图遍历索引如果需要支持高效的时态图遍历如“找出在时间T时某人的所有朋友”则需要维护针对特定时间点的图结构索引这非常复杂可能需要在查询时动态构建或维护物化视图。5.2 数据生命周期与压缩时态数据库的数据会无限增长。必须制定数据保留和压缩策略。冷热数据分离将tx_end非INF的历史数据即已关闭的旧版本迁移到更廉价的冷存储中。当前版本tx_endINF保留在热存储以保证写入和实时查询性能。时态分区按tx_start或vt_start对表进行范围分区。例如每个月一个分区。这可以极大提升按时间范围查询和删除旧数据的效率。版本压缩对于某些场景可能不需要保留每一个微小的变更。可以定期运行压缩作业将短时间内、由同一智能体做出的、属性变化不大的连续版本合并为一个版本减少存储开销。但这会损失一部分历史精度需谨慎评估。5.3 并发控制与一致性多智能体并发写入是常态。TGMS需要强一致性模型。多版本并发控制MVCC这是最自然的选择。每个事务看到的是一个基于其开始时间的事务时间快照。写入操作创建新版本不会阻塞读操作。PostgreSQL的MVCC可以直接借鉴。分布式事务如果TGMS是分布式的需要引入分布式事务协议如两阶段提交2PC或更现代的协议如Percolator模型来保证跨分片操作的原子性。这通常会牺牲一些性能。最终一致性与冲突解决在允许离线操作的边缘计算场景可能只能追求最终一致性。此时向量时钟或混合逻辑时钟可以用来标记版本之间的偏序关系并在同步时检测冲突。冲突解决模块见3.3节在这里至关重要。5.4 查询优化挑战时态图查询非常复杂。“找出在时间T1到T2之间与实体A有过关联的所有实体并显示这些关联在时间T3时的状态”这样的查询会涉及大量的时间区间连接和图遍历。查询规划器需要扩展查询引擎的优化器使其能够理解时态谓词并能够将asOf()、validDuring()等操作下推到存储层利用时间索引。物化视图为常见的查询模式如“每日凌晨0点的系统全图快照”创建物化视图可以极大提升特定时间点查询的性能。近似查询对于某些分析型查询可能不需要精确到毫秒的历史。可以提供“在时间T附近”的近似查询通过检索时间上最接近的版本并返回来换取查询速度。6. 典型应用场景与避坑指南6.1 金融交易与合规审计在证券交易中一笔订单的生命周期创建、部分成交、完全成交、取消及其价格、数量都有精确的有效时间。同时交易所系统接收、处理、确认这些订单又有各自的事务时间。TGMS可以完整重建任意时刻的市场状态和系统认知状态用于交易回放与复盘精确模拟历史某一天的交易情况用于策略测试。监管合规证明在特定时间点系统是否遵循了所有规则如风控规则。纠纷仲裁当客户对成交价格有异议时可以查询在订单有效时间内系统实际记录的市场深度情况。避坑指南金融场景对性能和一致性要求极高。务必对tx_start使用单调递增且全局有序的时间戳如TrueTime或混合逻辑时钟避免因时钟偏移导致版本顺序错乱。写入路径必须高度优化避免成为瓶颈。6.2 供应链与物流追溯从原材料到成品每个物料的归属、位置、状态都在随时间变化。双时态图可以建模整个供应链网络追踪批次溯源当发现某个成品有质量问题时可以快速找到其所有组件在任意历史时刻的来源。责任界定货物在哪个仓库、由哪个承运商负责期间发生了损坏通过对比有效时间损坏发生时间和事务时间损坏被记录的时间可以更清晰界定责任。预测与规划基于历史的状态变化图预测物流瓶颈。避坑指南供应链数据往往由多个异构系统ERP, WMS, TMS提供每个系统都是一个“智能体”。需要设计统一的ID映射和消息格式并处理好来自不同系统的、可能带有延迟或冲突的数据同步。有效时间的对齐是关键确保所有系统都使用协调世界时UTC或一个统一的业务时间基准。6.3 物联网与数字孪生工厂里的设备传感器持续产生带时间戳的数据有效时间。这些数据被采集、处理、存入数字孪生模型事务时间。TGMS可以维护一个与物理世界同步演变的数字孪生图。状态历史查询查询一台机器在昨天下午3点到4点之间的所有振动指标。根因分析当产品缺陷率上升时回溯分析生产线上相关设备在缺陷产品生产时段的历史状态关联。仿真与推演基于历史状态图训练模型预测设备未来可能发生的故障。避坑指南物联网数据量巨大且流速快。直接为每一个传感器读数创建一个新的顶点版本是不现实的。通常需要聚合例如为每个传感器创建一个顶点其属性是一个时间序列字段或者将高频数据存储在专门的时序数据库如InfluxDB中而在TGMS中只维护设备之间的拓扑关系变化和重要的状态事件如开机、停机、报警。TGMS与TSDB需要协同工作。6.4 知识图谱的演进管理企业的知识图谱不是静态的实体会被合并、拆分关系会被修正。TGMS可以记录这些演变。知识溯源为什么系统认为A公司和B公司是竞争对手这个结论是基于哪一年哪份财报数据得出的当时的数据源是什么假设分析如果某个历史事件如并购没有发生现在的知识图谱会是什么样子可以通过“分支”历史版本进行推演。审计与合规满足数据隐私法规如GDPR中“被遗忘权”的要求可以精确地删除某个用户在某段时间内的所有相关信息。避坑指南知识图谱中的更新常常是“声明式”的例如“从今天起A是B的子公司”这同时改变了A和B的状态以及它们之间的关系。在TGMS中这可能需要在一个事务中原子性地更新多个顶点和边并确保它们的事务时间戳完全一致以保持图的一致性快照。这要求事务具有足够的能力来批量操作多个图元素。构建或采用TGMS是一个架构上的重大决策。它引入了显著的数据存储复杂性和查询开销因此只有当你的应用真正需要同时、清晰地回答“当时是什么样”和“我们何时知道”这两个问题时它才是合适的。对于大多数只需要简单历史版本功能的场景传统的版本化设计或事件溯源模式可能更简单有效。然而在那些对数据的时间本质有深刻要求的领域——金融、供应链、物联网、法规遵从——TGMS所提供的清晰性和强大能力是其他方案难以比拟的。它不仅仅是一个数据库更是对业务时间本质的一种深刻建模。