hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13260) Bootstrap Tables for fun and profit
Date Wed, 22 Apr 2015 00:52:59 GMT

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

Enis Soztutar commented on HBASE-13260:

bq. try to pass 50 as the WAL threads number (there is just 1 thread in the wal)
Let me try that. 
bq. but still, I don't think the focus should be comparison on write perf 
write perf comes into picture in case we will do assignments using procedures. In case of
100K/1M region clusters, we do not want to be bottlenecked by the proc store. 
bq. can we throw away the logs when we remove everything from the memstore?
I am not sure I follow. Rolling the WAL is a very heavyweight operation. We should not roll
the WAL everytime there is no more procedure references. We already have the region mechanics
to optimize the WAL rolls vs flushes. We also have the periodic flushes to help with recovery
(although the patch does not contain periodic flusher yet).  
bq. can we avoid the delete markers and similar.
I think this would be a bigger change. We want if memstore contains it remove, otherwise put
a tombstone to optimize empty flushes (for this logic). Regardless of this, do you think flushes
and compactions will be a perf problem? As I comment above, every time a flush happens, we
will get rid of the WALs using the regular seqId tracking. Better yet, on graceful shutdown,
we will not do any replay, since everything is flushed and WAL files already archived. 

One of the goals for this patch is not to just replace proc store, but have this as a general
service for other use cases (storing cluster membership, RS groups, etc). The motivation is
to also not have yet another WAL format. In case we do not want the rest of HRegion, I think
we should at least use FSHLog as the proc wal store. 

> Bootstrap Tables for fun and profit 
> ------------------------------------
>                 Key: HBASE-13260
>                 URL: https://issues.apache.org/jira/browse/HBASE-13260
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 2.0.0, 1.1.0
>         Attachments: hbase-13260_bench.patch, hbase-13260_prototype.patch
> Over at the ProcV2 discussions(HBASE-12439) and elsewhere I was mentioning an idea where
we may want to use regular old regions to store/persist some data needed for HBase master
to operate. 
> We regularly use system tables for storing system data. acl, meta, namespace, quota are
some examples. We also store the table state in meta now. Some data is persisted in zk only
(replication peers and replication state, etc). We are moving away from zk as a permanent
storage. As any self-respecting database does, we should store almost all of our data in HBase
> However, we have an "availability" dependency between different kinds of data. For example
all system tables need meta to be assigned first. All master operations need ns table to be
assigned, etc. 
> For at least two types of data, (1) procedure v2 states, (2) RS groups in HBASE-6721
we cannot depend on meta being assigned since "assignment" itself will depend on accessing
this data. The solution in (1) is to implement a custom WAL format, and custom recover lease
and WAL recovery. The solution in (2) is to have the table to store this data, but also cache
it in zk for bootrapping initial assignments. 
> For solving both of the above (and possible future use cases if any), I propose we add
a "boostrap table" concept, which is: 
>  - A set of predefined tables hosted in a separate dir in HDFS. 
>  - A table is only 1 region, not splittable 
>  - Not assigned through regular assignment 
>  - Hosted only on 1 server (typically master)
>  - Has a dedicated WAL. 
>  - A service does WAL recovery + fencing for these tables. 
> This has the benefit of using a region to keep the data, but frees us to re-implement
caching and we can use the same WAL / Memstore / Recovery mechanisms that are battle-tested.


This message was sent by Atlassian JIRA

View raw message