hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5311) Allow inmemory Memstore compactions
Date Wed, 08 Feb 2012 22:16:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204055#comment-13204055
] 

Todd Lipcon commented on HBASE-5311:
------------------------------------

bq. should 'state' be closed before being updated?

I don't think it matters from a correctness standpoint. If we close the old state before updating
the state variable, then all concurrent accessors beginning at this point will sit and spin
while any previously running accessors finish their work. If we set the new state first, then
any new accessors can immediately proceed so we don't cause any "hiccup" in access.

The semantics of this whole data structure are a little subtle though so we'll have to be
careful to expose only a minimal API and clearly document where we might have strange causality
relations, etc.
                
> Allow inmemory Memstore compactions
> -----------------------------------
>
>                 Key: HBASE-5311
>                 URL: https://issues.apache.org/jira/browse/HBASE-5311
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Lars Hofhansl
>         Attachments: InternallyLayeredMap.java
>
>
> Just like we periodically compact the StoreFiles we should also periodically compact
the MemStore.
> During these compactions we eliminate deleted cells, expired cells, cells to removed
because of version count, etc, before we even do a memstore flush.
> Besides the optimization that we could get from this, it should also allow us to remove
the special handling of ICV, Increment, and Append (all of which use upsert logic to avoid
accumulating excessive cells in the Memstore).
> Not targeting this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message