Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 24 Nov 2015 01:52:11 +0000 (UTC)
From: "Vladimir Rodionov (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12895998.1443070219000.169856.1448329931142@Atlassian.JIRA>
In-Reply-To: <JIRA.12895998.1443070219000@Atlassian.JIRA>
References: <JIRA.12895998.1443070219000@Atlassian.JIRA>
 <JIRA.12895998.1443070219655@arcas>
Subject: [jira] [Commented] (HBASE-14477) Compaction improvements: Date
 tiered compaction policy
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-14477?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D150=
23572#comment-15023572 ]=20

Vladimir Rodionov commented on HBASE-14477:
-------------------------------------------

[~davelatham]
{quote}
Do you have intent to backport to 1 or 0.98?
{quote}

Short answer is - yes.

> Compaction improvements: Date tiered compaction policy
> ------------------------------------------------------
>
>                 Key: HBASE-14477
>                 URL: https://issues.apache.org/jira/browse/HBASE-14477
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>             Fix For: 2.0.0
>
>
> For immutable and mostly immutable data the current SizeTiered-based comp=
action policy is not efficient.=20
> # There is no need to compact all files into one, because, data is (mostl=
y) immutable and we do not need to collect garbage. (performance reason wil=
l be discussed later)
> # Size-tiered compaction is not suitable for applications where most rece=
nt data is most important and prevents efficient caching of this data.=20
> The idea  is pretty similar to DateTieredCompaction in Cassandra:
> http://www.datastax.com/dev/blog/datetieredcompactionstrategy
> http://www.datastax.com/dev/blog/dtcs-notes-from-the-field
> From Cassandra own blog:
> {quote}
> Since DTCS can be used with any table, it is important to know when it is=
 a good idea, and when it is not. I=E2=80=99ll try to explain the spectrum =
and trade-offs here:
> 1. Perfect Fit: Time Series Fact Data, Deletes by Default TTL: When you i=
ngest fact data that is ordered in time, with no deletes or overwrites. Thi=
s is the standard =E2=80=9Ctime series=E2=80=9D use case.
> 2. OK Fit: Time-Ordered, with limited updates across whole data set, or o=
nly updates to recent data: When you ingest data that is (mostly) ordered i=
n time, but revise or delete a very small proportion of the overall data ac=
ross the whole timeline.
> 3. Not a Good Fit: many partial row updates or deletions over time: When =
you need to partially revise or delete fields for rows that you read togeth=
er. Also, when you revise or delete rows within clustered reads.
> {quote}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)