Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 16 Nov 2016 02:26:58 +0000 (UTC)
From: "Mingliang Liu (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12994118.1470096079000.288337.1479263218632@Atlassian.JIRA>
In-Reply-To: <JIRA.12994118.1470096079000@Atlassian.JIRA>
References: <JIRA.12994118.1470096079000@Atlassian.JIRA> <JIRA.12994118.1470096079825@arcas>
Subject: [jira] [Commented] (HADOOP-13449) S3Guard: Implement
 DynamoDBMetadataStore.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 16 Nov 2016 02:27:00 -0000


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

Mingliang Liu commented on HADOOP-13449:
----------------------------------------

Thanks for the ideas. Now we're getting close to the depth.

{quote}
The client has to check S3.
{quote}
I see the difference that we have now. After import, I was treating the DDB as the consistent store and authoritative by default. Suppose we have /a, /a/b, /a/c, for delete operations, we delete /a/ first; if other thread/process comes to list /a, it returns null (because /a is not there) indicating the subtree does not exist, though /a/b/ and /a/c/ are there. We may need to cover corner cases. Another question is that, if another process bypasses S3Guard and puts a new entry to /a/d/, do we have to make sure /a/d be added to the store by checking S3? I was thinking not; S3Guard guards those who buy it.

My previous thoughts: scan was not acceptable. If we should use scan; we have to redesign the DDB schema. Creating the parent path while creating the child is not efficient; for putting X files in the same directory, we don't want to check X times ancestors which bring heavy overhead. For empty directories, I didn't have to go to S3 as we may need time to get latest state. There must be feasible solutions/workarounds for DDBMetadataStore implementation if we agree on the list contract; I'll post my ideas later.

Now I have to think about the difference on the "contract" for list. As to the concern of not strictly having parent directories pre-created, is importing the only one? Cluster not being started is OK; DDB persists the data. We can import data via tools (e.g. command line) first on Day 1.

> S3Guard: Implement DynamoDBMetadataStore.
> -----------------------------------------
>
>                 Key: HADOOP-13449
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13449
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>            Reporter: Chris Nauroth
>            Assignee: Mingliang Liu
>         Attachments: HADOOP-13449-HADOOP-13345.000.patch, HADOOP-13449-HADOOP-13345.001.patch, HADOOP-13449-HADOOP-13345.002.patch, HADOOP-13449-HADOOP-13345.003.patch, HADOOP-13449-HADOOP-13345.004.patch
>
>
> Provide an implementation of the metadata store backed by DynamoDB.


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

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org