[
https://issues.apache.org/jira/browse/HBASE-12324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183518#comment-14183518
]
Vladimir Rodionov commented on HBASE-12324:
-------------------------------------------
[~ndimiduk]:
{quote}
What I'm hearing is that it could be interesting to be able to flag a table or
column family as "immutable". This combined with a TTL setting can allow for
significant compaction optimizations. Next steps would be to enable such a
configuration and write an integration test that demonstrates the benefit of
this configuration.
{quote}
Benefits:
* Constant sustained write rate which does not decreases over time. All DB
systems that do not update data in - place and relies on a compaction to merge
delete/updates suffer badly when data set size becomes larger and larger.
Sustained write rate decreases significantly over time (anti -logarithmically)
* A lot of optimizations can be done on a read path as well (no need to keep
track for deleted cell, for example)
> Improve compaction speed and process for immutable short lived datasets
> -----------------------------------------------------------------------
>
> Key: HBASE-12324
> URL: https://issues.apache.org/jira/browse/HBASE-12324
> Project: HBase
> Issue Type: New Feature
> Components: Compaction
> Affects Versions: 0.98.0, 0.96.0
> Reporter: Sheetal Dolas
> Attachments: OnlyDeleteExpiredFilesCompactionPolicy.java
>
>
> We have seen multiple cases where HBase is used to store immutable data and
> the data lives for short period of time (few days)
> On very high volume systems, major compactions become very costly and
> slowdown ingestion rates.
> In all such use cases (immutable data, high write rate and moderate read
> rates and shorter ttl), avoiding any compactions and just deleting old data
> brings lot of performance benefits.
> We should have a compaction policy that can only delete/archive files older
> than TTL and not compact any files.
> Also attaching a patch that can do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
