You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Gabriel Reid (JIRA)" <ji...@apache.org> on 2014/03/16 08:21:09 UTC

[jira] [Resolved] (PHOENIX-566) Speeding up mutable index performance

     [ https://issues.apache.org/jira/browse/PHOENIX-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gabriel Reid resolved PHOENIX-566.
----------------------------------

    Resolution: Fixed

Bulk resolve of closed issues imported from GitHub. This status was reached by first re-opening all closed imported issues and then resolving them in bulk.

> Speeding up mutable index performance
> -------------------------------------
>
>                 Key: PHOENIX-566
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-566
>             Project: Phoenix
>          Issue Type: Task
>            Reporter: Jason Yates
>
> Did the testing for the fixes on local box - running DFS and HBase w/ HBase managed ZK. First two commits fix the biggest issue, multiple repeats of the same index update for all Put/Delete in the batch. this comes about b/c the HBase CP hooks pass the same WAL on the postPut/Delete hook, causing the same index writes as we deserialize from that WAL. Fixed by checking the first IndexedKV for a batchComplete flag and skipping it if we don't need it. This is essentially a bug fix to bring the time back down from expoential (n^n) to linear.
> Next two are more minor speedups.
> (1) Writing before used to batch based on a single update to the target table. Now we group all the index updates by the target table and then write those as a single batch. ~200-300ms speedup for 500 rows
> (2) ExposedMemstore was using the MemSlab which copied the passed KVs to the MemSLAB on calls to _add. We don't care about the underlying bytes as we just can use what we get from the cache (and the expectation that its short-lived means GC isn't an issue). ~100-200ms speedup for 500 rows



--
This message was sent by Atlassian JIRA
(v6.2#6252)