Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
PHOENIX-4278 changed index maintenance for transactional tables to be performed on the client side. For local indexes, this is not ideal and not really necessary as the updates to the indexes will all be local. By doing this on the client side, we'd incur extra overhead:
- extra RPCs for updates to local index tables separate from RPCs for data tables
- related to this, more network bandwidth would be used
- calculation on client-side to determine region start key (which is someone unclear whether there's a race condition with a split occurring while this is being determined)
- the updates to local indexes would no longer be row-level atomic with data table HBase updates (though they'd be atomic because they're transactional)
With Tephra, we can do the index maintenance on the server side without further changes. For Omid, it's more difficult since we must:
- perform all writes
- write to the commit table
- write the shadow cells (which requires knowing the index updates)
If there will already be an API to write the shadow cells (required for the initial population of local indexes), then perhaps we could piggyback on that. On the client-side, we could do the following:
- perform all writes
- write to the commit table
- perform writes again, but with a flag set to indicate that only the shadow cells need to be written (note we already have the mutation.setAttribute(REPLAY_WRITES, REPLAY_ONLY_INDEX_WRITES) option that will help with this) . In this case, we'd execute the logic to compute the index updates twice, but on the plus side, we wouldn't incur the other overhead mentioned before.
All in all, it's unclear if this is worth doing. It doesn't make a lot of sense to use local indexes for transactional tables, since one of the biggest benefits of local indexes is row level atomicity between index and table rows is already achieved more generally by transactions.