黄小虎

一、查询需求： 如下图所示，每条线都代表一次由起点开始的查询，如图共三行，第一行为起始点，为业务给出输入，第二行为1阶查询结果，第三行为根据1阶查询结果进行查询的2阶结果，每次查询可能有多个边。 二、

一、背景 在查询图数据库（nebula）过程中，我们往往需要具有拓扑关系的连续多次查询来作为业务的一次有效查询，比如我需要查询某点的一阶关系，获取到其一阶关系表，判断结果进行业务逻辑处理并对每个结果进

一、前言 之前一直使用图数据库封装好的api进行图关系查询与计算，最近由于评估新业务，选择直接使用graphx进行计算，当然接下来也会将数据导入nebula进行对比看看。目前梳理了下进度。 需求：算法

一、起因 业务方反馈说图服务升级后gremlin查询性能较之前旧版本慢了五倍，特此记录下定位记录和思路。 二、思路和步骤 由于新旧版数据库此时并行在一起，尚未切量，故无法通过监控来查看相关信息，使用的

一、 背景 业务方需要经常按label类型导出数据进行分析，此前一直是将全部数据（千亿点边）导出再进行label的，效率很低。选择使用spark(scala+java)来进行数据的批量导出。 二、核心

前言目前市面上存在多款开源图数据库，以及各家厂商也进行了自研图数据库（大多闭源），以符合自己的定制化要求，如何选择呢？hugegraph,janusgraph,nebula，bytegraph，腾讯图

hugegraph经过一次大的版本升级(v0.9-0.11)，其底层存储结构发生变化，新旧版本存储不兼容，社区提供了数据导出组件tools,将数据从hbase中导出为原始数据，在导入到新版图中。但并不适用于大数据量业务，主要考虑有以下两点： tools为单机，实测导入速度并不足…

1. 火焰图： 火焰图用于分析热点代码占用大量cpu,从而导致服务性能下降的情况。如下图，自底向上为调用关系。上层宽度越宽标示当前函数cpu耗时越久，我们关注最宽的函数调用。 2. 两款常用火焰图生成工具 这款工具开箱即用，本人在生产环境中也经常使用。 -d表示采样时间(s)，…

大量数据导入hugegraph库时，官方导入工具loader实际使用效率低，不适合亿级数据的导入。且loader通过原生接口进行数据导入，影响生产集群的稳定性，同时数据的持续写入会因为 flush，compaction 等机制占用较多的系统资源。 因此考虑使用bulkload直…