[
https://issues.apache.org/jira/browse/YARN-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529377#comment-14529377
]
Li Lu commented on YARN-3134:
-----------------------------
Thanks [~zjshen]! I'm addressing your comments. Meanwhile, I think there are
some points that I'd like to discuss:
bq. How do we chose the size and the expiry time?
Oh, thanks for reminding that! Currently I just set some placeholders for
frequent accesses (10 seconds clean up time) and medium concurrency (16
threads). We may want to tune this case-by-case in the future.
bq. If we use try with resources, do we still need to close stmt? Shall we
close them in finally block?
I believe this is why we need try-with-resource statements. See
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
bq. So why name and version should be combined and put it the same cell, but
not be separated?
I've also noticed the HBase implementation and the Phoenix implementation use
those two fields in different ways (the Hbase implementation is not using the
version field, if I understand correctly). How do we want to use the version
field? I was trying to use it as a part of the id to uniquely locate one "flow
run"
bq. Does phoenix support numeric/decimal? Not sure if we should store the
numbers in these types?
Phoenix supports concrete number types such as INTEGER, BIGINT, SMALLINT,
FLOAT, DOUBLE, etc, but nothing is directly mapped to lang.Number.
> [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-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)
