[jira] [Comment Edited] (HBASE-24749) Direct insert HFiles and Persist in-memory HFile tracking

["Tak-Lon (Stephen) Wu (Jira)" <ji...@apache.org>]

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

Tak-Lon (Stephen) Wu edited comment on HBASE-24749 at 7/21/20, 5:26 PM:
------------------------------------------------------------------------

Thanks [~busbey] and [~zhangduo] , I will send a email to dev@ list.
{quote}Could this be a part of meta instead?
{quote}
Definitively we can more them into meta table, and it shouldn't put too much load and data (about 400MB for 10k region). but [~zhangduo]  is right that, meta table itself still need to have something to store the tracking for the meta region(s). but other storing storefile tracking of metatable region in zookeeper, do you guys have other thoughts?


one additional thoughts on the meta table itself, do we need meta table to be splittable mentioned in HBASE-23055 ? basically we were thinking how much load meta table could handle, and we have yet gathered that information. 

 
{quote}But it is still a pain that we could see a HFile on the filesystem but we do not know whether it is valid... Check for trailer?
{quote}
For repairing and recovery, currently we're testing and reusing refresh hfiles coprocessor ({{RefreshHFilesClient}}) that relies on {{HStore#openStoreFiles}} to valid if the HFiles should be included (if the HFiles can be opened and/or it's a result from compaction). seem like that {{HStore#openStoreFiles}}  ({{initReader}}) already did that for checking the metadata ?
{quote}And we should provide new HBCK tools to sync the file system with the storefiles family, or rebuild the storefiles family from the filesystem?
{quote}
We can change that to be part of repairing meta table in HBCK such user do not need to run a separate command.


was (Author: taklwu):
Thanks [~busbey] and [~zhangduo] , I will send a email to dev@ list.

bq. Could this be a part of meta instead? 

Definitively we can more them into meta table, and it shouldn't put too much load and data (about 400MB for 10k region). but [~zhangduo]  is right that, meta table itself still need to have something to store the tracking for the meta region(s). but other storing storefile tracking of metatable region in zookeeper, do you guys have other thoughts? 

{quote}But it is still a pain that we could see a HFile on the filesystem but we do not know whether it is valid... Check for trailer?
{quote}
For repairing and recovery, currently we're testing and reusing refresh hfiles coprocessor ({{RefreshHFilesClient}}) that relies on {{HStore#openStoreFiles}} to valid if the HFiles should be included (if the HFiles can be opened and/or it's a result from compaction). seem like that {{HStore#openStoreFiles}}  ({{initReader}}) already did that for checking the metadata ? 

bq. And we should provide new HBCK tools to sync the file system with the storefiles family, or rebuild the storefiles family from the filesystem?

We can change that to be part of repairing meta table in HBCK such user do not need to run a separate command.

> Direct insert HFiles and Persist in-memory HFile tracking
> ---------------------------------------------------------
>
>                 Key: HBASE-24749
>                 URL: https://issues.apache.org/jira/browse/HBASE-24749
>             Project: HBase
>          Issue Type: Umbrella
>          Components: Compaction, HFile
>    Affects Versions: 3.0.0-alpha-1
>            Reporter: Tak-Lon (Stephen) Wu
>            Priority: Major
>              Labels: design, discussion, objectstore, storeFile, storeengine
>         Attachments: 1B100m-25m25m-performance.pdf, Apache HBase - Direct insert HFiles and Persist in-memory HFile tracking.pdf
>
>
> We propose a new feature (a new store engine) to remove the {{.tmp}} directory used in the commit stage for common HFile operations such as flush and compaction to improve the write throughput and latency on object stores. Specifically for S3 filesystems, this will also mitigate read-after-write inconsistencies caused by immediate HFiles validation after moving the HFile(s) to data directory.
> Please see attached for this proposal and the initial result captured with 25m (25m operations) and 1B (100m operations) YCSB workload A LOAD and RUN, and workload C RUN result.
> The goal of this JIRA is to discuss with the community if the proposed improvement on the object stores use case makes senses and if we miss anything should be included.
> Improvement Highlights
>  1. Lower write latency, especially the p99+
>  2. Higher write throughput on flush and compaction 
>  3. Lower MTTR on region (re)open or assignment 
>  4. Remove consistent check dependencies (e.g. DynamoDB) supported by file system imple



--
This message was sent by Atlassian Jira
(v8.3.4#803005)