Page Comparison

...

A new Cps Path query algorithm is being proposed. The time complexity was measured assessed through code analysis and performance testing, for existing and proposed solutions, and is found to be:.

For a database comprising over 1,000,000 data nodes in a single anchor, the following results were recorded:

...

/bookstore/categories[@code="1"]/books[@title@price="Matilda"15]

the following SQL query is generated:

SELECT
    * 
FROM
    FRAGMENT 
WHERE
    anchor_id = 3
    AND xpath ~ '/bookstore/categories\[@code=''1'']/books(\[@(?!.*\[).*?])?$' 
    AND (
        attributes @> '{"titleprice":"Matilda"15}'
    )

The use of regex potentially results in full table scans (as each node's xpath needs to be compared against the regex), severely impacting performance, and causing query time duration to grow linearly with the fragment table size (i.e. queries get slower as the database gets bigger).

In addition, the mechanism for fetching descendant nodes returned from the query causes causes quadratic complexity in the worst case quadratic performance.

Why does the existing solution have worst case quadratic complexity?

...

1. An SQL query that returns nodes matching query criteria - O(N)
2. For each node returned from query 1, another SQL query is issued to fetch that node with descendants, using a LIKE operator - O(N).

The LIKE operator has linear time complexity, as all nodes' xpaths in a given anchor need to be examined.

In the case of a query that matches all N nodes, we In the case of a query that matches all N nodes, we are issuing 1+N queries, each with complexity O(N). Thus the overall complexity is O(N²).

...

/bookstore/categories[@code="1"]/books[@title@price="Matilda"15]

The new approach will used nested sub-queries to search for each path component, first looking for "bookstore", and using that as the parent node, look for ''categories[@code='1']", and using that as parent, look for "books" before finally applying leaf condition checks.

...

SELECT
    * 
FROM
    fragment 
WHERE
    parent_id IN (
        SELECT
            id 
        FROM
            fragment 
        WHERE
            xpath_component = 'categories[@code=''1'']'
            AND parent_id =IN (
                SELECT
                    id 
                FROM
                    fragment 
                WHERE
                    xpath_component = 'bookstore'
                    AND anchor_id = 3
                    AND parent_id IS NULL
            )
        ) 
        AND (
            xpath_component = 'books'
            OR xpath_component LIKE 'books[%'
        ) 
        AND (
            attributes @> '{"titleprice":"Matilda"15}'
        )

In addition, a new algorithm for fetching descendants is implemented.

...

WITH RECURSIVE descendant_search AS (
  SELECT id, 0 AS depth
    FROM fragment
   WHERE id IN (:fragmentIds)
   UNION
  SELECT child.id, depth + 1
    FROM fragment child INNER JOIN descendant_search ds ON child.parent_id = ds.id
   WHERE depth <= :maxDepth
) 
SELECT f.id, anchor_id AS anchorId, xpath, f.parent_id AS parentId, CAST(attributes AS TEXT) AS attributes 
FROM fragment f INNER JOIN descendant_search ds ON f.id = ds.id

There is existing code in CpsDataPersistenceService similar to this, so minimal code changes are required to implement this.

Comparison with existing solution

...

Here is a visualization of both algorithms, executing a query for /bookstore/categories[@code='1']/books[@title@price='Matilda15']:

Detailed Performance Comparison

Proof of Concept

A proof of concept (poc) implementation was developed so that performance could be compared against existing Cps Path query algorithms.

Test

...

setup

These tests below were performed using Groovy/Spock tests, directly calling the CPS-Service Java API (thus these tests do not include any HTTP service 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' has 86 data nodes. 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 + parent node = 1,032,000 001 total data nodes.

The test timings used to generate the charts in this document is available as a spreadsheet: CPS-1646 CpsPath queries using path-component lookup.xlsx

...

Query one device out of many

...

In this case, a query that matches a single device node is executed.

Case	Query one out of many using descendant cps path	Query one out of many using absolute cps path
Query	//openroadm-device[@device-id="C201-7-1A-14"]	/openroadm-devices/openroadm-device[@device-id="C201-7-1A-19"]
Comparison graph		Image Modified
Graph detail
Time complexity of existing solution	O(N)	O(N)
Time complexity of proposed solution	O(N)	Near-constant, O(1)

...

Comments

The use of LIKE 'openroadm-device[%' in the

...

Note: I have not illustrated all different fetchDescendantOptions, as it has only minor impact in the case of fetching 1 device node.

Query all devices (N out of N) using descendant cps path

In this case, a query that matches all device nodes using a descendant cps path is executed.

...

Direct Descendants

...

All Descendants

...

...

...

...

...

...

...

Time complexity of
existing solution

...

Query all devices (N out of N) using absolute cps path

...

As seen in the graphs, query performance for current master branch is linear on the size of the database, while the PoC implementation is constant time (independent of database size).

Note: I have not illustrated all different fetchDescendantOptions, as it has only minor impact in the case of fetching 1 device node.

Query all devices using descendant cps path

In this case, a query that matches all device nodes using a descendant cps path is executed.

...

Cps Path Query capabilities can be extended

Presently, Cps Path queries limit leaf-condition, text-condition, etc. to the final path component. The proposed solution allows for future improvement where conditions could be applied to any or all path components.

For example, given these queries:

1. /bookstore/categories[@code='1']/books[@title='Matilda']
2. /bookstore/categories[@name='SciFi']/books[@title='Matilda']
3. /bookstore/categories/books[@title='Matilda']

Presently, only case 1 will return data, and cases 2 and 3 return nothing. Given the proposed solution uses an SQL sub-query for each path-component, the query generator can be adapted to support cases 2 and 3. The main work required for this would be changes to the Cps Path parser.

Other operations can be accelerated

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.

However, some of these existing operations have "plural" implementations taking Collections as parameters, such as getDataNodesForMultipleXpaths. Additional investigation is needed for these cases.

...

Query all devices using absolute cps path

In this case, a query that matches many device nodes using an absolute cps path is executed.

Possible improvements

Optimization: Index-only lookup when list key is used in leaf condition

Given the following CPS path query:

...

We can optimize for this case, by checking if xpath_component = "books[@title='Matilda']", thus avoiding the need to examine the attributes field in the fragment table (thus the entire operation involves only database indexes).

In the PoC implementation, the following is a snippet from the SQL generated from the CPS path query:

        AND (
            xpath_component xpath_component = 'books' OR xpath_component LIKE 'books[%'
        ) 
        AND (
            attributes @> '{"title":"Matilda"}'
        )

it It may be replaced with this to add the new functionality:

        AND (
            xpath_component = 'books[@title=''Matilda'']'
            OR (
                (xpath_component = 'books'               xpath_component = 'books' OR xpath_component OR xpath_component LIKE 'books[%'
     ) 
         )                 AND (
                    attributes @> '{"title":"Matilda"}')
                )
             )         ) 

This would allow for an index-only lookup of the node, without needing the LIKE comparison or the attribute checkor the attribute check.

Optimization: Faster look-ups for lists and list elements

Given the bookstore model where books are stored in a list, and given a path query //books[@price=15], using proposed solution, this would use a LIKE 'books[' to find potential matches.

AND (xpath_component = 'books' OR xpath_component LIKE 'books[%')

The use of the LIKE operator in this case would result in O(N) time, as every fragment may need to be compared against the LIKE pattern. There is a solution which may push this case toward constant O(1) performance, namely adding the list name as an indexed column to the fragments table - note only list elements need this field populated, container nodes can set this field to NULL:

Our query could be modified to replace the LIKE with an indexed look up:

AND (xpath_component = 'books' OR list_name = 'books')

This would give rise to constant time look up in such cases. If this solution is not implemented, users can work around this problem wrapping lists in container nodes, with the container being included in the descendant query, e.g. instead of //books[@title='Matilda'], change the model and use //books/book[@title='Matilda'] as a query. This would then have O(1) performance.

Note: if we wish to avoid creating additional database fields, using list/container name field would offer the best balance of performance, e.g.

In this case, attributes for any list element path component would need to be looked up (so it would no longer be index-only). My suspicion is that this would have better general performance than using xpath_component alone, but testing is needed to verify.

Cps Path Query capabilities can be extended

Presently, Cps Path queries limit leaf-condition, text-condition, etc. to the final path component. The proposed solution allows for future improvement where leaf conditions could be applied to any or all path components.

For example, given these queries:

1. /bookstore/categories[@code='1']/books[@title='Matilda']
2. /bookstore/categories[@name='SciFi']/books[@title='Matilda']
3. /bookstore/categories/books[@title='Matilda']

Presently, only case 1 will return data (because 'code' is the list key for 'categories'), and cases 2 and 3 return nothing. Given the proposed solution uses an SQL sub-query for each path-component, the query generator can be adapted to support cases 2 and 3, with little expected performance impact. Note this feature would require storing the container/list name as an indexed field, as described in the previous section.

Other operations can be accelerated

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. However, some of these existing operations have "plural" implementations taking Collections as parameters, such as getDataNodesForMultipleXpaths. Additional investigation is needed for these cases.

Work Breakdown for Implementation

In addition to the changes outlined aboveBeside the work done in the PoC implementation, there is additional work remaining for this change to be production-ready.  The main algorithm was is mostly done during complete in the PoC (all integration tests are passing for the PoC). The existing PoC code can thus be refactored to make it production ready.

It may be possible to incorporate the recursive SQL descendant search into the existing solution as a starting point.

DB upgrade

Because a new column is being added to the Fragment table, this column needs to be populated. An SQL script will be needed to provide a value for of the new xpath_component field based on existing xpath fieldbe refactored to make it production ready.

Fetch descendants

The proposed solution can broadly be broken into two major changes:

1. Cps Path query using path-component look-up
2. Using recursive SQL to fetch descendants of nodes returned from 1.

I proposed that the recursive SQL to fetch descendants be implemented first as an independent change, as it move worst-case complexity from O(N²) to O(N). By contrast, the query using path-component look-up will improve best-case performance from O(N) to O(1).

Cps Path Parser changes

The PoC uses String.split for parsing path components, which means paths containing '/' in the leaf condition are not parsed correctly, such as //books[@title='GNU/Linux']. CpsPathBuilder and CpsPathQuery classes from cps-path-parser module will need to be updated to provide the individual path components (in normalized form).

DB upgrade

Because a new column is being added to the Fragment table, the new column needs to be populated during DB upgrade (to maintain backwards compatibility with existing databases). An SQL script will be needed to provide a value for of the new xpath_component field based on existing xpath field.