JanusGraph 的定位先用一句话说清楚：它是一层图语义与 Gremlin 遍历引擎，本身不持有图数据。顶点和边被序列化成键值条目落在存储后端里（Cassandra、HBase、ScyllaDB、BerkeleyDB 这一类），全文检索与数值范围这类 mixed index 落在 Elasticsearch、Solr 或 Lucene 里。JanusGraph 进程手里只有遍历状态、事务上下文和当前结果集。
这个拆分带来一个很具体的后果：租机器的时候你租的不是"一台图数据库服务器"，而是三批资源池——跑 Gremlin Server 的应用层、跑键值存储的存储层、跑检索的索引层。多数团队第一次上 JanusGraph 时把预算压在应用层那两三台机器上，后端复用一套已有的 Cassandra 集群或者只给一台小机器，上线之后遍历延迟从毫秒级掉到秒级，排查一圈才发现瓶颈根本不在 JanusGraph 进程上。本文按"三批资源池各算各的"这个口径写，重点放在内存怎么估、存储怎么留、哪些参数必须限。
先说边界：下面出现的所有字节数、请求数量级、命中率分界线、比例系数，全部是工程经验值（预估），会随 JanusGraph 版本、后端版本、序列化配置、属性数量和图的度数分布变化。落地前必须在你自己的数据上压测复核，不能直接抄当成实测数据引用。涉及费用的部分一律写需询价，公开渠道差异较大，以实时报价为准。
JanusGraph 的存储模型是"邻接列表聚簇"：一个顶点的 ID 作为键值前缀，它的所有边连同边上的属性在物理上大致连续存放，取一个顶点的邻居在后端看来是一次按键范围取一段的 slice 操作。这个设计让一度遍历非常高效，也决定了后面所有性能问题的形态——每一次图上的"跳"，落到后端都是一批 slice。
索引分成两类，走的地方完全不同。composite index 由存储后端自身的有序键实现，只支持精确匹配，部分后端支持前缀或范围约束，它的开销已经包含在存储后端那批机器里。mixed index 走外部索引后端，支持全文、数值范围、地理查询和多条件组合，它有自己的堆内存、段合并和磁盘占用。这两类索引的资源账必须分开算。
三批资源池的特征差异很明显。应用层吃的是 CPU 与 JVM 堆：Gremlin 遍历步骤的状态机、展开中的顶点集合、结果集缓冲都在这里，量级相对可控。存储层吃的是页缓存与磁盘 IOPS：能不能把热图数据装在内存里，直接决定一次点查是微秒级还是十毫秒级。索引层吃的是堆内存、文件系统缓存和段合并时的 CPU 与 IO。把这三件事压到同一台机器上算，是选型阶段最常见的错误。
后端选哪种也直接改变容量模型。BerkeleyDB 只能本地单机部署，没有横向扩展能力，适合功能验证和小规模试用，选它就意味着内存估算退化成单机口径：一台机器的物理内存要覆盖全部热数据。Cassandra、ScyllaDB、HBase 可以横向扩展，但副本数会实打实地乘到资源总量上——三副本意味着同一份热数据在集群里要占三份页缓存，算内存时按"热数据乘以副本数"而不是按原始数据量算。
机器数量错觉的具体表现是：采购清单上写"JanusGraph 服务器两台，32 核 64 GB"，后端挂在一个三节点、每节点 32 GB 的旧 Cassandra 集群上，索引后端共用别的业务的 Elasticsearch。清单看起来齐全，实际热数据有 300 GB，页缓存只装得下不到一半，遍历延迟必然崩。正确的做法是把清单拆成三行，每行单独估资源，最后再合起来谈预算。
一条典型的 Gremlin：`g.V().has('user','uid','U123').out('knows').out('buy')`。执行过程分三段。第一步靠索引把 uid 换成顶点 ID——有 mixed index 就走 Elasticsearch，用 composite index 就走存储后端的有序键，这一步是整个查询里唯一一次"索引查找"，通常只有一两次请求。第二步按顶点 ID 去存储后端 slice 出所有 knows 边，反序列化出对端顶点 ID 集合。第三步对上一步得到的每一个顶点再各发一次 slice，取它的 buy 边。
关键在第二跳的展开：如果第二步返回 800 个顶点，第三步就是 800 次邻接列表读取。这些读取能不能被合并，取决于顶点 ID 在分区上的分布——落在同一个分区、同一个节点上的可以批处理成一次 multi-get，分散在十个节点上的就是十次跨机 RPC。图的 ID 分配策略和分区键设计在这里直接决定请求数。
单次请求的延迟有三档，彼此差一到两个数量级。命中后端页缓存的本地读在微秒到亚毫秒级；需要跨节点 RPC 但目标节点缓存命中的在毫秒级（多一次网络往返和队列等待）；落到磁盘的随机读在十毫秒级。所以"一次遍历几千次点查"这句话的真实含义是：端到端延迟约等于点查次数乘单次延迟，而单次延迟由缓存命中率和分区分布共同决定。优化遍历的第一步从来不是改 Gremlin 写法，而是把缓存命中率拉上去。
工程经验值（需压测验证，随度数分布剧烈变化）：中等度数图上的两跳遍历，后端键值请求数在几百到几千量级；三跳可能到万级；五跳在幂律分布的图上可以到十万甚至更高。这个数字不要当结论用，它只用来说明"跳数是乘性放大"这件事。真正的数字要在你的数据和 ID 分配策略下测。
验证方法很直接：在后端开 metrics，Cassandra 侧看读延迟分位数与读请求计数，HBase 侧看 RPC 计数与队列长度，然后单独执行一次目标遍历，观察请求计数的增量而不是看墙钟时间。同时打开 JanusGraph 侧的 profile，看每一步展开出的顶点数。两个数字对上，才知道延迟是被请求数撑大的，还是被单次延迟拖长的——这两种情况的解法完全不同。
内存压力的落点需要纠正一次：它不在 JanusGraph 进程的堆上，而在存储后端的页缓存里。Gremlin Server 的堆里放的是遍历状态机和当前结果集，一个查询占几 MB 到几十 MB，并发几十个查询也就是 GB 量级。后端要装的是整片热图数据，量级是几十 GB 到几百 GB。把内存预算加在应用层上，等于把钱花在不是瓶颈的地方。
判断口径这样定：热图数据规模 = 会被反复访问的顶点数 × 单顶点序列化字节数 + 这些顶点关联的边数 × 单边序列化字节数。然后要求这个规模能被放进"后端所有节点的页缓存总量 ÷ 副本数"里。注意除副本数这一步——三副本集群里，每份热数据会在三个节点上各占一份缓存，可用缓存总量要按副本展开后的实际占用算。
单个条目的字节数必须自己测，不要套用。JanusGraph 序列化后的顶点条目包含 ID、label 和属性键值；边条目包含 ID、label、两端顶点 ID 和边上的属性。工程经验值（需压测验证）：只有三到五个短字符串属性的顶点，加上存储层的行开销后大致在几百字节量级；一条边在一百到几百字节量级，边属性越多越大，长字符串和列表属性会显著抬高。测法有两种：用抽样统计算出平均条目数，再用存储的 SSTable 或 HFile 实际大小除以条目数；或者直接在后端节点上读压缩前后的表大小反推。
热数据和总数据要区分。真实的图里存在大量冷边：一年前的历史关系、已归档实体的关联、只被批量计算扫过一次不会被在线查询碰到的边。工程经验值（需按业务访问分布统计）：冷数据占总量的比例可能在六成到九成，也就是说热数据规模可能只有文件总大小的一到三成。按文件总大小配内存会大幅超配，按热数据配才是对的。反过来，如果你的访问模式是均匀的（比如每次查询起点随机），那热数据就等于全量数据，这个前提要先确认。
命中率的分界线（工程经验值，需压测）：后端读缓存命中率维持在九成以上时，多跳遍历的延迟基本是毫秒级；掉到七成以下，同样一条 Gremlin 会退到秒级，因为相当比例的请求要走磁盘随机读。这条线就是容量规划的目标函数——配内存的目标不是"装得下数据"，而是"让命中率站住九成"。
下表按场景档位给出第一轮预算口径，全部为工程经验值（预估），落地前需在目标数据上压测复核；费用项一律需询价，公开渠道差异较大，以实时报价为准。
| 场景档位 | 热图数据规模（顶点加边） | 存储后端内存与节点口径 | 索引后端单独要算的资源 | 必须额外留的余量 |
|---|---|---|---|---|
| 功能验证档 | 千万级顶点加边以内，冷数据可忽略 | BerkeleyDB 单机或两三节点集群，页缓存覆盖全量热数据，单节点内存 32 到 64 GB（预估） | Lucene 本地索引或单节点 Elasticsearch，堆 4 到 8 GB（预估） | 磁盘留三成给压实与临时空间，不做导入与查询混跑 |
| 中小图在线查询档 | 亿级顶点加边，热数据约占总量一到三成 | 3 到 5 节点，节点内存按热数据乘副本再乘 1.2 到 1.5 倍系数配，单节点 128 到 256 GB（预估） | Elasticsearch 3 节点，堆不超过 31 GB，剩余内存留给文件系统缓存 | 查询限最大 3 跳，4 跳以上转离线；结果条数硬上限 |
| 大图深度关联档 | 十亿级顶点加边，存在明显幂律分布 | 6 节点以上，分区键与 ID 分配策略先定再做内存测算，避免跨节点 RPC 占比过高 | Elasticsearch 5 节点以上，冷热分层，历史索引迁冷节点 | 超级节点单独建模；导入窗口与在线窗口分离 |
| 写多读少档 | 顶点规模中等，写入 QPS 高、边频繁变更 | 内存仍按热数据配，但磁盘按写入放大乘副本预留，压实带宽要单独留 | 调大 refresh 间隔，限制并发段合并线程数，给写队列留缓冲 | 锁超时与重试显式配置，锁后端独立部署并做可用性与延迟告警 |
表里最容易被跳过的是"必须额外留的余量"这一列。内存算得再准，压实空间、段合并峰值、导入期突发写入这三样没留，集群照样在业务高峰出问题。它们不是安全冗余，是必须计入的负载类型。
超级节点指的是一个顶点挂着几十万甚至上百万条边。真实图里它无处不在：热门商品的购买边、头部账号的关注边、根目录分类下的归属边、"未知来源"这类兜底实体的关联边。它的危害不是慢，是把内存一次性吃完。
具体路径是这样的：遍历走到这个顶点，JanusGraph 要取它的邻接列表。在没有 vertex-centric index 的情况下，这个顶点的全部边连同边上的属性会被整段读进内存，然后在内存里按遍历条件过滤。几十万条边乘以每条几百字节，单个顶点就是几十 MB 到上百 MB 的对象；并发几个这样的遍历，或者一个遍历里连着碰到两个超级节点，堆直接打爆。
症状有迷惑性。监控上看到的不是延迟缓慢上升，而是 Gremlin Server 的堆曲线快速锯齿化、GC 停顿时间暴涨、然后进程被 OOM 杀掉。日志里常见的是堆溢出或者 GC overhead 超限，看不到任何跟"某个顶点度数太高"相关的提示。定位要靠 profile：把遍历按步展开，看哪一步的展开顶点数出现数量级跳变，那个跳变点就是超级节点。
存储侧还有第二层问题。单个键下的 slice 特别长，会造成分区热点：这个分区的请求量远高于其他分区，节点间负载失衡，扩容加节点也缓解不了，因为热点跟着键走，不跟着节点走。这种情况加机器是无效的，必须改建模。
还有一个常被误解的点：加了 limit 不等于只读一点。能否把 limit 下推到存储层，取决于遍历步骤的组合和当前版本的优化器能力。如果下推不成功，JanusGraph 仍然要先把整段邻接列表读回来再截断，limit 只省了网络传输和序列化，没省内存。这条要在你的版本上用 profile 实测确认，不要假设。
第一条路是 vertex-centric index。做法是在边的 label 上建立以边属性为排序键的索引，通过 management API 建索引并指定排序键与排序顺序。建好之后，"取这个顶点的某类边且属性满足某范围"变成一次带范围约束的 slice，后端只返回命中的那一段，不需要把整段邻接列表拉回内存。这是把过滤下推到存储层的唯一机制。
它的代价是写放大和存储膨胀：每条被索引的边要多写一份索引条目，写入吞吐下降，导入变慢，磁盘占用上升。所以只对确认会成为热点的边 label 建，不要给所有边都建。判断依据是先统计度数分布，找出出度 top N 的顶点属于哪个 label，再针对那个 label 建。
第二条路是在建模层面把超级节点拆掉。具体做法有几种：引入中间顶点按维度分流，比如"用户-某月订单桶-商品"而不是"用户-商品"，把原本挂在用户一个顶点上的百万条边摊到几十个桶顶点上；把属性从边上移到中间顶点上，让边只承担连接语义；给边加分区维度，把一维的邻接列表变成二维。取舍很明确：拆分之后 Gremlin 写法变复杂，探索式查询不再直观，业务方理解成本上升。
两条路不是二选一，而是分阶段。短期先用 vertex-centric index 缓解，成本最低、改动最小；长期如果数据规模继续增长，必须回到 schema 拆分。原因在于索引只能缩小单次扫描的范围，它改变不了"一个键下挂一百万条边"这个物理事实——即使有索引，扫描一个大范围仍然是大操作，只是比全量扫好。
阈值怎么定（工程经验值，需压测验证，与条目大小和堆配置强相关）：单顶点出度超过一万就该评估，观察它对堆和分区负载的影响；超过十万基本必须拆分或者建索引；超过百万时，建索引只能救急，schema 不改迟早出事。这个阈值不要照抄，用你自己机器的堆大小和单条目字节数反推能承受的邻接列表大小。
每一跳都在乘性放大顶点集合。起点 10 个顶点、平均出度 50 的图上，一跳 500，二跳两万五千，三跳一百二十五万。这是乘法不是加法，所以资源曲线是指数的。真实图还有幂律分布，少数顶点度数极高，遇到它们时放大比平均值算出来的更剧烈，平均值在这里是误导性指标，要看度数分布的分位数。
工程经验值（需压测验证）：同一条查询在 2 跳和 5 跳之间，后端键值请求数可能差三到五个数量级，端到端延迟从几十毫秒涨到几十秒甚至超时。这个区间的宽度取决于度数分布和缓存命中率——命中率高的时候差距小一些，命中率一掉，深跳的延迟会加速恶化，因为深跳碰到的顶点更冷、更容易落到磁盘。
所以三条限制是必须项，不是优化项。第一条是按跳数限流：在应用层对最大跳数设硬上限，超过的查询拒绝或者转离线图计算任务，不要让业务方能随便提交 8 跳的探索查询。第二条是限制返回条数：给结果集设硬上限，并确保 limit 真的能下推（用 profile 验证），避免"查到一百万条再在应用侧截断"。第三条是加查询超时。
超时必须分层设，只设一层会出事故。至少三层：Gremlin Server 侧的查询求值超时、后端驱动侧的请求超时、后端服务端自身的读超时。三层的时长要依次递减或者留出余量，让外层先超时时内层也能感知并释放资源。只在上层设超时的典型后果是：应用层已经放弃这个查询，后端的读还在跑，资源被已死查询持续占用，越积越多。
还有一条容易忽略的取舍：结果集是流式返回还是全量收集。全量收集意味着整个结果集堆在堆内存里，深跳加宽结果的组合下，这一项就能把堆吃掉。能流式的场景走流式，需要在应用层排序或者去重的场景才收集，收集时要有条数上限保护。
先判断要不要上 mixed index。composite index 走存储后端的有序键，只支持精确匹配，但对等值查询来说已经够用，而且不需要额外机器。只有当查询里出现全文检索、数值范围、地理条件或者多条件组合时，才需要 mixed index。判断错了的代价是一整个资源池：多了几台机器、一套运维、一份一致性复杂度。
Elasticsearch 侧的堆内存口径和常规检索集群一致，但有个容易搞反的点：堆不要开得过大，因为字段数据和聚合大量依赖操作系统的文件系统缓存，把物理内存都划给堆会挤掉缓存。常见做法是把堆控制在 31 GB 以内（压缩指针阈值，工程经验值，需按版本验证），剩下的物理内存留给文件系统缓存。所以索引节点不是"内存越大堆越大"，而是总内存要够、堆要克制。
段合并是第二笔账。写入索引时会产生新段，后台合并段要吃 CPU 和磁盘 IO，和在线查询争抢同一份资源。图数据的写入往往是持续的、小批量的，段合并压力比一次性批量导入的检索场景更难预测。工程做法（需压测验证）：调大 refresh 间隔减少小段产生，限制并发段合并线程数，把合并峰值摊平；同时把段合并队列长度做成监控项，队列持续堆积说明写入速率超过了合并能力。
磁盘占用也要单独估。索引的磁盘占用通常是原始数据的一到几倍，取决于分词方式、是否存储原始字段、副本数。图上的顶点属性如果全部索引，索引层的数据量可能接近甚至超过存储层，这一项在容量清单里经常被漏掉，等磁盘告警了才发现。
一致性是这笔账的隐藏成本。mixed index 的写入和存储后端的写入不在同一个事务里，索引侧是最终一致的：刚写入的数据可能查不到，或者索引条目与后端数据在异常中断后出现不一致。JanusGraph 提供相关的索引修复与重建机制，但这意味着"写完立刻查"这件事需要显式处理——要么在业务侧容忍短暂延迟，要么走一致性配置把索引读取和后端状态对齐，后者有性能代价。这个取舍要写进设计文档，不要默认没有。
JanusGraph 的写事务依赖锁机制来保证邻接列表修改的一致性，锁后端可以独立配置。图上相邻顶点的修改天然容易冲突：两个事务同时给同一个顶点加边、同时改同一条边的属性，或者两个事务在遍历中同时触及同一个顶点的邻接列表，都会撞锁。图结构越密、写入越集中在少数顶点，撞锁概率越高。
撞锁的表现是事务提交变慢、超时、抛出锁相关的异常。在写多读少的场景里——实时风控图、实时关系写入、流式更新的画像图——这个概率显著上升，而且往往在业务高峰才暴露，因为平时并发低、锁等待被掩盖了。所以这类场景在选型阶段就要把锁等待当成一项资源来评估。
锁后端的选择不要留默认。锁后端的可用性直接决定写入可用性：存储后端还活着但锁后端不可用，写入就卡住。所以锁后端要独立部署、要有监控和告警、要按写入 QPS 估容量。把它挂在一个共享的、没人管的实例上，等于把写入路径的单点风险放在最不显眼的位置。
一致性级别的取舍要按业务定，不能一刀切。反欺诈的判定链路、资金相关的关联校验，读到旧值可能导致误判，这类要较高的一致性要求，代价是写入延迟上升、可用性下降。画像统计、推荐候选生成、离线标签计算，容忍秒级甚至分钟级的延迟，可以放低一致性要求换吞吐。同一个集群上跑两类业务时，用不同的 keyspace 或者不同的图实例分开，不要混在一起调一个全局参数。
具体要显式配的项：锁等待超时时间、事务重试次数、重试退避策略、事务提交前的冲突检测范围。这些都有默认值，但默认值是按通用场景定的，在写密集的图上通常不适用。同时把"锁等待时长"和"事务重试率"做成监控指标，它们比错误日志更早反映冲突加剧。
批量导入有专门的工具链（常见的是基于 Spark 的 bulk loader），它按后端原生的格式直接生成数据文件并交给后端加载，绕开了正常的事务路径，因此不受锁开销和事务日志的约束，吞吐量比逐条事务写入高一个量级。也要认清它的边界：bulk loader 通常要求图schema 预先定义好，导入期间不保证在线查询看到的数据视图是完整的，也不走索引后端的实时更新。
瓶颈发生转移。导入期的瓶颈不在 Gremlin Server，不在应用层，而在存储后端的写入吞吐与压实能力：Cassandra 与 ScyllaDB 侧是 SSTable 的刷写与压实，HBase 侧是 MemStore 刷写与 HFile 压实。这三样吃的是磁盘吞吐、压实线程和磁盘空间，而不是页缓存。所以"用跑在线查询的同一批机器做导入"是个明确的坑。
坑的具体形态：导入把磁盘写满或者把压实队列堆到很长，导入进程结束了，压实还在追，这段时间内在线查询的读延迟和读放大都显著恶化，可能持续数小时。症状上表现为"导入明明已经完成，业务还是慢"，排查方向如果盯着图服务就找错了。
三条做法。第一条是错峰或者分离：导入窗口和在线查询窗口分开排，规模大的用独立集群导入再切换，不要在业务高峰边上做全量重建。第二条是磁盘留余量，工程经验值（需按后端压实策略验证）是给压实留三成以上的空闲空间，压实需要临时空间，盘快满的时候压实可能卡住甚至失败。第三条是限速：导入速度按后端能追平的压实速率来定，不是按你能生成多快的数据来定，生成侧快一倍，压实追不上，最后总时间反而更长。
索引后端也要单独排期。mixed index 需要在数据导入之后或导入过程中重建索引，reindex 本身是一次全量扫描，有自己的时间开销和资源开销，并且会触发前面说的段合并峰值。容量清单里要给 reindex 单独留一个时间窗和资源余量，不要把它算进导入时间。
第一种：图规模很小。顶点和边在百万量级以内、关联深度固定、关系类型就那么几种，用关系型数据库的递归查询就够了。PostgreSQL 的 WITH RECURSIVE 能处理固定深度的关联展开，配合邻接表和几张覆盖索引，二度三度查询的延迟完全可以接受。它的优势在于运维是现成的：备份恢复、监控告警、扩容、故障排查都有一套成熟流程。上 JanusGraph 意味着引入三批机器和两套分布式系统运维，收益覆盖不了成本。
第二种：要跑的是全图算法。PageRank、社区发现、连通分量、全图最短路径这些算法要反复扫描全部边，计算模型是迭代式的批量扫描，不是逐顶点点查。这类场景应该交给图计算框架（GraphX、Giraph 这一类，或者专门的图计算引擎），把图一次性装载进内存做迭代。用 Gremlin 逐顶点遍历跑全图算法，会撞上前面说的点查放大：一次迭代就是全量边的点查，几十次迭代下来时间不可接受。图数据库和图计算框架解决的是两类问题，别拿一个顶另一个。
第三种：查询模式固定、深度有限但吞吐要求极高。典型如"给定用户，取二度关系里满足某条件的商品"，这种固定查询用预计算加缓存加键值存储更快更省：把结果离线算好写进缓存，在线只做一次键值读取。图数据库的价值在于查询模式不固定、需要临时探索、关联维度随时变。模式固定时，图数据库带来的灵活性用不上，只留下三批机器的成本。
第四种：团队里没有人能运维分布式键值存储。Cassandra 或 HBase 的压实策略调优、分区键设计、副本修复、节点上下线、读放大排查，都是独立技能，需要专门的人。如果团队没有这块能力，上 JanusGraph 等于把最大的风险放在自己最弱的地方——而且故障往往不在图服务那一层，排查时最容易看错方向。这种情况要么先补人，要么选托管程度更高的图数据库产品。
判断顺序：先问"查询模式是不是固定的、深度是不是可控"——是，考虑键值加预计算；再问"是不是要跑全图迭代算法"——是，用图计算框架；然后问"团队有没有人能运维分布式键值存储"——没有，先别上；三个都过了，再谈 JanusGraph 的三批机器怎么配。
把前面所有开销项收敛成一个可执行的计算顺序，按从上往下走，不要跳步。第一步，统计热图数据规模：确定哪些顶点和边会被在线查询反复访问，按访问分布而不是按总量算，测出单顶点与单边的序列化字节数。第二步，定存储后端内存：热数据规模乘以副本数，再乘 1.2 到 1.5 的余量系数（工程经验值，需压测），除以节点数得到单节点内存目标，验证标准是后端读缓存命中率能站住九成。第三步，定索引后端：按有没有全文与范围查询决定要不要上，上就按节点数、堆不超过 31 GB、剩余内存留给文件系统缓存来配，并预留段合并峰值。第四步，设查询边界：最大跳数、结果条数上限、三层超时，用 profile 验证 limit 能下推。第五步，给导入期单独留窗口与磁盘余量，压实空间留三成以上。第六步，剩下的才是应用层机器的规格。
资源边界用一句话表述：后端缓存命中率高于九成时，多跳遍历的延迟是毫秒级；命中率掉到七成以下，同一条 Gremlin 从毫秒级退到秒级，因为相当比例的键值请求要走磁盘随机读（工程经验值，需在你的数据上压测验证）。这条线就是容量规划的目标函数，配内存不是为了装下数据，是为了让命中率站住。
要长期盯的监控项，按重要性排：后端读延迟的 p99 分位数、后端读缓存命中率、每次遍历按步展开的顶点数分布（用来发现跳数放大和超级节点）、出度 top N 顶点及其变化趋势、锁等待时长与事务重试率、索引后端的段合并队列长度、压实待处理量与磁盘空闲比例。前四项决定在线延迟，后三项决定写入与导入期的稳定性。
机器形态上的取舍：存储后端节点优先选大内存加本地 NVMe，因为页缓存和压实都吃本地资源；索引后端节点同样要大内存，但磁盘要按索引膨胀后的量配；应用层节点的规格反而可以保守，它是 CPU 与堆的组合，横向扩容也最容易。三批机器的配比不要均分，按上面的顺序算出来的数字往往差异很大。具体机型、带宽、IP 与存储扩容等费用项一律需询价，公开渠道差异较大，以实时报价为准，可联系一万网络（深耕 19 年（成立于 2007 年）获取对应配置的实时报价。
本文的机制描述基于公开的 JanusGraph 架构与文档口径：图数据以邻接列表形式序列化到可插拔的存储后端（Cassandra、HBase、ScyllaDB、BerkeleyDB 等），索引分为由存储后端键序实现的 composite index 与依赖外部索引后端（Elasticsearch、Solr、Lucene）的 mixed index；Gremlin 遍历按步展开顶点集合，每一次跳跃落到后端是一批键值 slice 操作；写事务依赖独立可配置的锁后端；批量导入通过专门的 bulk loader 绕过事务路径直接写后端；索引后端与存储后端之间为最终一致，需要显式的索引修复与重建流程。
需要你在自己环境里逐条核对的项目：热图数据的顶点数与边数，以及单顶点、单边的实际序列化字节数（用存储文件大小除以条目数反推，不要套用经验值）；副本数与热数据乘副本后的实际缓存占用；后端读缓存命中率的实测值与目标值（九成）的差距；单顶点出度的分布分位数与出度 top N 顶点列表；目标边 label 上是否已建 vertex-centric index，以及 limit 是否真的下推到存储层（用 profile 逐步确认）；一次 2 跳、3 跳、5 跳遍历各自的后端键值请求数增量；三层超时（查询求值、驱动请求、后端读）的实际取值与递减关系；锁后端是否独立部署、锁等待超时与重试策略是否为显式配置；索引后端堆大小、文件系统缓存余量、段合并队列长度与索引磁盘占用；导入期的压实待处理量、磁盘空闲比例与导入限速值。
核对方法：用后端的 metrics 接口读取读延迟分位数、读请求计数、压实队列与磁盘使用，在执行目标遍历前后做差值而不是只看墙钟时间；用 JanusGraph 的 profile 逐步展开遍历，记录每一步的顶点数，找出跳变点定位超级节点；用度数统计任务定期输出出度分布，把 top N 顶点纳入监控；用一次真实的批量导入演练来测量压实追平时间，不要在生产高峰第一次跑这个流程；用一次真实的索引重建来测量 reindex 的耗时与资源峰值。
本文不涉及任何价格数字。服务器租用、带宽、IP、存储扩容、索引节点与备份等费用项一律需询价，公开渠道差异较大，以实时报价为准。文中所有字节数、请求数量级、命中率分界线、度数阈值、比例系数与规格数字均为工程经验值（预估），用于建立容量计算框架与排查顺序，落地前需在目标数据、目标版本与目标硬件上压测验证，不作为实测数据引用。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
