Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Wed, 6 May 2015 21:00:00 +0000 (UTC)
From: "Zhijie Shen (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12772276.1423033308000.28696.1430946000951@Atlassian.JIRA>
In-Reply-To: <JIRA.12772276.1423033308000@Atlassian.JIRA>
References: <JIRA.12772276.1423033308000@Atlassian.JIRA>
 <JIRA.12772276.1423033308851@arcas>
Subject: [jira] [Commented] (YARN-3134) [Storage implementation] Exploiting
 the option of using Phoenix to access HBase backend
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Zhijie Shen commented on YARN-3134:
-----------------------------------

Some more comments:

1. Maybe it's better to commit the batch per entity. Otherwise, if one entity has some I/O error, all entities in this write call will be failed?
{code}
186	        storeMetrics(entity, currContext, conn);
187	      }
188	      ps.executeBatch();
189	      conn.commit();
{code}

2. stmt doesn't need to be closed explicitly, but conn still does, right?
{code}
277	      conn.commit();
278	    } catch (SQLException se) {
279	      LOG.error("Failed in init data " + se.getLocalizedMessage());
280	      throw se;
281	    }
{code}

3. Many of PhoenixTimelineWriterImpl private functions can be static.

bq. except for two points

I'm okay if we want to defer it as the future stabilization work.

> [Storage implementation] Exploiting the option of using Phoenix to access HBase backend
> ---------------------------------------------------------------------------------------
>
>                 Key: YARN-3134
>                 URL: https://issues.apache.org/jira/browse/YARN-3134
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Li Lu
>              Labels: BB2015-05-TBR
>         Attachments: SettingupPhoenixstorageforatimelinev2end-to-endtest.pdf, YARN-3134-040915_poc.patch, YARN-3134-041015_poc.patch, YARN-3134-041415_poc.patch, YARN-3134-042115.patch, YARN-3134-042715.patch, YARN-3134-YARN-2928.001.patch, YARN-3134-YARN-2928.002.patch, YARN-3134-YARN-2928.003.patch, YARN-3134-YARN-2928.004.patch, YARN-3134DataSchema.pdf
>
>
> Quote the introduction on Phoenix web page:
> {code}
> Apache Phoenix is a relational database layer over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Apache Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows.
> {code}
> It may simply our implementation read/write data from/to HBase, and can easily build index and compose complex query.


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