date:20160421

submit Index populate Job to yarn cluster

2016-04-21 Thread 金砖


Async Index job http://phoenix.apache.org/secondary_indexing.html:

${HBASE_HOME}/bin/hbase org.apache.phoenix.mapreduce.index.IndexTool
  --schema MY_SCHEMA --data-table MY_TABLE --index-table ASYNC_IDX
  --output-path ASYNC_IDX_HFILES


How to submit that job to a yarn cluster ?

On a single Node with huge data, process will be killed in reduce stage.

Re: Getting swamped with Phoenix *.tmp files on SELECT.

2016-04-21 Thread marks1900-post01

Was unable to apply the PHOENIX-2556 patch 
(https://issues.apache.org/jira/secure/attachment/12780561/PHOENIX-2556.patch 
from https://issues.apache.org/jira/browse/PHOENIX-2556) as suggested.  As I am 
using a much older version of Phoenix (4.4 vs 4.7) there are quite a few 
conflicts.

Not sure when I will get the chance to spend more time on this.  In the 
meantime I have created a JIRA issue to track this:  
https://issues.apache.org/jira/browse/PHOENIX-2850
Maybe I can update these source files by hand.  What files do you want to 
updated and what changes do yo want made?
https://github.com/hortonworks/phoenix-release/blob/HDP-2.4.0.0-tag/phoenix-core


  From: Samarth Jain 
 To: "user@phoenix.apache.org" ; Maryann Xue 
 
 Sent: Thursday, 21 April 2016, 11:54
 Subject: Re: Getting swamped with Phoenix *.tmp files on SELECT.
   
My first suggestion would be to upgrade to the latest version of Phoenix which 
it doesn't seem like is possible in your case. Second would be to try applying 
the patch in PHOENIX-2556 and see if that solves the issue for you. If that 
doesn't work either, please file a JIRA and one of us will take a look at it.
- Samarth
On Wed, Apr 20, 2016 at 1:41 PM,  wrote:

So I did some debugging and found the code responsible for this *.tmp files 
being created.
https://github.com/hortonworks/phoenix-release/blob/HDP-2.4.0.0-tag/phoenix-core/src/main/java/org/apache/phoenix/iterate/MappedByteBufferQueue.java#L304
--org.apache.phoenix.iterate.MappedByteBufferQueue$MappedByteBufferSegmentQueue
--
private void flush(T entry) throws IOException {  Queue inMemQueue = 
getInMemoryQueue();  int resultSize = sizeOf(entry);  maxResultSize = 
Math.max(maxResultSize, resultSize);  totalResultSize = hasMaxQueueSize ? 
maxResultSize * inMemQueue.size() : (totalResultSize + resultSize);  if 
(totalResultSize >= thresholdBytes) {    this.file = 
File.createTempFile(UUID.randomUUID().toString(), null);    RandomAccessFile af 
= new RandomAccessFile(file, "rw");    FileChannel fc = af.getChannel();    int 
writeIndex = 0;    mappingSize = Math.min(Math.max(maxResultSize, 
DEFAULT_MAPPING_SIZE), totalResultSize);    MappedByteBuffer writeBuffer = 
fc.map(MapMode.READ_WRITE, writeIndex, mappingSize);
--

Is any fix or work-around, so that these temp files don't exhaust my free disk 
space?

  From: 
 To: "user@phoenix.apache.org" ;
 Sent: Tuesday, 19 April 2016, 12:00
 Subject: Re: Getting swamped with Phoenix *.tmp files on SELECT.
   
Would it be possible for you to upgrade to the latest version of Phoenix (4.7)? 
It is likely that this bug has been fixed in the latest release. One of the 
possibly related JIRA that was fixed in 4.7 is PHOENIX-2556. Although, Maryanne 
would be the best person to comment on this. 
Maryanne, would you mind taking a look?
On Mon, Apr 18, 2016 at 1:43 PM,  wrote:

I have narrowed this issue down to select statement below.  When I have 
iterated through the query results of this select statement, I do ensure that 
the JDBC close statements on my ResultSet, Statement and Connection are called.

For now, I am go with the suggested work-around and implement something like 
tmpwatch as a Java scheduled service.

Also, I think I found someone else who seems to be having this style of issue 
in Phoenix:  https://issues.apache.org/jira/browse/PHOENIX-1395

--
String sql =  "SELECT TR.ID"    + "  ,TR.CLIENT_ID"    + "  ,TR.BRAND_ID"    + 
"  ,TR.SITE_ID"    + "  ,TR.EMAIL"    + "  ,COUNT(TS2.ID) + 
MAX(TR.repeatBrandShortVisit) AS repeatBrandShortVisit"    + "  ,SUM(CASE WHEN 
TS2.SESSION_TYPE = 1 THEN 1 ELSE 0 END) + MAX(TR.repeatBrandLongVisit) AS 
repeatBrandLongVisit"    + "  ,SUM(CASE WHEN TS2.SITE_ID = TR.SITE_ID THEN 1 
ELSE 0 END) + MAX(TR.repeatSiteShortVisit) AS repeatSiteShortVisit"    + "  
,SUM(CASE WHEN TS2.SITE_ID = TR.SITE_ID AND TS2.SESSION_TYPE = 1 THEN 1 ELSE 0 
END) + MAX(TR.repeatSiteLongVisit) AS repeatSiteLongVisit"    + "  FROM ("    + 
"  SELECT TSE.ID"    + "      ,TSE.CLIENT_ID"    + "      ,TSE.BRAND_ID"    + " 
     ,TSE.SITE_ID"    + "      ,TSE.EMAIL"    + "      ,COUNT(TS1.ID) AS 
repeatBrandShortVisit"    + "      ,SUM(CASE WHEN TS1.SESSION_TYPE = 1 THEN 1 
ELSE 0 END) AS repeatBrandLongVisit"    + "      ,SUM(CASE WHEN TS1.SITE_ID = 
TSE.SITE_ID THEN 1 ELSE 0 END) AS repeatSiteShortVisit"    + "      ,SUM(CASE 
WHEN TS1.SITE_ID = TSE.SITE_ID AND TS1.SESSION_TYPE = 1 THEN 1 ELSE 0 END) AS 
repeatSiteLongVisit"    + "  FROM ("    + "      SELECT ID"    + "          
,CLIENT_ID"    + "          ,BRAND_ID"    + "          ,SITE_ID"    + "         
 ,EMAIL"    + "      FROM user.SESSION_EXPIRATION "    + "      WHERE 
NEXT_CHECK <= CURRENT_TIME()"    + "      LIMIT " + batchSize    + "      ) AS 
TSE"    + "  LEFT OUTER JOIN user.SESSION TS1"    + "      ON TS1.CLIENT_ID = 
TSE.CLIENT_ID"    + "      AND TS1.BRAND_ID = TSE.BRAND_ID"    + "  GROUP BY

Extract report from phoenix table

2016-04-21 Thread Sanooj Padmakumar

Hi

Is there a way using phoenix we can query a huge table to extract some
information from them ? The "where" condition will have "value" fields and
might not have any row key fields.

I am looking for something like a phoenix mapreduce (
https://phoenix.apache.org/phoenix_mr.html) but this always require the
output to be written to a table.

Any inputs ?

-- 
Thanks,
Sanooj Padmakumar

Re: Apache Phoenix + Wildfly (JEE)

2016-04-21 Thread James Taylor

Are you aware of the work being done to create shaded jars (PHOENIX-2535)?
This would be a good driver for that effort.
Thanks,
James

On Thu, Apr 21, 2016 at 8:43 AM,  wrote:

>
> It would be great if I could get some feedback on my current integration
> effort of Wildfly (JEE) and Apache Phoenix.
>
> While I managed to create a Wildfly datasource (
> https://docs.jboss.org/author/display/TEIID/Phoenix+Data+Sources), I
> moved to a Maven dependency for debugging purposes. Below is my working
> Maven dependency.
>
> Unfortunately, I could not use the standard Phoenix "-client.jar", as it
> caused many classpath and service conflict issues (Beware the
> META-INF/services folder inside the jar) with Wildfly.  Also the Maven
> configuration instructions given at
> https://phoenix.apache.org/building.html will also result in a lot of
> classpath issues in Wildfly.
>
>
> ** Please note I am using the following Hortanworks release, in my example
> below:
>
>
> https://github.com/hortonworks/phoenix-release/blob/HDP-2.4.0.0-tag/phoenix-core/pom.xml
>
>
> --
>
> 
>   ...
>   
> Apache releases
> https://repository.apache.org/content/repositories/releases/
> 
>   
>   
> Hortanworks releases
> http://repo.hortonworks.com/content/repositories/releases/
>   
>   
> Hortanworks public
> http://repo.hortonworks.com/content/groups/public/
>   
>   ...
> 
>
>
> 
>   ...
>   
> org.apache.phoenix
> phoenix-core
> 4.4.0-HBase-1.0
> compile
> 
>   
> org.mortbay.jetty
> *
>   
>   
> com.sun.jersey
> jersey-server
>   
>   
> com.sun.jersey
> jersey-guice
>   
>   
> javax.xml.bind
> jaxb-impl
>   
>   
> javax.xml.bind
> jaxb-api
>   
>   
> com.sun.jersey.contribs
> jersey-guice
>   
>   
> org.apache.hadoop
> hadoop-hdfs
>   
>   
> org.apache.hadoop
> hadoop-mapreduce-client-core
>   
>   
> org.apache.hadoop
> hadoop-mapreduce-client-app
>   
>   
> org.apache.hadoop
> hadoop-mapreduce-client-jobclient
>   
>   
> javax.*
> *
>   
>   
> tomcat
> *
>   
>   
> xml-apis
> xml-apis
>   
>   
> xerces
> xercesImpl
>   
>   
> guava
> com.google.guava
>   
>   
> httpclient
> org.apache.httpcomponents
>   
>   
> log4j
> log4j
>   
>   
> slf4j-api
> org.slf4j
>   
>   
> jsr305
> com.google.code.findbugs
>   
>   
> azure-storage
> com.microsoft.azure
>   
> 
>   
>   ...
> 
>
> --
>
>

Re: Getting swamped with Phoenix *.tmp files on SELECT.

2016-04-21 Thread Samarth Jain

My first suggestion would be to upgrade to the latest version of Phoenix
which it doesn't seem like is possible in your case. Second would be to try
applying the patch in PHOENIX-2556 and see if that solves the issue for
you. If that doesn't work either, please file a JIRA and one of us will
take a look at it.

- Samarth

On Wed, Apr 20, 2016 at 1:41 PM,  wrote:

> So I did some debugging and found the code responsible for this *.tmp
> files being created.
>
>
> https://github.com/hortonworks/phoenix-release/blob/HDP-2.4.0.0-tag/phoenix-core/src/main/java/org/apache/phoenix/iterate/MappedByteBufferQueue.java#L304
> 
>
> --
>
> org.apache.phoenix.iterate.MappedByteBufferQueue$MappedByteBufferSegmentQueue
> --
>
> private void flush(T entry) throws IOException {
>   Queue inMemQueue = getInMemoryQueue();
>   int resultSize = sizeOf(entry);
>   maxResultSize = Math.max(maxResultSize, resultSize);
>   totalResultSize = hasMaxQueueSize ? maxResultSize * inMemQueue.size() :
> (totalResultSize + resultSize);
>   if (totalResultSize >= thresholdBytes) {
> *this.file = File.createTempFile(UUID.randomUUID().toString(), null);*
> RandomAccessFile af = new RandomAccessFile(file, "rw");
> FileChannel fc = af.getChannel();
> int writeIndex = 0;
> mappingSize = Math.min(Math.max(maxResultSize, DEFAULT_MAPPING_SIZE),
> totalResultSize);
> MappedByteBuffer writeBuffer = fc.map(MapMode.READ_WRITE, writeIndex,
> mappingSize);
>
> --
>
> Is any fix or work-around, so that these temp files don't exhaust my free
> disk space?
>
>
> --
> *From:*
> *To:* "user@phoenix.apache.org" ;
> *Sent:* Tuesday, 19 April 2016, 12:00
>
> *Subject:* Re: Getting swamped with Phoenix *.tmp files on SELECT.
>
> Would it be possible for you to upgrade to the latest version of Phoenix
> (4.7)? It is likely that this bug has been fixed in the latest release. One
> of the possibly related JIRA that was fixed in 4.7 is PHOENIX-2556.
> Although, Maryanne would be the best person to comment on this.
>
> Maryanne, would you mind taking a look?
>
> On Mon, Apr 18, 2016 at 1:43 PM,  wrote:
>
> I have narrowed this issue down to select statement below.  When I have
> iterated through the query results of this select statement, I do ensure
> that the JDBC close statements on my ResultSet, Statement and Connection
> are called.
>
> For now, I am go with the suggested work-around and implement something
> like tmpwatch as a Java scheduled service.
>
> Also, I think I found someone else who seems to be having this style of
> issue in Phoenix:  https://issues.apache.org/jira/browse/PHOENIX-1395
>
> --
>
> String sql =
>   "SELECT TR.ID "
> + "  ,TR.CLIENT_ID"
> + "  ,TR.BRAND_ID"
> + "  ,TR.SITE_ID"
> + "  ,TR.EMAIL"
> + "  ,COUNT(TS2.ID ) + MAX(TR.repeatBrandShortVisit)
> AS repeatBrandShortVisit"
> + "  ,SUM(CASE WHEN TS2.SESSION_TYPE = 1 THEN 1 ELSE 0 END) +
> MAX(TR.repeatBrandLongVisit) AS repeatBrandLongVisit"
> + "  ,SUM(CASE WHEN TS2.SITE_ID = TR.SITE_ID THEN 1 ELSE 0 END) +
> MAX(TR.repeatSiteShortVisit) AS repeatSiteShortVisit"
> + "  ,SUM(CASE WHEN TS2.SITE_ID = TR.SITE_ID AND TS2.SESSION_TYPE = 1
> THEN 1 ELSE 0 END) + MAX(TR.repeatSiteLongVisit) AS repeatSiteLongVisit"
> + "  FROM ("
> + "  SELECT TSE.ID "
> + "  ,TSE.CLIENT_ID"
> + "  ,TSE.BRAND_ID"
> + "  ,TSE.SITE_ID"
> + "  ,TSE.EMAIL"
> + "  ,COUNT(TS1.ID ) AS repeatBrandShortVisit"
> + "  ,SUM(CASE WHEN TS1.SESSION_TYPE = 1 THEN 1 ELSE 0 END) AS
> repeatBrandLongVisit"
> + "  ,SUM(CASE WHEN TS1.SITE_ID = TSE.SITE_ID THEN 1 ELSE 0 END)
> AS repeatSiteShortVisit"
> + "  ,SUM(CASE WHEN TS1.SITE_ID = TSE.SITE_ID AND TS1.SESSION_TYPE
> = 1 THEN 1 ELSE 0 END) AS repeatSiteLongVisit"
> + "  FROM ("
> + "  SELECT ID"
> + "  ,CLIENT_ID"
> + "  ,BRAND_ID"
> + "  ,SITE_ID"
> + "  ,EMAIL"
> + "  FROM user.SESSION_EXPIRATION "
> + "  WHERE NEXT_CHECK <= CURRENT_TIME()"
> + "  LIMIT " + batchSize
> + "  ) AS TSE"
> + "  LEFT OUTER JOIN user.SESSION TS1"
> + "  ON TS1.CLIENT_ID = TSE.CLIENT_ID"
> + "  AND TS1.BRAND_ID = TSE.BRAND_ID"
> + "  GROUP BY TSE.ID "
> + "  ,TSE.CLIENT_ID"
> + "  ,TSE.BRAND_ID"
> + "  ,TSE.SITE_ID"
> + "  ,TSE.EMAIL"
> + "  ) AS TR"
> + "  LEFT OUTER JOIN user.SESSION TS2"
> + "  ON TS2.EMAIL = TR.EMAIL"
> + "  AND TS2.BRAND_ID = TR.BRAND_ID"
> + "  GROUP BY TR.ID "
> + "  ,TR.CLIENT_ID"
> + "  ,TR.BRAND_ID"
> + "

does secondary index works on view on hbase ?

2016-04-21 Thread 金砖


1. I have hbase table:
hbase shell: create 'table', 'cf'

2. then create view on that
   phoenix: create view "table" (pk varchar primary key, "cf"."field" 
varchar);


3. create index on view
phoenix:  create index idx on "table" ("cf"."field");

 IDX created in phoenix, and I can select from IDX:
select "*" from IDX where "cf:field" = '';

It's pretty fast, and it works.

But when using this:
select * from "table" where "cf"."field" = 'xxx';
or this:
select /*+ INDEX("table" IDX) */ * from "table" where "cf"."field" 
= 'xxx';


The index doesn't work, can anyone help out ?

question about populating async index table

2016-04-21 Thread 金砖


hi, I read from document that index can be created asynchronously.

After create index with ASYNC keyword, then kick off a MapReduce Job to 
pupulate index.


${HBASE_HOME}/bin/hbase org.apache.phoenix.mapreduce.index.IndexTool
  --schema MY_SCHEMA --data-table MY_TABLE --index-table ASYNC_IDX
  --output-path ASYNC_IDX_HFILES


My question:
Can value of --output-path (as is ASYNC_IDX_HFILES)  be wherever hdfs ?
OR must it match or must not match where hbase table path in hdfs ?

Re: Undefined column. columnName=IS_ROW_TIMESTAMP

2016-04-21 Thread Ankit Singhal

Arun,
the observations you had is understandable.
So, that's why we again requested the output of

*echo "scan 'SYSTEM.CATALOG',{RAW=>true}"|bin/hbase shell|grep CATALOG*

So that we can help you in adding ROW_TIMESTAMP column in system.catalog
table so that your phoenix setup works properly and you can also see it in
!describe command.






On Thu, Apr 21, 2016 at 4:20 AM, Arun Kumaran Sabtharishi <
arun1...@gmail.com> wrote:

> Another observation:(After upgrading from Phoenix 4.4 to 4.6.1)
>
> In a new SYSTEM.CATALOG table , when connected from phoenix 4.6.1 client,
>
> !describe SYSTEM.CATALOG does not show IS_ROW_TIMESTAMP
>
> But, select * from SYSTEM.CATALOG shows the IS_ROW_TIMESTAMP column.
>
> Is this an expected behavior?
>
> If I have to see IS_ROW_TIMESTAMP when doing describe, what should I do?
> This issue is blocking us in the production environment. Any help to
> resolve or workaround is highly appreciated.
>
> Thanks,
> Arun
>
>
> On Wed, Apr 20, 2016 at 12:01 PM, Ankit Singhal 
> wrote:
>
>> It's ok if you can just post after grep for CATALOG in a command output (scan
>> 'SYSTEM.CATALOG', {RAW=>true}).
>>
>> On Wed, Apr 20, 2016 at 10:07 PM, Arun Kumaran Sabtharishi <
>> arun1...@gmail.com> wrote:
>>
>>> One more question to add,
>>> Do we need to have 1000 versions, and KEEP_DELETED_CELL=true?
>>>
>>> I have limited the scan in HBase and here is the following data.
>>>
>>> \x00\x00TEST_TABLE_2 column=0:, timestamp=1460455162842,
>>> type=DeleteFamily
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:BASE_COLUMN_COUNT,
>>> timestamp=1460354090655, value=\x7F\xFF\xFF\xFF
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:COLUMN_COUNT, timestamp=1460354090655,
>>> value=\x80\x00\x00\x05
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:DATA_TABLE_NAME, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:DEFAULT_COLUMN_FAMILY,
>>> timestamp=1460354090655, value=default
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:DISABLE_WAL, timestamp=1460354090655,
>>> value=\x00
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:IMMUTABLE_ROWS, timestamp=1460354090655,
>>> value=\x00
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:INDEX_STATE, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:INDEX_TYPE, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:MULTI_TENANT, timestamp=1460354090655,
>>> value=\x00
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:PK_NAME, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:ROW_KEY_ORDER_OPTIMIZABLE,
>>> timestamp=1460354090655, value=\x01
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:SALT_BUCKETS, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:STORE_NULLS, timestamp=1460354090655,
>>> value=\x00
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:TABLE_SEQ_NUM, timestamp=1460354090655,
>>> value=\x80\x00\x00\x00\x00\x00\x00\x00
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:TABLE_TYPE, timestamp=1460354090655,
>>> value=u
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:VIEW_INDEX_ID, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:VIEW_STATEMENT, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:VIEW_TYPE, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:_0, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089
>>>
>>> \x00\x00TEST_TABLE_2 column=0:, timestamp=1460455162842,
>>> type=DeleteFamily
>>>
>>> _0_1460354090089\x00CDS_CLIENT_CORELATION_ID\
>>>
>>> x00default
>>>
>>> \x00\x00TEST_TABLE_2 column=0:ARRAY_SIZE, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089\x00CDS_CLIENT_CORELATION_ID\
>>>
>>> x00default
>>>
>>> \x00\x00TEST_TABLE_2 column=0:COLUMN_DEF, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089\x00CDS_CLIENT_CORELATION_ID\
>>>
>>> x00default
>>>
>>> \x00\x00TEST_TABLE_2 column=0:COLUMN_SIZE, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089\x00CDS_CLIENT_CORELATION_ID\
>>>
>>> x00default
>>>
>>> \x00\x00TEST_TABLE_2 column=0:DATA_TABLE_NAME, timestamp=1460354090655,
>>> type=DeleteColumn
>>>
>>> _0_1460354090089\x00CDS_CLIENT_CORELATION_ID\
>>>
>>> x00default
>>>
>>> \x00\x00TEST_TABLE_2 column=0:DATA_TYPE, timestamp=1460354090655,
>>> value=\x80\x00\x00\x0C
>>>
>>> _0_1460354090089\x00CDS_CLIENT_CORELATION_ID\
>>>
>>> x00default
>>>
>>> \x00\x00TEST_TABLE_2 column=0:DECIMAL_DIGITS, timestamp=1460354090655,
>>>

Re: apache phoenix json api

2016-04-21 Thread Plamen Paskov


Hi Francis,
Thank you for supporting me ! I appreciate that!
Below are the commands i executed and the respective responses. As you 
will see the new data is missing.

And these are the details about my setup:

OS: Ubuntu 14.04.3 LTS
hbase: Version 1.1.2.2.3.4.0-3485
phoenix: Version 4.4.0.2.3.4.0-3485


curl -XPOST 52.31.63.96:8765 -d '{"request": "openConnection", 
"connectionId": "12"}'


response:
{
  "response": "openConnection",
  "rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "ip-172-31-27-198:8765"
  }
}


curl -XPOST 52.31.63.96:8765 -d '{"request": "createStatement", 
"connectionId": "12"}'


response:
{
  "response": "createStatement",
  "connectionId": "12",
  "statementId": 28,
  "rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "ip-172-31-27-198:8765"
  }
}


curl -XPOST 52.31.63.96:8765 --data @data.json

data.json content
{
  "request": "prepareAndExecute",
  "connectionId": "12",
  "statementId": 28,
  "sql": "UPSERT INTO us_population VALUES('CA','Bla bla',10)",
  "maxRowCount": -1
}

response:
{
  "response": "executeResults",
  "missingStatement": false,
  "rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "ip-172-31-27-198:8765"
  },
  "results": [
{
  "response": "resultSet",
  "connectionId": "12",
  "statementId": 28,
  "ownStatement": false,
  "signature": null,
  "firstFrame": null,
  "updateCount": 1,
  "rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "ip-172-31-27-198:8765"
  }
}
  ]
}


curl -XPOST 52.31.63.96:8765 -d '{"request": "commit", "connectionId": 
"12"}'


response:
{
  "response": "resultSet",
  "connectionId": "12",
  "statementId": 29,
  "ownStatement": true,
  "signature": {
"columns": [
  {
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "TABLE_SCHEM",
"columnName": "TABLE_SCHEM",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "SYSTEM.TABLE",
"catalogName": "",
"type": {
  "type": "scalar",
  "id": 12,
  "name": "VARCHAR",
  "rep": "STRING"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.String"
  },
  {
"ordinal": 1,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 1,
"signed": false,
"displaySize": 40,
"label": "TABLE_CATALOG",
"columnName": "TABLE_CATALOG",
"schemaName": "",
"precision": 0,
"scale": 0,
"tableName": "SYSTEM.TABLE",
"catalogName": "",
"type": {
  "type": "scalar",
  "id": 12,
  "name": "VARCHAR",
  "rep": "STRING"
},
"readOnly": true,
"writable": false,
"definitelyWritable": false,
"columnClassName": "java.lang.String"
  }
],
"sql": null,
"parameters": [],
"cursorFactory": {
  "style": "LIST",
  "clazz": null,
  "fieldNames": null
},
"statementType": null
  },
  "firstFrame": {
"offset": 0,
"done": true,
"rows": [
  [
null,
null
  ],
  [
"SYSTEM",
null
  ]
]
  },
  "updateCount": -1,
  "rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "ip-172-31-27-198:8765"
  }
}


curl -XPOST 52.31.63.96:8765 -d '{"request": "prepareAndExecute", 
"connectionId": "12", "statementId": 28, "sql": "SELECT * FROM 
us_population","maxRowCount": -1}'


{
  "response": "executeResults",
  "missingStatement": false,
  "rpcMetadata": {
"response": "rpcMetadata",
"serverAddress": "ip-172-31-27-198:8765"
  },
  "results": [
{
  "response": "resultSet",
  "connectionId": "12",
  "statementId": 28,
  "ownStatement": true,
  "signature": {
"columns": [
  {
"ordinal": 0,
"autoIncrement": false,
"caseSensitive": false,
"searchable": true,
"currency": false,
"nullable": 0,
"signed": false,
"displaySize": 2,
"label": "STATE",
"columnName": "STATE",
"schemaName": "",
"precision": 2,
"scale": 0,
"tableName": "US_POPULATION",
"catalogName": "",
"type": {
  "type": "scalar",
  "id": 1,
  "name": "CHAR",
  "rep": "STRING"
},
"readOnly":

submit Index populate Job to yarn cluster

Re: Getting swamped with Phoenix *.tmp files on SELECT.

Extract report from phoenix table

Re: Apache Phoenix + Wildfly (JEE)

Re: Getting swamped with Phoenix *.tmp files on SELECT.

does secondary index works on view on hbase ?

question about populating async index table

Re: Undefined column. columnName=IS_ROW_TIMESTAMP

Re: apache phoenix json api

9 matches

Site Navigation

Mail list logo

Footer information