Thanks James for replying.
The below example is really a smart way to map dynamic columns into static
ones. I will implement the idea in another case.
But I can not create these views at schema creation time and I really have an
infinite set of values for event_type.
Keeping a column for all
Hi Sumanta,
Another alternative option is to leverage support for VIEWs in Phoenix (
http://phoenix.apache.org/views.html). In many use cases I've seen where
there are hundreds of sparse columns defined for a schema, there's a column
that determines *which* sparse columns are applicable for a
Hi Siddharth,
I havent used Phoenix with Storm but I have used HBase with Storm.
IMHO, it should be fairly simple to write your own connector(code in
Spout/Bolt) to talk with Phoenix. It should mostly be same code that you
use in standalone Phoenix java app.
Thanks,
Anil Gupta
On Tue, Jan 6,
Hi,
spark-phoenix integration would be great as Spark community is greately active
now and more
and more developers are using Apache Spark.
Thanks,
Sun.
From: James Taylor
Date: 2015-01-07 16:10
To: su...@certusnet.com.cn
Subject: Re: Fwd: Phoenix in production
This is great, Sun! Thank
We have been using Phoenix 2.2.3 in production for about a year and I agree
with the previous comments.
- Mainly a storage for temporal OLAP-like data in single tables without
secondary indexes.
- Data ingested via pig on hourly basis.
- Heavy usage of composite primary keys using skip-scans
Hi,
Glad to share our experience of using Phoenix in Production. I believe that
Siddharth had done
sufficient tests and practices about Phoenix performance. Here are some tips
about how we are using
Phoenix for our projects:
1. We facilitate Phoenix to give convinience for both RD and QA
Inline.
On Tue, Jan 6, 2015 at 11:54 PM, Justin Workman justinjwork...@gmail.com
wrote:
I am also using Phoenix in production and have been now for roughly 6
months. We adopted Phoenix for most of the same reasons Anil mentions.
We are connection to a secure cluster without issue. We have
Hi Anil,
Well, there are already good opensouce project on github for Spark on HBase,
like the following:
https://github.com/cloudera-labs/SparkOnHBase
Phoenix integration shall be more convenient based on that. Considering to
share our code for using
that schema.
Thanks,
Sun.
CertusNet
Hi Noam,
It doesn't sound all that surprising that you're CPU bound on a batch
import job like this if you consider everything that is going on
within the mappers.
Let's say you're importing data for a table with 20 columns. For each
line of input data, the following is then occurring within the
Is the CPU usage 100% all the time OR only while doing bulk loading?
From: Bulvik, Noam [mailto:noam.bul...@teoco.com]
Sent: Wednesday, January 07, 2015 6:26 PM
To: user@phoenix.apache.org
Subject: high CPU when using bulk loading
Hi,
We are tuning our system for bulk loading. We managed to
what kind of disc using , sas or sata ? how much cpu for system /user?
also can using jstack to check what is the map are doing ?
whether too much map stared in one node?
Wangwenli
From: Bulvik, Noammailto:noam.bul...@teoco.com
Date: 2015-01-07 21:29
To:
Thanks for sharing your experiences,Vaclav. That's very valuable.
Yes, for (1) bad things can happen if a region server doesn't have the
Phoenix jar. This was improved as of HBase 0.98.9 with HBASE-12573 and
HBASE-12575. For (3), this was fixed as of Phoenix 3.1/4.1 with
PHOENIX-1075. If you have
If the dynamic column approach with the cf.* feature (PHOENIX-374) meets
your needs, that's good feedback. FWIW, you would not need to create all
the views up front at schema creation time. You can create them
on-the-fly. All views share the same, single underlying HBase table, so no
HBase
Yup, I am aware of Spark HBase integration. Phoenix-Spark integration would
be more sweet. :)
On Wed, Jan 7, 2015 at 12:40 AM, su...@certusnet.com.cn
su...@certusnet.com.cn wrote:
Hi Anil,
Well, there are already good opensouce project on github for Spark on
HBase, like the following:
Hello,
I am looking to find documentation on the integer representation used by
Phoenix for its data types listed here:
http://phoenix.apache.org/language/datatypes.html
Here is what I have found so far, this came from a combination of java.sql
types for the non-unsigned types and some
What is the cluster size, number of salted buckets?
Are you using compression ? : SNAPPY recommended.
From: Bulvik, Noam [mailto:noam.bul...@teoco.com]
Sent: Wednesday, January 07, 2015 7:00 PM
To: user@phoenix.apache.org
Subject: RE: high CPU when using bulk loading
Only when doing bulk
16 matches
Mail list logo
