Hi Prakash, Here is the url for performance comparison: http://phoenix.apache.org/performance.html
Thanks, Anil Gupta On Wed, Sep 10, 2014 at 9:16 AM, anil gupta <anilgupt...@gmail.com> wrote: > Hi Prakash, > > Please find my reply inline. > > On Tue, Sep 9, 2014 at 11:28 PM, Prakash Hosalli < > prakash.hosa...@syncoms.com> wrote: > >> Hi James/Anil, >> >> >> Regarding the questions you put forward, >> >> 1. Yes we will stored data in Hbase, >> 2. Hive will run over Hbase. >> > Anil: I am not aware of your use case to say how much you can do with > OOTB(Out of the Box) features of Hive and HBase integration. But, when i > tried to use Hive with HBase i could not use it because Hive does not > supports querying a table that has composite rowkeys. In an production > environment, most of the times users have composite rowkeys. Obviously, you > can patch Hive-HBase integration to make it better. Please keep in mind > that Hive is not designed to support HBase(HBase integration is just a > small feature of Hive). In contrast, Phoenix is designed on "Top of HBase" > so you will get much much better integration and optimization of HBase > query. > >> 3. We will be using large amount of data (approximately 10 Million >> of rows/daily to be process). >> > Anil: What kind of processing you will be doing? If you are doing simple > aggregates, that is already supported by Phoenix. You can also have a look > a Phoenix-Pig integration to leverage more analytical power of Pig(Although > Pig is a data flow language and Hive is declarative but you get Pig > integration OOTB.) > >> 4. Right now we have both options open, but primarily we plan to use >> Hive table to serve client request/query on aggregated data. >> > Anil: People primarily use Hive for SQL querying, same can be achieved in > a better way with Phoenix(especially when HBase is your storage). > >> 5. We plan to employ all type of query & we plan to achieve high >> level of low latency. >> > Anil: Phoenix will provide you much better performance on HBase. > >> >> If I understand correctly phoenix will just connect to Hbase >> securely & rely on the Hbase API to extract query reply, therefore Phoenix >> will depend on security mechanisms employed by Hbase API & will not provide >> any security feature by itself. >> > Anil: Yes, that is true. At present, Phoenix does not provides mechanism > to grant/revoke/create/add users. Same can be done using HBase shell and > phoenix will honor those changes. Phoenix is open source so a patch is > always appreciated for new features. > >> >> Kindly correct me if my understanding is wrong. >> >> >> Thanks & Regards, >> Prakash Hosalli >> >> >> -----Original Message----- >> From: James Taylor [mailto:jamestay...@apache.org] >> Sent: Tuesday, September 09, 2014 11:56 PM >> To: user; anil gupta >> Subject: Re: Hive or Phoenix >> >> Hi Prakash, >> If possible, it'd be helpful if you could describe your use case a bit. >> >> Some questions I'd have for you: is the data over which you'd query >> stored in HBase? And if so, would the Hive run over the HBase data? Is the >> data read-only or does it mutate? How much data are we talking about >> (approximately) and what would your typical queries be: point look-ups, >> range scans, or full table scans? >> >> As far as security, HBase provides some more fine grained mechanisms as >> well which you could leverage through HBase APIs. Other than the ability to >> connect to a secure cluster through the connection URL, Phoenix doesn't yet >> provide a SQL wrapper on these HBase APIs. This is how Intuit is leveraging >> Phoenix + security in HBase. Anil Gupta can likely tell you more. >> >> Thanks, >> James >> >> On Tue, Sep 9, 2014 at 9:28 AM, Nicolas Maillard < >> nmaill...@hortonworks.com> wrote: >> > Hello Prakash >> > >> > Considering Hive or Phoenix is a little misleading they di serve >> > different needs, let me break it down as I can. >> > >> > You mention security: >> > Phoenix and hive both work on a secured Hadoop cluster, but Hive with >> > Hive Atz has a more fine grained authorization model. So from that >> > perspective Hive has more features. >> > >> > Query performance >> > On the performance side Phoenix has random read,write access where >> > Hive is a full data access, so no way to read a particular entry >> > unless you read the whole associated file. >> > So Hive is batch or interactive, meaning a couple of tens of seconds >> > to get your answer, where Phoenix can be sub second, the response time >> > will depend greatly on wether part of the pheonix key is in your >> > query. I you do a full table scan response time will suffer. Granted >> > secondary indexes could help you there. >> > >> > SQL Semantics >> > Hive currently has a more rich sql semantics with analytics functions, >> > complex types etc... >> > Phoenix is also more limited than Hive in joins or UDFS >> > >> > So I would use Hive for large data, random analysis and ETL, and pay >> > the price of the response time a little. >> > Phoenix on the other hand is great for large volumes of data where you >> > can set up your schema and especially keys according to specific needs >> > and query patterns, in this situation you would get great query >> performance. >> > >> > To sum up in all honesty both are needed >> > >> > Hope this helps >> > >> > On Tue, Sep 9, 2014 at 4:19 PM, Prakash Hosalli >> > <prakash.hosa...@syncoms.com> wrote: >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> Is phoenix as any security layer in it. As we have in >> >> hive. >> >> >> >> >> >> >> >> Getting confuse to go forward with Phoenix or Hive in >> >> production environment in my company. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Prakash Hosalli >> >> >> >> Syncoms Bangalore India. >> >> >> >> >> > >> > >> > >> > CONFIDENTIALITY NOTICE >> > NOTICE: This message is intended for the use of the individual or >> > entity to which it is addressed and may contain information that is >> > confidential, privileged and exempt from disclosure under applicable >> > law. If the reader of this message is not the intended recipient, you >> > are hereby notified that any printing, copying, dissemination, >> > distribution, disclosure or forwarding of this communication is >> > strictly prohibited. If you have received this communication in error, >> > please contact the sender immediately and delete it from your system. >> Thank You. >> > > > > -- > Thanks & Regards, > Anil Gupta > -- Thanks & Regards, Anil Gupta
