Thanks Mujtaba. This is good to know. It is possible manipulate the key bit to
avoid the hot-spotting, so we are probably trying unsalted table out.
Still, it would be nice if combined indexes in a single table is possible.
> On Jul 11, 2016, at 2:41 PM, Mujtaba Chohan
FYI if you keys are not written in order i.e. you are not concerned about
write hot-spotting/write throughput then try writing your data to an
un-salted table. Read performance for un-salted table can be comparable or
better to salted one with stats
This indexes will be salted indeed. (so is the data table). If all indexes
reside in the same table, there will be only 512 regions in total (256 for data
table, 256 for the combined index table). Indeed the combined index table will
be 12x large as a single index table. But it doesn’t cover
Will the index be salted (and that's why it's 256 regions per table)? If
not, how many regions would there be if all indexes are in the same table
(assuming the table is 12x bigger than one index table)?
On Monday, July 11, 2016, Simon Wang wrote:
> Thanks, Mujtaba. What
Thanks, Mujtaba. What you wrote is exactly what I meant. While not all our
tables needs these many regions and indexes, the num of regions/region server
can grow quickly.
-Simon
> On Jul 11, 2016, at 2:17 PM, Mujtaba Chohan wrote:
>
> 12 index tables * 256 region per
12 index tables * 256 region per table = ~3K regions for index tables
assuming we are talking of covered index which implies 200+ regions/region
server on a 15 node cluster.
On Mon, Jul 11, 2016 at 1:58 PM, James Taylor
wrote:
> Hi Simon,
>
> I might be missing
Hi Simon,
I might be missing something, but with 12 separate index tables or 1 index
table, the amount of data will be the same. Won't there be the same number
of regions either way?
Thanks,
James
On Sun, Jul 10, 2016 at 10:50 PM, Simon Wang wrote:
> Hi James,
>
>
Hi James,
Thanks for the response.
In our use case, there is a 256 region table, and we want to build ~12 indexes
on it. We have 15 region servers. If each index is in its own table, that would
be a total of 221 regions per region server of this single table. I think the
extra write time cost
Hi Simon,
The reason we've taken this approach with views is that it's possible with
multi-tenancy that the number of views would grow unbounded since you might
end up with a view per tenant (100K or 1M views or more - clearly too many
for HBase to handle as separate tables).
With secondary
Hi all,
I am writing to ask if there is a way to let Phoenix store all indexes on a
single table in the same HBase table. If each index must be stored in a
separate table, creating more than a few indexes on table with a large number
of regions will not scale well.
From what I have learned,
10 matches
Mail list logo