...
For a database comprising around over 1,000,000 data nodes in a single anchor, the following performance was measuredresults were recorded:
| Operation | Existing solution | Proposed solution |
|---|---|---|
| Query returning 0.01% of all nodes | 20 seconds | < 50 ms |
| Query returning all nodes | 45 minutes | 45 seconds |
...
Note: using the proposed query solution without the recursive descendant search results in no performance improvement; the converse is also true. Only when the two new queries are combined that optimal performance is reached (the two queries being path-component lookup and recursive SQL descendant search).
Proof of Concept
A PoC proof of concept (poc) implementation was developed so that performance could be compared against existing Cps Path query algorithms.
Test data
These tests below were performed using Groovy/Spock tests, directly calling the Java CPS-Service Java API (thus these tests do not include any HTTP overhead as when REST APIs are used).
The test data is using the openroadm model, present in the integration-test module of CPS source code repository. In this case, each 'device node' is comprised has 86 data nodes / fragments in the database. In these tests, four anchors were populated using the same data. Thus, for 3000 device nodes, there are 3000 devices x 86 data nodes x 4 anchors = 1,032,000 total data nodes.
...
The same algorithm to improve query performance could also be used to improve performance of other operations, such as GET, UPDATE, and DELETE data nodes. (In fact, the exact same code could be used.)
However, some of these existing operations have "plural" implementations taking Collections as parameters, such as getDataNodesForMultipleXpaths. Additional investigation is needed for these cases.
...