hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14920) Compacting Memstore
Date Tue, 29 Mar 2016 21:20:25 GMT

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

stack commented on HBASE-14920:


No need of these things...

445	    /*----------------------------------------------------------------------

no one else does this...

Oh... so we could let go of an edit because it was beyond max versions or something and then
you need to update the lowest outstanding sequenceid .... this thing?

465	          updateLowestUnflushedSequenceIdInWal(true); // only if greater

I'd never have thought to do that.

We are changing the flush policy on the user here?

944	        if(hasCompactingStore) {
945	          double alpha = FLUSH_SIZE_WEIGHT;
946	          this.memstoreFlushSize =
947	              (long)(alpha*memstoreFlushSize + (1-alpha)*blockingMemStoreSize);
948	          LOG.info("Increasing memstore flush size to "+memstoreFlushSize +" for the region="
949	              + this);
950	          htableDescriptor.setFlushPolicyClassName(FlushNonCompactingStoresFirstPolicy.class
951	              .getName());
952	        }

Thats not bad in-itself (just Release Note it as well as the fact that we are going to run
w/ more memory), but we are doing it by setting policy on the HTableDescriptor; every region
is going to do this? Can we do it on the region itself? Or can we get away w/o changing HTD?
 This is unusual practice.

Do you have to start your own? Can you not piggyback off the RS's existing Executor?

	1748	    this.service.startExecutorService(ExecutorType.RS_IN_MEMORY_FLUSH_AND_COMPACTION,
1749	        conf.getInt("hbase.regionserver.executor.inmemoryflush.threads", 3));

Do you need to add this one to RegionServicesFor...

56	  public HTableDescriptor getTableDesc() {
57	    return region.getTableDesc();
58	  }

Would be good if you could get away w/ not passing it down...

And this one...

68	  public RegionServerServices getRegionServerServices() {
69	    return region.getRegionServerServices();
70	  }

This onlyIfGreater was there before you?

168	  void updateStore(byte[] encodedRegionName, byte[] familyName, Long sequenceId,
169	      boolean onlyIfGreater) {

We should purge it? It is of little use?

TestCompactingMemStore is junit3 rather than junit4 because it parent is. I'll attach a patch
here that moves TestDefaultMemStore to junit4 so this test can be junit 4 too (We've been
trying to purge the old tests...)

I skimmed the tests. They look great.

Looks committable to me.

> Compacting Memstore
> -------------------
>                 Key: HBASE-14920
>                 URL: https://issues.apache.org/jira/browse/HBASE-14920
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Eshcar Hillel
>            Assignee: Eshcar Hillel
>         Attachments: HBASE-14920-V01.patch, HBASE-14920-V02.patch
> Implementation of a new compacting memstore with non-optimized immutable segment representation

This message was sent by Atlassian JIRA

View raw message