apache
PHOENIX-4906 Introduce a master coprocessor to handle cases where merging regions of salted table might cause an issue
I suggest using a more generic name, like PhoenixMasterObserver.
This will make our lives easier if we ever need to add more features to it.
@stoty i have changed the names accordingly. Please review when you get some cycles.
Also, since this is a broad topic, perhaps we could split this feature into its separate JIRA ?
I am mostly positive about this change but need help in two things
- How can we check if a table is a phoenix table or not?
- How do we want to add this coprocessor to system? Through hbase-site config(
hbase.coprocessor.master.classes) or through phoenix code (i am not aware of this path) ?
@virajjasani @kadirozde @apurtell @stoty Looking forward for your suggestions
I think using something like org.apache.phoenix.util.PhoenixRuntime.getTable(Connection, String)is the easiest (and perhaps fastest). PTable also tells us if the table is salted.
As for the processor, I could not find a way to load from code, it has to be configured manually. Phoenix already has a similar requirement for the old indexing's WAL Codec, so while not ideal, it's not a problem.
Few questions @mnpoonia
- Shouldn't this be handled in HBase purely instead of involving Phoenix, as I understand salting is an HBase feature?
A couple of questions if Phoenix needs to be involved 2. Shouldn't there be some checks if the Phoenix subsystem is present or not? 3. What are the implications on dependency management (since there is a tight coupling here between HBase master services and phoenix) during upgrades and maintenance?
@virajjasani @apurtell your thoughts?
Salting is not an HBase feature, it's a Phoenix feature (at least as used by Phoenix).
Ideally, HBase had a MergePolicy mechanism simliar to the SplitPolicy mechanism where we could add this logic per table, but it doesn't. Even if we were to add it, it wouldn't be available before 2.6 or even later.
I admit I that I have never really tracked down why we have this merging restriction, but it seems to be a performance optimization.
Salting is not an HBase feature, it's a Phoenix feature (at least as used by Phoenix).
@stoty I referring to what was explained here in the hot-spotting section of the hbase book. I think Phoenix just facilitates this under the cover for the user.
What I was asking is shouldn't we be seeing this issue in a purely HBase table with row keys distributed with salt prefixes?
I also think we should investigate more why the scanRanges are behaving such. Will try and dig more.
Yes, the problem is caused by this assumption built into the Phoenix implementation. If we could remove that without hurting performance, that would be brilliant. Thank you for digging into it.
@stoty I referring to what was explained here in the hot-spotting section of the hbase book. I think Phoenix just facilitates this under the cover for the user.
What I was asking is shouldn't we be seeing this issue in a purely HBase table with row keys distributed with salt prefixes?
@jpisaac I am not sure but my understanding is that hbase doesnot have a concept of salting. Clients can use salting to reduce the hotpostitng but then it is upto clients that how they want to manage all aspects of it. HBase doesn't care about salting in case of split or merge.
In phoenix we have this limitation that every row in a single region should have same salt. If we mix(merge) two regions of different salts phoenix scans starting behaving weird.