Hi Krishna,
I'd agree about #salt_buckets as being a multiple of #region servers. But,
that may not take into account (at least, completely) the number of region
servers that we add, going forward.
Or is it not a bad idea to begin with a large number of pre-splits initially?
That may impact read speed though.
Thanks,Sumit
From: Krishna <research...@gmail.com>
To: "user@phoenix.apache.org" <user@phoenix.apache.org>
Sent: Tuesday, January 12, 2016 12:17 PM
Subject: Re: ALTER table
General recommendation is to choose salt number as a small multiple of region
servers. If you are aware of your key distribution you can pre-split the table
in phoenix too along specific split points.
On Monday, January 11, 2016, Ken Hampson <hamps...@gmail.com> wrote:
I ran into this as well just today, and am very interested in the answer. HBase
itself allows regions to be explicitly split as well as pre-split and
auto-split. SALT_BUCKETS seems like a pre-split equivalent of sorts, so I am
interested to see what there may be in terms of auto- and explicit-salting.
Thanks,
- Ken
On Mon, Jan 11, 2016 at 6:10 AM Sumit Nigam <sumit_o...@yahoo.com> wrote:
Hello,
SALT_BUCKETS cannot be altered after table creation. I'd like to know from
advanced users as to how do we ensure that salt buckets hold up as data grows?
I might state salt buckets as say, 8 when I create table and that may hold up
for a long time. However, as data is increasing those salt buckets will not be
sufficient. Also, the value may not always be optimal for different read/ write
load types.
Or would specifying initial salt buckets will hold up as long as I make sure I
keep adding region servers as I go along?
Thanks,Sumit
