Re: [alto] Considerations about More Flexible ALTO Query/Filter

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hi Jensen,

Thank you for bringing these considerations.
Do you have examples of filters or constraints that you would like to add to queries for Unified Properties or Path Vector and that cannot be achieved with the current ALTO design?
Also, do you have examples that illustrate the limitations of NoSQLs or document-oriented databases wrt ALTO? And examples for option1 and option2.

Thanks,
Sabine


From: alto <[e-mail]> On Behalf Of Jensen Zhang
Sent: Friday, March 27, 2020 3:28 AM
To: IETF ALTO <[e-mail]>
Subject: [alto] Considerations about More Flexible ALTO Query/Filter

Hi all,

I'm considering the extension to the current ALTO information resource query.

Currently, ALTO can only support the very simple query (e.g., Filtered Network Map, Filtered Cost Map). Although Filtered Cost Map supports the test constraint, it is very limited and cannot be applied to some new ALTO extensions (e.g., path vector and unified properties).

So far, as I know, most of NoSQLs or document-oriented databases (e.g., MongoDB [1], PostgreSQL [2], ElasticSearch [3]) have JSON query support. I think we can leverage them to query ALTO information resources. However, all of them have a clear limitation when applied to ALTO: the query statement must specify the concrete field names. But all of ALTO information resources use non-fixed fields (e.g., PIDName in Network Map, src and dst TypedEndpointAddr in ECS).

To extend the current ALTO query, I can think about two options:

Option 1: we define a conversation between the ALTO JSON schema and some other schema using fixed fields (e.g., the JSON schema defined by YANG model [4]). Then the client can use the JSON query languages in existing database systems to query the later schema, but the ALTO server transfers the result to the former (ALTO) schema and returns it. In the backend, most of the ALTO implementations should be based on those database systems. So this option can be acceptable in practice.

Option 2: we use some more flexible JSON query language (e.g., JSONiq [5]), or define a new query language for ALTO specific. This option can be more valuable if we want to design a new database system for ALTO.

Looking forward to seeing more comments and discussions from WG.

[1] https://docs.mongodb.com/manual/tutorial/query-documents/
[2] https://www.postgresqltutorial.com/postgresql-json/
[3] https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html
[4] https://tools.ietf.org/html/draft-shi-alto-yang-model-03<https://tools..ietf.org/html/draft-shi-alto-yang-model-03>
[5] http://jsoniq.org/

Best regards,
Jensen