Uh oh!
There was an error while loading. Please reload this page.
[Feature](Variant) Implement inner nested data type for variant type - #39022
Merged
Conversation
doris-robot
commented
Aug 7, 2024
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
eldenmoonforce-pushed
the
var_nested
branch
8 times, most recently
from
August 7, 2024 10:03
7b9885c to
5820cdaCompareeldenmoon
commented
Aug 7, 2024
MemberAuthor
run buildall |
doris-robot
commented
Aug 7, 2024
TPC-H: Total hot run time: 41920 ms |
doris-robot
commented
Aug 7, 2024
TPC-DS: Total hot run time: 169921 ms |
doris-robot
commented
Aug 7, 2024
ClickBench: Total hot run time: 30.18 s |
eldenmoon
commented
Aug 8, 2024
MemberAuthor
run buildall |
doris-robot
commented
Aug 8, 2024
TPC-H: Total hot run time: 39346 ms |
eldenmoon
commented
Aug 8, 2024
MemberAuthor
run buildall |
2 similar comments
eldenmoon
commented
Aug 8, 2024
MemberAuthor
run buildall |
eldenmoon
commented
Aug 9, 2024
MemberAuthor
run buildall |
| } | ||
| 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
| voidColumnObject::finalize(FinalizeMode mode) { | |
| voidColumnObject::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>
^eldenmoon
commented
Aug 9, 2024
MemberAuthor
run buildall |
doris-robot
commented
Aug 9, 2024
TPC-H: Total hot run time: 39935 ms |
doris-robot
commented
Aug 9, 2024
TPC-DS: Total hot run time: 202325 ms |
doris-robot
commented
Aug 9, 2024
ClickBench: Total hot run time: 30.39 s |
eldenmoon
commented
Aug 26, 2024
MemberAuthor
run buildall |
doris-robot
commented
Aug 26, 2024
TPC-H: Total hot run time: 38272 ms |
doris-robot
commented
Aug 26, 2024
TPC-DS: Total hot run time: 192313 ms |
doris-robot
commented
Aug 26, 2024
ClickBench: Total hot run time: 31.2 s |
Contributor
PR approved by at least one committer and no changes requested. |
Contributor
PR approved by anyone and no changes requested. |
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
eldenmoon added a commit
that referenced
this pull request
Oct 28, 2024
HappenLee pushed a commit
to HappenLee/incubator-doris
that referenced
this pull request
Apr 24, 2026
…pache#39022) # Background 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 } ] } } ``` # Design 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). # 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 ```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).
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
Sign up for freeto 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).