Dan Burkert has posted comments on this change.

Change subject: new range partitioning features blog post
......................................................................


Patch Set 2:

(20 comments)

New rendered version: 
https://github.com/danburkert/kudu/blob/gh-pages/_posts/2016-08-18-new-range-partitioning-features.md

http://gerrit.cloudera.org:8080/#/c/4012/1/_posts/2016-08-18-new-range-partitioning-features.md
File _posts/2016-08-18-new-range-partitioning-features.md:

Line 14: Since Kudu's initial release, tables have had the constraint that once 
created,
> "Since Kudu's initial release, tables..."
Done


Line 15: the set of partitions is static. This forces users to plan ahead and 
create
> "table's partitioning and tablets" is odd. Aren't tables partitioned into t
No, many tablets can belong to a single range partition.


Line 16: enough partitions for the expected size of the table, because once the 
table is
> Perhaps join this sentence to the previous one with a semi-colon and reword
Done


Line 17: created no further partitions can be added. When using hash 
partitioning,
> s/is adding/provides
Done


Line 19: range partitioning, however, knowing where to put the extra partitions 
ahead of
> "To support..., we removed an even more fundamental range partition restric
Done


Line 26: remote server. Range splitting is particularly thorny with Kudu, 
because Kudu
> I know "disjoint" is probably accepted jargon, but it is jargon nontheless.
I ended up making it even more jargony, but I'm not sure what else to do.


PS1, Line 31: 
            : As an 
> Here you're calling it "time series", not "timeseries". I don't have a pref
Done


PS1, Line 32: lows range partitions
            : to be
> Maybe "to partition a table by range on..."
Done


Line 42: Previously, range partitions could only be created by specifying split 
points.
> "Now that tables must no longer cover all possible rows". Hmm, that's not g
Done


Line 42: Previously, range partitions could only be created by specifying split 
points.
> s/forced/required
Done


Line 43: Split points separate an implicit partition covering the entire range 
into
> s/we/Kudu
Done


PS1, Line 45: unded b
> "continue"
Done


Line 46: the final partition being unbounded is that datasets which are range 
partitioned
> on the fly,
Done


PS1, Line 46: nded is that datasets w
> I assume you're referring to the "This is a big problem for timeseries data
Done


PS1, Line 48:  any other. Unbalanced partitions are commonly referred to as
            : hotspotting, and until Kudu 0.10 is has been difficult a difficult
> There's singular/plural confusion here. Perhaps "an old range partition for
Done


PS1, Line 56:  poin
> "combined"
Done


PS1, Line 57: specifi
> "comprise"
Done


PS1, Line 58: uarantee 
> "hash"
Done


PS1, Line 58: corresp
> "dropping"
Done


PS1, Line 59: t, Kudu will now reject writes which fall in
> "the addition or removal of one tablet per hash bucket."
Done


-- 
To view, visit http://gerrit.cloudera.org:8080/4012
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I53504d849c2aca9ff613b11e67d1533536283931
Gerrit-PatchSet: 2
Gerrit-Project: kudu
Gerrit-Branch: gh-pages
Gerrit-Owner: Dan Burkert <d...@cloudera.com>
Gerrit-Reviewer: Adar Dembo <a...@cloudera.com>
Gerrit-Reviewer: Dan Burkert <d...@cloudera.com>
Gerrit-Reviewer: Misty Stanley-Jones <mi...@apache.org>
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
Gerrit-HasComments: Yes

Reply via email to