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

Li Lu commented on YARN-3134:
-----------------------------

I've updated the patch according to latest comments. I addressed the concurrent 
modification problem by eliminating the connection cache (address separately in 
YARN-3595).

Other modifications:
bq. This is not necessary given YARN-3562 is already get in. Can you remove it?
It's a mistake. Removed. 

bq. Two spaces here, omit one.
Fixed.

bq. We should put the String as type to ColumnFamilyInfo, the same case as 
getInfo(), getIsRelatedToEntities() and getRelatesToEntities(), etc
Improved ColumnFamilyInfo so that it contains type information. Renamed it to 
DynamicColumns to better reflect its function. 

bq. we are duplicated calling entity.getConfigs().keySet() twice which should 
be avoid
While I believe modern compilers will remove this kind of redundancies, I've 
added local variables to make this explicit. This may bring in some register 
level advantages but it depends on language implementation and runtime system. 

bq. Looks like we are adding column families here rather than columns. May be 
we should rename it to appendColumnFamiliesToSQL?
We are adding dynamic columns in the same column family here. I think the name 
ColumnFamilyInfo is misleading here so I changed it, instead of this. 

bq. For setStringsForColumnFamily() and setBytesForColumnFamily(), it looks 
like most code there is duplicated, can we consolidate into one method?
bq. Document this is only for test.
Fixed. 



> [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
>         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-3134-YARN-2928.005.patch, YARN-3134-YARN-2928.006.patch, 
> YARN-3134-YARN-2928.007.patch, YARN-3134DataSchema.pdf, 
> hadoop-zshen-nodemanager-d-128-95-184-84.dhcp4.washington.edu.out
>
>
> 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)

Reply via email to