[
https://issues.apache.org/jira/browse/KUDU-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Burkert updated KUDU-1145:
------------------------------
Component/s: (was: fs)
> Add partition functions other than identity
> -------------------------------------------
>
> Key: KUDU-1145
> URL: https://issues.apache.org/jira/browse/KUDU-1145
> Project: Kudu
> Issue Type: New Feature
> Affects Versions: Backlog
> Reporter: Ryan Blue
>
> This is something I talked with [~mpercy] about after the hackathon but
> forgot to file until now.
> The only way to control partitioning available during the hackathon was to
> use a column as part of the key. I was adding Kudu as a storage engine for
> Kite, which lets users specify the partitioning that they want using a [JSON
> formatted spec|http://kitesdk.org/docs/1.1.0/Partition-Strategy-Format.html].
> I had to restrict the supported partitioning strategies because not all of
> them could be represented in Kudu and I had no table properties where I could
> store the original.
> I heard that automatic salting is planned, which would be good. But I think
> there are a few other partition functions that would be useful, like ranges
> (part = x - (x % width)) and [geo
> hashes|http://www.bigfastblog.com/geohash-intro].
> I'm not sure whether the team will want to build those into Kudu and expose
> them via special predicates or make libraries that build on top of Kudu add
> that functionality. If it's the latter solution, then libraries like Kite
> that add them would need a way to store information about how the partitions
> are created from a row (basically, we need to store Kite's partition
> strategy).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
