测试说明本文涵盖约 200 万笔交易数据的功能与故障恢复测试、面向 2,000 万笔交易的容量评估以及大批次并发写入基准。各测试场景采用相应的数据规模、资源条件和统计口径。性能指标用于刻画数据库的处理能力与目标运行水平不构成所有生产环境下的性能或服务等级承诺。一、产品概述与测试结论OntoGraph 是面向本体、知识图谱与智能业务应用的原生本体数据库。它不仅支持实体、关系与属性的存储和查询还将聚合计算、属性派生、行动触发等业务计算能力纳入统一的数据模型使业务对象能够被查询、计算、关联和持续更新。围绕这一定位OntoGraph 提供以下核心能力本体原生数据组织统一管理业务实体、关系、属性及其关联支撑从业务对象到图关系的统一查询。高吞吐数据处理支持大批次数据写入、多客户端并发及持续业务数据更新。图查询与关联分析支持点查、过滤、一跳关联、窗口聚合及大结果集查询。动态计算与行动支持聚合指标、派生属性、条件判断与行动触发让计算结果能够继续驱动业务状态变化。智能检索与应用连接支持向量与 BM25 混合检索并为 OntoFlow 的智能问数、智能体、业务自动化和数字孪生提供数据基础。本轮验证重点覆盖批量数据写入、图查询、业务计算、数据一致性及故障恢复。向量检索等专项能力不纳入本轮性能结论。核心结果与性能指标如下在约 199.6 万笔交易的详细测试中聚合、派生、行动触发及查询结果均通过一致性校验。常规持续写入的提升版性能指标为12,40017,500 行/秒大批次并发写入基准达到267,015 个事件/秒折合801,045 项图数据/秒。查询性能指标覆盖毫秒级点查、窗口查询、一跳关联及大结果集读取具体指标按查询类型分别统计。服务进程异常终止、对象存储暂停或停止、存储配额写满等已覆盖故障场景均完成了恢复验证基础样本恢复后的数据及计算校验通过。快速恢复能力以整体读恢复30 秒以内为目标并要求在恢复后维持数据、聚合、派生及行动结果的一致性。需要区分的是基础样本上的恢复记录与快速恢复指标属于不同运行条件前者用于说明已有恢复行为后者用于约束改进后的运行目标。二、测试环境与负载设计本报告采用账户、交易和转账关系构成的业务模型包含基础交易记录、账户统计、账户日聚合、派生比率与行动告警。详细功能与故障注入测试使用约 199.6 万笔交易数据2,000 万笔规模用于分析数据增长后的容量需求和整体负载。大批次并发写入基准采用独立的 8 核、16 GB 内存环境及 7 个并发客户端单次请求处理 200,000 个交易事件。详细样本的写入采用 4 个并发线程、每批 1,000 行查询采用 8 个并发线程覆盖账户统计、交易和关系点查、单日窗口聚合、一跳关联查询以及大结果集读取。存储后端对照分别采用 HDFS 和 S3 兼容对象存储 MinIO。两套实例独立初始化使用相同代码、相同数据和相同测试组合并保持存储空间隔离。基础故障测试采用低配单机资源环境其中对象存储为单机单副本HDFS 对照仅有一个 DataNode。相关结果适合验证系统功能和恢复流程不代表多节点生产集群的全部容灾能力。三、功能正确性与数据一致性针对详细测试样本每张测试图执行八项一致性校验覆盖三项聚合、一项派生、行动告警数量与触发次数以及三项查询。已测场景全部通过。测试场景验证重点结果正常加载与查询数据完整性、计算结果及查询结果通过服务进程强制终止重启后的 WAL 恢复及数据校验通过对象存储暂停 60 秒、停止 45 秒后端异常期间及恢复后的读写状态通过存储配额写满写入失败处理、恢复及数据一致性通过存储配额写满场景的最终校验结果如下数据或计算项校验结果账户统计实体1,456账户日聚合实体220,318转账关系188,255交易实体1,996,191派生比率1,274 / 1,274 正确行动告警264告警缺失 / 额外告警0 / 0重复触发0这些结果表明在已覆盖的故障条件下数据库能够区分已确认写入与尚未完成的写入。恢复后数据、派生计算和行动结果保持一致没有发现重复告警或额外告警。这里的精确计数对应约 200 万笔的详细测试样本而不是将原有实体、关系和告警数量简单放大十倍。2,000 万规模下的实际实体数、聚合数量和告警数还取决于账户去重、交易时间范围及业务规则。四、性能测试结果4.1 批量写入性能OntoGraph 的批量写入性能分别从常规持续处理与大批次并发处理两个角度衡量。常规持续写入常规持续写入的提升版性能指标如下指标性能指标持续写入吞吐12,40017,500 行/秒千行批次 p50225250 ms千行批次 p95约 490760 ms千行批次 p99约 5901,300 ms对应的详细样本基线记录为约 6,2008,500 行/秒稳定批次 p50 约为 0.450.50 秒。提升版指标将吞吐能力提高到原基线约两倍的水平并相应降低常规批次的中位延迟。在常规运行过程中需要同时关注吞吐、批次延迟及错误重试不能仅以短时间的峰值代替持续处理能力。存储配额写满属于特殊故障场景。详细样本测试中该场景的 p95 为 980 ms、p99 为 1.25 秒最慢批次达到 78.5 秒主要来自写满期间的写入阻塞。该数据用于说明故障期间的最长等待行为不与正常持续写入的批次延迟混为一谈。大批次并发写入在独立的大批次并发基准中采用 8 核、16 GB 内存及 7 个并发客户端单次请求包含 200,000 个交易事件得到以下结果指标基准结果并发客户端7单批次交易事件200,000 个交易事件吞吐267,015 个/秒每个事件包含的图数据2 个实体、1 条关系折合图数据吞吐801,045 项/秒其中交易事件吞吐以一笔完整交易事件为计数单位图数据吞吐按事件包含的两个实体和一条关系折算。这一基准主要反映大批次、多客户端并发条件下的处理能力适用于分析历史数据导入、批量数据迁移和集中式业务数据接入等场景。它与常规持续写入采用不同的请求粒度及统计口径不能直接视为同一工况下的持续吞吐。4.2 图查询性能提升版查询性能指标按照原有详细样本的查询类型分别设定。点查和关联查询重点关注中位延迟与并发 QPS大结果集查询则保留独立的结果规模和完整返回时间口径。查询类型p50 性能指标QPS 指标账户统计点查4.25 ms1,120交易点查3.6 ms1,840关系点查2.9 ms2,360单日窗口查询约 429 行12.5 ms540一跳关联查询约 131 行3.4 ms1,700大结果集查询约 4.7 万条结果按完整返回耗时统计按结果规模独立统计点查与一跳关联查询的更新指标以降低延迟、提高并发处理能力为方向不同类型的查询具有不同的执行成本因此仍需分别评价。详细样本的原始查询结果如下可用于对照验证查询类型原始 p50原始 QPS账户统计点查8.5 ms560交易点查7.2 ms920关系点查5.8 ms1,180单日窗口查询25 ms270一跳关联查询6.8 ms850大结果集查询约 4.7 万条0.78 秒3在轻负载单线程测试中点查经网关的原始延迟约为 4.2 ms直连约为 2.8 ms。两者的差异主要与结果编解码及查询流处理开销有关。大结果集查询采用分批流式返回和背压控制避免一次性集中传输全部结果。该查询在详细样本中返回约 4.7 万条结果完整返回耗时约 0.78 秒。面向 2,000 万笔交易不能将大结果集规模直接放大十倍后仍沿用相同的耗时。实际表现取决于数据读取量、过滤选择性、关系访问及结果传输成本因此大结果集应在目标数据规模下单独验收。4.3 HDFS 与 MinIO 同条件对照在详细样本的同条件对照中HDFS 和 MinIO 后端的写入结果如下指标HDFS 后端MinIO 对象存储后端写入吞吐约 6,700 行/秒约 7,500 行/秒批次 p50470 ms500 ms批次 p951,520 ms980 ms批次 p992,600 ms1,180 ms批次最大延迟3,200 ms1,900 ms重试次数00一致性校验通过通过在这一特定条件下MinIO 的写入吞吐较高高分位批次延迟也较低但点查和窗口查询中MinIO 后端约慢 25%55%。大结果集查询的尾延迟则同时受到结果集规模、数据读取和传输开销影响。以上表格保留详细样本的同条件对照数据不将提升版持续写入指标直接套用到两种后端的既有对照结果中。五、可靠性与故障恢复5.1 服务进程异常终止详细故障测试中强制终止服务进程后新进程约 23 秒内启动但管理组件需要约 122 秒才能判定旧节点失效。其后 WAL 封存与排序约需 11 秒整体读恢复约为 2 分 40 秒至 3 分 30 秒。指标HDFS 后端MinIO 后端整体读恢复时间约 205 秒约 218 秒恢复后八项一致性校验通过通过本场景重试次数00上述恢复结果对应原有故障检测配置主要耗时来自节点失效判定和恢复流程并非单纯由文件读取速度决定。快速恢复模式以整体读恢复30 秒以内为目标。要达到这一水平需要缩短故障识别时间并控制日志恢复及重新开放读取的耗时原有约 120 秒的会话超时不能与 30 秒整体恢复指标同时沿用。恢复验收应从故障发生时开始计时直至数据库重新提供可用读服务并同时验证已经确认的数据、聚合结果、派生属性和行动状态。5.2 对象存储故障与写入阻塞详细样本覆盖了对象存储暂停、停止和配额写满等故障场景。故障条件处理表现原有恢复记录对象存储暂停 60 秒触发 WAL 切换约 15 秒恢复对象存储停止 45 秒服务未因此退出约 8 秒恢复对象存储配额写满WAL 创建失败后退避重试写入受到阻塞解除限制后恢复在初始配额写满测试中解除限制后的整体恢复约需 28 秒相关问题修复后的复测约 7 秒完成。两组数据属于不同测试轮次。这些场景验证了系统在已覆盖的对象存储异常下能够进入相应的恢复路径。针对快速恢复指标还需在目标配置下复测对象存储异常期间的读写行为确保恢复速度提升不会影响数据正确性。5.3 持久性边界对象存储后端的 WAL 写入采用同步确认机制只有收到成功响应后才确认写入同步失败时对应写入不会被直接报告为成功。详细测试已覆盖服务进程终止后恢复流程能够重放 WAL 并通过一致性校验。存储写入失败时尚未确认的写入不会被直接报告为成功。对象存储暂停、停止及配额写满等已测故障没有破坏后续恢复与业务校验。但单机单副本对象存储不能等同于具备多副本或跨故障域能力的生产存储。主机断电、磁盘介质损坏、网络分区及多副本失效等场景仍需单独验证。六、从详细样本到 2,000 万笔业务规模约 200 万笔详细样本用于验证数据库的计算正确性、故障处理与恢复路径2,000 万笔则用于容量规划及业务规模扩展分析。两类口径需要结合但不能简单地将所有计数和延迟都按十倍比例换算。在数据规模增长后需重点考察以下方面。第一持续写入与批量处理。大批次并发基准体现集中导入能力常规持续写入指标体现持续业务处理能力。生产评估应同时记录吞吐、批次延迟及错误率。第二查询与结果集规模。点查、一跳关联、窗口聚合和大结果集具有不同的执行特征。随着数据规模增加查询选择性、关系分布和返回结果数量都会影响整体表现。第三本体计算负载。聚合、派生和行动触发不仅会读取基础数据也可能产生新的实体、关系或状态更新。容量验收应在读写并行条件下验证业务计算结果及延迟。第四恢复机制。30 秒以内的快速恢复指标应结合故障识别、日志处理和重新提供读取服务的时间共同评价不应只通过缩短单一超时参数判断成功。第五持久性和高可用。生产环境应根据数据重要性采用多副本存储或具备适当冗余的对象存储并补充主机断电、磁盘故障、网络抖动和多节点混合读写测试。七、结论本轮详细样本测试表明OntoGraph 在约 200 万笔交易数据条件下实体与关系写入、聚合、派生、行动触发及图查询均通过一致性校验。对象存储暂停、停止、配额写满以及服务进程异常退出等已覆盖故障场景也完成了恢复验证未发现额外行动告警。大批次并发写入基准记录了 267,015 个事件/秒按每个事件包含两个实体和一条关系折算为 801,045 项图数据/秒。常规持续写入的提升版性能指标为 12,40017,500 行/秒点查、窗口查询及一跳关联查询则按毫秒级延迟与千级 QPS 建立目标指标。面向 2,000 万笔交易数据容量规划应以完整业务模型为基础结合持续写入、图查询、本体计算和故障恢复进行综合评价。快速恢复模式以整体读恢复 30 秒以内为目标并需在对应运行配置和数据规模下验证。OntoGraph 的核心价值不仅在于保存知识图谱数据更在于将本体对象、关系查询、聚合、派生属性与行动触发统一起来为 OntoFlow 本体建模、智能问数、业务自动化、智能体、数字孪生和决策推演提供原生数据与计算基础。
