常见问题FAQ

如果按照文中的建议无法解决问题，请到Nebula Graph论坛提问或提交。

Nebula Graph 2.0一直在持续开发，功能或操作的行为可能会有变化，如果发现不一致，请提交issue通知Nebula Graph团队。

关于历史兼容性

nGQL兼容openCypher 9吗？

下面是nGQL和openCypher 9的主要差异（由于设计原因而不兼容）。

哪里可以找到更多nGQL的示例？

用户可以在Nebula Graph GitHub的features目录内查看超过2500条nGQL示例。

features目录内包含很多.features格式的文件，每个文件都记录了使用nGQL的场景和示例。例如：

示例中的关键字说明如下。

欢迎，成为Nebula Graph贡献者。

是否支持TinkerPop Gremlin？

不支持。也没有计划。

关于数据模型

Nebula Graph支持 W3C 的RDF（SPARQL）或 GraphQL 吗？

不支持。也没有计划。

Nebula Graph的数据模型是属性图，是一个强Schema系统，不支持RDF标准。

Nebula Graph的查询语言也不支持 SPARQL 和 GraphQL。

返回消息中`time spent`的含义是什么？

将命令返回的消息作为示例：

nebula> SHOW SPACES;
+-------------------+
| Name              |
+-------------------+
| basketballplayer  |
+-------------------+
Got 1 rows (time spent 1235/1934 us)

第一个数字1235表示数据库本身执行该命令花费的时间，即查询引擎从客户端接收到一个查询，然后从存储服务器获取数据并执行一系列计算所花费的时间。
第二个数字1934表示从客户端角度看所花费的时间，即从客户端发送请求、接收结果，然后在屏幕上显示结果所花费的时间。

可以在`CREATE SPACE`时设置`replica_factor`为偶数（例如设置为2）吗？

不要这样设置。

如果replica_factor=2，当其中一个副本故障时，就会导致系统无法工作；如果replica_factor=4，只能有一个副本可以出现故障，这和replica_factor=3是一样。以此类推，所以replica_factor设置为奇数即可。

建议在生产环境中设置replica_factor=3，测试环境中设置replica_factor=1，不要使用偶数。

大部分情况下，查询语句需要有YIELD或RETURN，请检查查询语句是否包含。

如何统计每种Tag有多少个点，每个边类型有多少条边?

请参见show-stats。

如何获取每种Tag的所有点，或者每种边类型的所有边?

建立并重建索引

> CREATE TAG INDEX i_player ON player();
> REBUILD TAG INDEX i_player;

使用LOOKUP或MATCH语句。例如：

更多详情请参见INDEX、和MATCH。

如何处理错误信息`can’t solve the start vids from the sentence`

查询引擎需要知道从哪些VID开始图遍历. 这些开始（图遍历）的VID，或者通过用户指定，例如

> GO FROM ${vids} ...
> MATCH (src) WHERE id(src) == ${vids}
# 开始图遍历的VID通过如上办法指定

或者通过一个(属性)索引来得到，例如

# CREATE TAG INDEX i_player ON player(name(20));
# REBUILD TAG INDEX i_player;
> LOOKUP ON player WHERE player.name == "abc" | ... YIELD ...

否则，就会抛出这样一个异常 can’t solve the start vids from the sentence。

如何处理错误信息`Storage Error: The VID must be a 64-bit integer or a string.`

检查输入的 vid 是否是 create space 设置的整型或者 fix_string(N). 如果是字符串类型，检查长度是否超过N (默认为 8). 见.

如何处理错误信息`edge conflict`或`vertex conflict`

Storage服务在毫秒级时间内多次收到插入或者更新同一点或边的请求时，可能返回该错误。请稍后重试。

如何处理错误信息`Storage Error E_RPC_FAILURE`

报错原因通常为Graph服务向Storage服务请求了过多的数据，导致Storage服务超时。请尝试以下解决方案：

修改配置文件: 在nebula-graphd.conf文件中修改--storage_client_timeout_ms参数的值，以增加Storage client的连接超时时间。该值的单位为毫秒（ms）。例如，设置--storage_client_timeout_ms=60000。如果nebula-graphd.conf文件中未配置该参数，请手动增加。提示：请在配置文件开头添加—local_config=true再重启服务.
优化查询语句，减少全库扫描型的查询（包括含有LIMIT的该类语句）。
检查Storaged是否发生的 OOM。(dmesg |grep nebula)
为Storage服务器提供性能更好的SSD或者内存。
重试请求。

已知问题，通常需要重试1-N次(N==partition数量)。原因为 meta client 更新leader缓存需要1-2个心跳或者通过错误触发强制更新。

是否支持停止或者中断慢查询

不支持。即使关闭了客户端，服务端仍会尽力把该查询执行完毕，无法中断。

关于运维

日志文件过大时如何回收日志？

Nebula Graph 的日志默认在 /usr/local/nebula/logs/ 下, 正常INFO级别日志文件为 nebula-graphd.INFO, nebula-storaged.INFO, nebula-metad.INFO，报警和错误级别后缀为 .WARNING 和 .ERROR.

Nebula Graph使用 glog 打印日志。glog 没有日志回收的功能，用户可以使用 crontab 设置定期任务回收日志文件，详情请参见。

如何查看Nebula Graph版本

例如，要查看Graph服务的版本，进入Graph服务对应的二进制文件nebula-graphd所在目录，运行./nebula-graphd --version。
在页搜索该commit ID，获取commit的提交时间。
对比commit提交时间和GitHub Releases页的版本发布时间，即可确定Nebula Graph的版本。

如何扩缩容

Nebula Graph 2.0.1 未提供运维命令以实现自动扩缩容，参考以下步骤：

metad 的扩容和缩容： metad 不支持扩缩容，也不支持迁移到新机器，也不要增加新的 metad 进程。
graphd 的缩容：将该 graphd 的 ip 从 client 的代码中移除，关闭该 graphd 进程。
graphd 的扩容：在新机器上准备 graphd 二进制文件和配置文件，在配置文件中修改或增加已在运行的 metad 地址，启动 graphd 进程。
storaged 的缩容：（副本数都必须大于1），参考缩容命令。完成后关闭 storaged 进程。
storaged 的扩容：（副本数都必须大于1）在新机器上准备 storaged 二进制文件和配置文件，在配置文件中修改或增加已在运行的 metad 地址，启动 storaged 进程。

storaged扩缩容之后，还需要运行。

修改Host名称后，旧的Host一直显示`OFFLINE`怎么办？

OFFLINE状态的Host将在一天后自动删除。

防火墙中需要开放哪些端口

如果没有修改过配置文件中预设的端口，请在防火墙中开放如下端口：

如果修改过配置文件中预设的端口，请找出实际使用的端口并在防火墙中开放它们。

用户可以使用如下telnet命令检查端口状态：

telnet <ip> <port>

示例：

// 如果端口已开放：
$ telnet 192.168.1.10 9669
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
// 如果端口未开放：
$ telnet 192.168.1.10 9777

FAQ