-
Notifications
You must be signed in to change notification settings - Fork 114
[PROPOSAL]: Index nested fields #347
[PROPOSAL]: Index nested fields #347
Comments
Looks good! Could you also consider |
+1 as well. Could you capture that nested fields can also be supported for included columns? |
+1 Looks awesome! Thanks @andrei-ionescu! I have a few minor questions/nits:
|
At first, it was intentional to project the field that we search by (the indexed field). But I switch to your suggestion as it seems more used. I'll add details for joins too, as I get more understanding how the plans do get composed. |
Sounds good, thank you! |
@rapoth, @imback82, @sezruby: There is an improvements that I need to address. The Given the nested dataset
and this join
resulting in the following join plan over nested fields
the Canonicalised fields:
Do you see any problems if I modify the |
@andrei-ionescu I think the problem is that canonicalized value of condition left is |
@sezruby I don't know if that is possible without other changes. The I just want to mention that the plan listed above is what Spark does by itself - Spark is adding those aliases in this case of joins. My approach was to not inject the projection into the Your suggestion is to keep the canonicalisation but to do that we need to go through projection layers to build the lineage from the join condition to relation fields. I'll try adding a function transforming the canonicalized condition fields into relation fields and use it inside The next step will be modifying the |
Based on the field name might cause some confusion/problem if there are same column names on both left and right. |
Kindly, please have a look into it. |
Problem description
This design proposal is for adding support for nested fields in both
indexedColumns
andincludedColumns
.Currently, Hyperspace does not support nested fields like structs or structured arrays.
Having the possibility to use nested fields with Hyperspace would be of great benefit to everybody.
Goal
The user should be able to create and index with nested fields and use it in queries.
For example:
Proposed solution
Using the same Hyperspace APIs indexes over nested fields should work as for other simple fields.
Given the
nestedDataset
dataset with schemaand the following data
This is the way and index on
field1
field with other 2 projection fields can be createdAdding the support for nested fields impacts the following areas:
Creating the index
Given the dataset defined above with the listed data, after doing
the following dataset will be created
It is important to understand that the name of the field of the index column is a non-nested column and due to parquet quirkiness on using
.
(dot) in the field name, it has to be properly renamed and at query time projected as it was.Search query
Given the following search/filter query
The optimized and spark plans without index are
The transformed optimized and spark plans should look like
Complexities
Transforming the plan
Filters inside the plan must be modified to accomodate the index schema not the data schema - the flattened schema not the nested field. Instead of accessing the field with
GetStructField(GetStructField(AttributeReference))
it must directly access withAttributeReference
.Given the query plan
The filter must be modified from
to
The projection from
to
The relation from
to
Hybrid scans
The transforment plans for Hybrid scans will have need to accomodate the union between the latest files arriving in the dataset having the following schema
and the index schema
Search queries
Files Appended
The optimized plan
The Spark plan
Files Deleted
The optimized plan
The Spark plan
Join queries
The following join queries will have a dataset a bit different from the one at the beginning. The following are extracted from the
HybridScanForNestedFieldsTest
tests.Join append only
Original plan
Altered optimized plan
Altered Spark plan
Delete files
Original plan
Altered optimized plan
Altered Spark plan
Append + Delete
Original plan
Altered optimized plan
Altere Spark plan
Impact
There should be no impact on the current Hyperspace implementations.
Background
This is a result of #312 discussion.
The text was updated successfully, but these errors were encountered: