Ok..so if using jpa would kill hbase's performance...it may be an idea to use hbase native interface for hbase and jpa only for traditional DBs...so there are two interfaces..
But nevertheless I will try on using data nucleus' jpa for hbase and make some benchmarks to compare it with the hbase native interface ;-) Btw. I don't think I would have to forget M/R as I would only use JPA to get data into hbase or to get few records out of it....for analysis via M/R I would of course not use any JPA stuff but the native way.. comments welcome..as I'm a greenhorn to hadoop concepts :) ________________________________ Von: Michael Segel <[email protected]> An: [email protected] Gesendet: 22:27 Samstag, 15.Oktober 2011 Betreff: RE: Persist to HBase with JPA using HBql-JDBC-Driver (Examples)? Ok. So scratch the M/R then. I would still suggest that you really don't try and create a single interface. You're going to reduce your performance unnecessarily and not gain much in the process. HBase doesn't fit well in the JDBC realm. There is no such concept of a transaction. If you're going to try and solve a problem w two totally different types of data stores, you may want to get a little more creative. But trying to force HBase's api into a JPA which was designed for RDBMs... not really a good idea. JMHO, YMMV. -Mike ________________________________ Date: Sat, 15 Oct 2011 20:41:09 +0100 From: [email protected] Subject: Re: Persist to HBase with JPA using HBql-JDBC-Driver (Examples)? To: [email protected] CC: [email protected] Yes, the hbase access API may be easy but in the current project I want to have an exchangeable persistence solution without needing to write adapter-code for each db. That's because some customers of the system will have huge loads of data, so they will use hbase...for other small customers traditional DBs would be enough.. So the only requirement is a jpable database ;) If I missunderstood sth..please tell me :-) ________________________________ Von: Michel Segel <[email protected]> An: "[email protected]" <[email protected]> Gesendet: 17:18 Samstag, 15.Oktober 2011 Betreff: Re: Persist to HBase with JPA using HBql-JDBC-Driver (Examples)? <mini rant> ok... There are two ways to use HBase. One is as part of a map reduce program. The other is as a NoSQL data store. If you are writing a m/r job, you really don't want to create any DAO layer or even think about a JPA layer. Sorry but the access API is too simple to require any JPA and you're not writing to multiple data sources so you really don't want to do any abstraction... Keep It Simple. If you are writing an app to access HBase outside of a map reduce job, most of the same arguments apply. HBase access patterns are too simple to require any abstraction. </mini rant> Sorry, JMHO YMMV, so take what I say with a grain of salt. Sent from a remote device. Please excuse any typos... Mike Segel On Oct 14, 2011, at 3:54 PM, Christian Schäfer <[email protected]> wrote: > Hi St.Ack > > yes I'm currently using Data Nucleus...and thought I missed that there is a > JDBC-Driver > > > > > ________________________________ > Von: Stack <[email protected]> > An: [email protected]; Christian Schäfer <[email protected]> > Gesendet: 18:35 Freitag, 14.Oktober 2011 > Betreff: Re: Persist to HBase with JPA using HBql-JDBC-Driver (Examples)? > > On Fri, Oct 14, 2011 at 1:26 PM, Christian Schäfer <[email protected]> > wrote: >> just saw that there is a JDBC-Driver for HBase. >> >> So I wonder if it's possible to persist to HBase via JPA using that >> JDBC-Driver? >> >> For now I still saw in the examples that there are Annotations included in >> HBql what seems not so far away from JPA-Annotations. >> >> JPA-HBql-. Examples (I didnt find any) would be welcome :-) >> > > I think you might need to temper your expectation a little. I think > that jdbc driver is for hbql -- least thats what it understands. > Then I'm not sure of the state of hbql. > > The above seems a little dodgy to be building a jpa bridge upon? If > you google jpa and hbase there seem to be a few possibilities > (datanucleus for one). > > St.Ack
