1

I am trying to design the relational table structure and standard SQL query for Apache - IoTDB (a time series database) with Calcite. Now I want to know how i can convert Calcite's logical plan to IoTDB own physical plan easily.

For example, I execute a simple query:

SELECT deviceid, temperature FROM root_ln WHERE deviceid = 'd1'

After parsing by Calcite, Logical Plan represented by RelNodes is like this:

LogicalProject(DEVICEID=[$1], TEMPERATURE=[$2])
  LogicalFilter(condition=[=($1, 'd1')])
    EnumerableTableScan(table=[[IoTDBSchema, ROOT_LN]])

And I want to convert it to IoTDB's own physical plan, which i need to provide:(just the simple example)

  1. Project's path, like root.ln.d1.temperature, we execute query by these paths. I have to put tablename(root.ln), deviceid(d1), and measurement(temperature) together to get a whole path. This needs to scan the whole logical plan.
  2. Project's datatype, like float. I can get it from paths, it's simple.
  3. Filter's expression, I have to convert LogicalFilter's expression to IoTDB's expression again, including parse what $1 means in this example.

I think it involves too much work. When the query becomes more complex, the conversion becomes more difficult too.

So I think maybe there is a simpler way to do this work.

Michael Mior
  • 28,107
  • 9
  • 89
  • 113
Xiangwei Wei
  • 27
  • 5

1 Answers1

1

The standard way of creating a physical plan for a particular data source is to create an adapter for that data source. This amounts to writing rules which can convert logical operators to physical operators. This allows data sources to specify what logical operators it can implement and how.

Michael Mior
  • 28,107
  • 9
  • 89
  • 113
  • Thanks for your response. I browsed some code of adapters recently, like Cassandra, ElasticSearch Adapter. And I got some questions. Just take Cassandra for example, it creates some relational algebra like `CassandraProject`, `CassandraFilter` and writes some responding rules to convert logical operators to these operators which represent the trait of Cassandra. Then the adapter executes a CQL query by appending the converting result which get a CQL that Cassandra needs, right? (Maybe I get a wrong point.) – Xiangwei Wei Dec 19 '19 at 12:54
  • And If I would rather convert physical operators Calcite generates to our physical plan directly than appending SQL and execute it again, is that feasible? Finally we get the result set from our database directly instead of Calcite. If it’s feasible, what I need to do is that create relational algebra like `XXXFilter` carrying the information I need and write rules to convert logical operators to that, right? – Xiangwei Wei Dec 19 '19 at 12:55
  • You're correct about how adapters work. I'm not sure what you mean about converting "to our physical plan directly than appending SQL." Once the query is oatsed and the relational algebra expression is constructed, SQL is no longer involved (unless of course you eventually execute the query against a data source which also uses SQL.) – Michael Mior Dec 20 '19 at 16:37