[Feature](Variant) Implement inner nested data type for variant type #39022
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
eldenmoon
force-pushed
the
var_nested
branch
8 times, most recently
from
7b9885c to
5820cda
Compare
Member
Author
|
run buildall |
TPC-H: Total hot run time: 41920 ms |
TPC-DS: Total hot run time: 169921 ms |
ClickBench: Total hot run time: 30.18 s |
Member
Author
|
run buildall |
TPC-H: Total hot run time: 39346 ms |
Member
Author
|
run buildall |
2 similar comments
Member
Author
|
run buildall |
Member
Author
|
run buildall |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| } | ||
|
|
||
| void ColumnObject::finalize(bool ignore_sparse) { | ||
| void ColumnObject::finalize(FinalizeMode mode) { |
Contributor
There was a problem hiding this comment.
warning: method 'finalize' can be made const [readability-make-member-function-const]
be/src/vec/columns/column_object.h:370:
- void finalize(FinalizeMode mode);
+ void finalize(FinalizeMode mode) const;
Suggested change
| void ColumnObject::finalize(FinalizeMode mode) { | |
| void ColumnObject::finalize(FinalizeMode mode) const { |
| // and modified by Doris | ||
|
|
||
| #pragma once | ||
| #include <butil/compiler_specific.h> |
Contributor
There was a problem hiding this comment.
warning: 'butil/compiler_specific.h' file not found [clang-diagnostic-error]
#include <butil/compiler_specific.h>
^
Member
Author
|
run buildall |
TPC-H: Total hot run time: 39935 ms |
TPC-DS: Total hot run time: 202325 ms |
ClickBench: Total hot run time: 30.39 s |
ClickBench: Total hot run time: 30.5 s |
Member
Author
|
run buildall |
TPC-H: Total hot run time: 38272 ms |
TPC-DS: Total hot run time: 192313 ms |
ClickBench: Total hot run time: 31.2 s |
github-actions
bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
Contributor
|
PR approved by anyone and no changes requested. |
morningman
approved these changes
Aug 27, 2024
Contributor
morningman
left a comment
morningman
left a comment
There was a problem hiding this comment.
PROTO and THRIFR LGTM
eldenmoon
added a commit
to eldenmoon/incubator-doris
that referenced
this pull request
Sep 3, 2024
…pache#39022) Currently, importing nested data formats, such as: ``` json { "a": [{"nested1": 1}, {"nested2": "123"}] } ``` This results in the a column type becoming JSON, which has worse compression and query performance compared to native arrays, mainly due to the inability to leverage low cardinality optimizations and the overhead of parsing JSON during queries. A common example: ``` json { "eventId": 1, "firstName": "Name1", "lastName": "Surname1", "body": { "phoneNumbers": [ { "number": "5550219210", "type": "GSM", "callLimit": 5 }, { "number": "02124713252", "type": "HOME", "callLimit": 3 }, { "number": "05550219211", "type": "WORK", "callLimit": 2 } ] } } ``` Consider storing the expanded nested structure so that the schema merge logic can be utilized directly, and querying becomes easier, for example: ``` json { "n": [{"a": 1, "b": 2}, {"a": 10, "b": 11, "c": 12}, {"a": 1001, "d": "12"}] }, { "n": [{"x": 1, "y": 2}] } ``` Data would be stored as follows, with following storage format Column | Row 0 | Row 1 -- | -- | -- n.a (array<int>) | [1, 10, 1001] | [null] n.b (int) | [2, 11, null] | [null] n.c (int) | [null, 12, null] | [null] n.d (text) | [null, null, "12"] | [null] n.x | [null, null, null] | [1] n.y | [null, null, null] | [1] Data offsets are aligned (equal size). To maintain the relationship between nested nodes, such as n.a, n.b, n.c, and n.d, during compaction, if any of these columns are missing, their offsets are filled using any sibling column's offset. ```sql SELECT v['n']['a'] FROM tbl; --- This outputs [1, 10, 1001]. ``` ``` sql SELECT v['n'] FROM tbl; --- This outputs [{"a" : 1, "b" : 2}, {"a" : 10, "b" : 11, "c" : 12}, {"a":1001, "d" : "12"}]. ``` During queries, the path's nested information is not perceived because this information is ignored during path evaluation (not stored in the subcolumn tree).
eldenmoon
added a commit
that referenced
this pull request
Sep 3, 2024
gavinchou
added
dev/3.0.x
dev/3.0.x-conflict
and removed
dev/3.0.2-merged
dev/3.0.x
labels
eldenmoon
added a commit
that referenced
this pull request
Oct 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
Currently, importing nested data formats, such as:
{ "a": [{"nested1": 1}, {"nested2": "123"}] }This results in the a column type becoming JSON, which has worse compression and query performance compared to native arrays, mainly due to the inability to leverage low cardinality optimizations and the overhead of parsing JSON during queries.
A common example:
{ "eventId": 1, "firstName": "Name1", "lastName": "Surname1", "body": { "phoneNumbers": [ { "number": "5550219210", "type": "GSM", "callLimit": 5 }, { "number": "02124713252", "type": "HOME", "callLimit": 3 }, { "number": "05550219211", "type": "WORK", "callLimit": 2 } ] } }Design
Consider storing the expanded nested structure so that the schema merge logic can be utilized directly, and querying becomes easier, for example:
{ "n": [{"a": 1, "b": 2}, {"a": 10, "b": 11, "c": 12}, {"a": 1001, "d": "12"}] }, { "n": [{"x": 1, "y": 2}] }Data would be stored as follows, with following storage format
Data offsets are aligned (equal size).
Compaction
To maintain the relationship between nested nodes, such as n.a, n.b, n.c, and n.d, during compaction, if any of these columns are missing, their offsets are filled using any sibling column's offset.
Queries
During queries, the path's nested information is not perceived because this information is ignored during path evaluation (not stored in the subcolumn tree).