NebulaGraph 图模型设计核心法则：属性归属点还是边的决策指南用户问题原文：“在设计图模型时，应该将属性放在点上还是边上？决策依据是什么？”本文将深入剖析这一图数据库建模的根本性问题。面向具备丰富大数据生态（Spring/Flink/ClickHouse/Hudi/Kafka）经验但初涉图数据库的工程师，我们将以供应链风险传导分析为具体案例，在NebulaGraph 3.8.0中系统性地拆解属性归属的决策逻辑。我们将从底层存储机制、查询模式优化到生产实践陷阱，提供一套清晰、可操作的决策框架。一、问题引入：一个错误的归属引发的性能雪崩在某次供应链金融项目中，团队最初将“交易金额”、“交易时间”等属性放在了supplier（供应商）和manufacturer（制造商）等点上。当需要分析“某核心企业过去一个月内所有大于100万的交易对手”时，查询变得异常复杂且缓慢。原因在于，点上的属性描述的是实体本身的状态，而无法直接表达两个实体之间的一次具体交互行为。这个错误导致了：数据冗余：同一个供应商与多个制造商交易，其“最近交易金额”属性会频繁被覆盖，丢失历史信息。查询低效：无法通过简单的边遍历获取交易详情，