Community
Pick of the Week at NebulaGraph - SQL vs nGQL & Job Manager in NebulaGraph
Normally the weekly issue covers Feature Explanation and Community Q&As. If something major happens, it will also be covered in the additional Events of the Week section.
Events of the Week
This Comparison Between SQL and nGQL document will help you transit from SQL to nGQL and quickly understand the usage of nGQL.
Feature Explanation
This week let's talk about the Job Manager feature.
There are some time-consuming tasks running at the storage layer of NebulaGraph. For such tasks, we provide Job Manager, a management tool, for releasing, managing, and querying the jobs.
We currently provide Compact and Flush for task releasing. Compact is usually used to clear data that has been marked for deletion from the storage layer, and flush is used to write back the memfile in memory to the hard disk.
Scenario #1: Release RocksDB Compact Task.
To release a RocksDB compact task, you can run the SUBMIT JOB COMPACT; command and a Job ID is returned, as shown in the following figure:
To write the RocksDB memfile in the memory to the hard disk, you can run the SUBMIT JOB FLUSH; command and a Job ID is returned, as shown in the following figure:
Scenarios #2: Query Tasks.
In terms of task query, we support to list a single job or all jobs for task querying.
To find all the jobs, you can run the SHOW JOBS; statement to do the full job query. All the job IDs are returned, as shown in the following figure：
In this job list, you can see information such as Job ID, Task ID, commands and the landing nodes.
After obtaining the specific ID of a job, you can use SHOW JOB <JOB ID>; to query the details. From the job details, you can get the Task ID of each task. Generally, each node for the storaged service has one Task ID, so the number of Task IDs depends on the number of nodes for the storaged service.
The command STOP JOB <JOB ID>; can be used to suspend ongoing tasks.
You can also use RECOVER JOB; to resume suspended tasks.
Community Q&A
Q: The LOOKUP query is quite slow. What can I do to optimize the performance?
A: The slow query speed may be caused by the unordered data. The LOOKUP statement needs schema indexes to work well, but the indexes can retrieve data efficiently only when the data are in order. If a large amount of data is imported, we recommend that you do a Compact operation on the data to make them in order. By doing so, the LOOKUP query speed can be improved.
