HugeGraphServer
Hugegraphserver (hereinafter referred to as HGserver) REST-API It provides a variety of resource access methods, including five common ones: (it is recommended to test in postman)
- Graph: query vertices and edges (e.g.: IP: 8080 / graphs / hugegraph / graph / vertices)
- Schema: query vertexlabels, propertykeys, edgelabels, indexlabels (e.g.: IP: 8080 / graphs / hugegraph / schema / vertexlabels)
- Gremlin: execute gremlin statements, which can be executed synchronously or asynchronously (e.g.: g.v())
- traverser: including various advanced queries, including shortest path, intersection, N steps to reach neighbors, etc
- task: query and delete with asynchronous tasks
The first few are common CURD operations and display some help information. Here we focus on gremlin, traverser and task,
Especially asynchronous tasks
Gremlin (synchronous + asynchronous)
- Synchronization mode
//Sending is equivalent to g.V(vid)Point check of GET http://IP:8080/gremlin?gremlin=hugegraph.traversal().V('1:jin') //POST mode. If it is empty, it can not be transmitted POST http://IP:8080/gremlin { "gremlin": "g.E('S1:jin>1>>S1:tom')", "bindings": {}, "aliases": { "graph": "hugegraph", "g": "__g_hugegraph" } }
- Asynchronous mode
// 2. Asynchronous mode (Seems to support only POST,And must specify language field) // [You can use the g.V()How,g Equivalent to hugegraph.traversal()] POST http://IP:8080/graphs/hugegraph/jobs/gremlin { "gremlin": "g.V().count()", "language": "gremlin-groovy" } //Return the task ID, and then query the result through the following tasks/taskID {"task_id": 5}
Of course, it is slightly different. If the g.V(vid) statement is passed in directly, an error will be reported. Here is the graph instance object used directly. After obtaining its traverser, you can query it. But refer to the official:
You can use "aliases": {"graph": "hugegraph", "g": "__ g_hugegraph "} adds an alias to the graph and traverser and uses the alias operation. Among them, hugegraph is a primitive variable__ g_hugegraph is an additional variable added by HugeGraphServer. Each graph will have a corresponding format (_ g${graph}).
At this time, the structure of the response body is different from that of the Restful API of other Vertex or Edge, and users may need to parse it by themselves
Task (asynchronous)
Because Gremlin uses the default synchronization method to execute tasks, many tasks with a larger amount of calculation will time out or seriously affect the use, such as g.V().count(). HG provides an asynchronous way to execute tasks and provides the corresponding task information interface
//1. View all task s GET http://IP:8080/graphs/hugegraph/tasks (Posterior calcaneal"?status=SUCCESS") //return { "tasks": [{ "task_name": "INDEX_LABEL:3:createdByDateFull", "task_progress": 0, "task_create": 1546831919171, "task_status": "success", "task_update": 1546831919752, "task_retries": 0, "id": 3, "task_type": "rebuild_index", "task_callable": "com.baidu.hugegraph.job.schema.RebuildIndexCallable" }....} //2. View a specific task by passing in taskID GET http://IP:8080/graphs/hugegraph/tasks/taskID //g.V().count()Implementation results of,But the return value doesn't seem to be right..Reasons to be confirmed? //Update, statement should be changed to g.V().count().next(), Default statistical traverser { "task_name": "g.V().count()", "task_progress": 0, "task_create": 1546857683640, "task_status": "success", "task_update": 1546857684513, "task_result": "1", "task_retries": 0, "id": 5, "task_type": "gremlin", "task_callable": "com.baidu.hugegraph.api.job.GremlinAPI$GremlinJob", "task_input": "{\"gremlin\":\"g.V().count()\",\"bindings\":{},\"language\":\"gremlin-groovy\",\"aliases\":{\"hugegraph\":\"graph\"}}" }
Traverser
In fact, gremlin supports unfriendly graph algorithms, such as PageRank, K-out, K-step neighbor, shortest path, full path query, community discovery, batch query, etc The effect is close to the function encapsulation of TigerGraph. When the corresponding parameters are passed in, the required return value can be obtained directly, and the tedious gremlin statement can be avoided. In this way, many common queries can be encapsulated for the business layer, which can greatly improve the use experience and efficiency
Here are some typical representatives:
//1. Shortest path (Shortest path returned) GET http://localhost:8080/graphs/hugegraph/traversers/shortestpath?source=1&target=12345&max_depth=5&direction=OUT //return { "path": [1,27,76,582,12345] } //2.K-step neighbors GET http://localhost:8080/graphs/hugegraph/traversers/kneighbor?source=1&depth=5&direction=OUT //return { "vertices": [12,27,556,1113,233] ..... } //3. Batch query vertex / edge (Direct incoming multiple id) GET http://localhost:8080/graphs/hugegraph/traversers/vertices?ids="1:4.4.4.4"&ids="1:5.5.5.5"&ids="1:8.8.8.8" //return { "vertices": [ {"id": "1:4.4.4.4", "label": "book", "type": "vertex", "properties":{"name":[{"id": "..",...}, {"id": "1:5.5.5.5", "label": "book", "type": "vertex", "properties":{"name":[{"id": "..",...}, {"id": "1:8.8.8.8", "label": "book", "type": "vertex", "properties":{"name":[{"id": "..",...} ] } //4.1 obtaining shard slice information (Here is the whole vertex?...That means) GET http://localhost:8080/graphs/hugegraph/traversers/vertices/shards?split_size=67108864 //return { "shards":[ { "start": "0", "end": "1234567", "length": 0 }, { "start": "1234567", "end": "3456789", "length": 0 }......] } //4.2 then combine scan to get these vertices (start and end) GET http://localhost:8080/graphs/hugegraph/traversers/vertices/scan?start=554189328&end=692736660 //return (Simultaneous interpreting id Batch query,No more columns)
For the implementation of relevant codes, see HugeTraverser.java