[jira] [Updated] (KUDU-1440) API for scanning rows in order
[
https://issues.apache.org/jira/browse/KUDU-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KUDU-1440:
--
Labels: roadmap-candidate (was: )
> API for scanning rows in order
> --
>
> Key: KUDU-1440
> URL: https://issues.apache.org/jira/browse/KUDU-1440
> Project: Kudu
> Issue Type: New Feature
> Components: client, master, tablet
>Affects Versions: 0.8.0
> Environment: CentOS 7
>Reporter: Martin Weindel
>Priority: Major
> Labels: roadmap-candidate
> Attachments: CreateTableTimeSeriesBug.java
>
>
> I have following simple table with two columns:
> {code}
> time TIMESTAMP,
> value FLOAT
> {code}
> The time column is used as range partition key.
> If I have understand the architecture of Kudu correctly, the rows should then
> be returned in ascending order for the time column.
> This works as long as not more than about 60 rows are inserted.
> If the number of inserted rows is above 1 mio, the order is messed up
> globally. On a microlevel it is still correct 99.9% if you look on successive
> rows.
> My setup is single master / single tablet server on a linux server. The table
> is created, filled and read with the Kudu Java client version 0.8.0.
> See attached Java code to reproduce the problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KUDU-1440) API for scanning rows in order
[
https://issues.apache.org/jira/browse/KUDU-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated KUDU-1440:
--
Priority: Major (was: Critical)
> API for scanning rows in order
> --
>
> Key: KUDU-1440
> URL: https://issues.apache.org/jira/browse/KUDU-1440
> Project: Kudu
> Issue Type: New Feature
> Components: client, master, tablet
>Affects Versions: 0.8.0
> Environment: CentOS 7
>Reporter: Martin Weindel
> Attachments: CreateTableTimeSeriesBug.java
>
>
> I have following simple table with two columns:
> {code}
> time TIMESTAMP,
> value FLOAT
> {code}
> The time column is used as range partition key.
> If I have understand the architecture of Kudu correctly, the rows should then
> be returned in ascending order for the time column.
> This works as long as not more than about 60 rows are inserted.
> If the number of inserted rows is above 1 mio, the order is messed up
> globally. On a microlevel it is still correct 99.9% if you look on successive
> rows.
> My setup is single master / single tablet server on a linux server. The table
> is created, filled and read with the Kudu Java client version 0.8.0.
> See attached Java code to reproduce the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KUDU-1440) API for scanning rows in order
[
https://issues.apache.org/jira/browse/KUDU-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated KUDU-1440:
-
Summary: API for scanning rows in order (was: Wrong result ordering for
scanning a table with millions of rows)
I'm changing the title for this jira to reflect that it's a feature request,
and what it is.
> API for scanning rows in order
> --
>
> Key: KUDU-1440
> URL: https://issues.apache.org/jira/browse/KUDU-1440
> Project: Kudu
> Issue Type: New Feature
> Components: client, master, tablet
>Affects Versions: 0.8.0
> Environment: CentOS 7
>Reporter: Martin Weindel
>Priority: Critical
> Attachments: CreateTableTimeSeriesBug.java
>
>
> I have following simple table with two columns:
> {code}
> time TIMESTAMP,
> value FLOAT
> {code}
> The time column is used as range partition key.
> If I have understand the architecture of Kudu correctly, the rows should then
> be returned in ascending order for the time column.
> This works as long as not more than about 60 rows are inserted.
> If the number of inserted rows is above 1 mio, the order is messed up
> globally. On a microlevel it is still correct 99.9% if you look on successive
> rows.
> My setup is single master / single tablet server on a linux server. The table
> is created, filled and read with the Kudu Java client version 0.8.0.
> See attached Java code to reproduce the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
