pros and cons of utilizing HANA JDBC driver

[MartinMaruskin]

Hi all,

I'm looking to gather an information on pros and cons of using HANA JDBC driver.

I understand that JDBC driver comes out of the box. What are actually cons of using it?

Also what are performance aspects of using HANA JDBC driver for connection to HANA from external JAVA app?

Is there any way of how to write native driver for HANA w/o using standard DB drivers of HANA like JDBC, ODBC, ODBO?

thanks in advance for your insight!

m./

[lbreddemann · Accepted solution]

Hi Martin,

I'm not really sure what you mean by pros/cons in this context.

The SAP HANA driver is as native as it can get. It's JDBC 4.0 compatible and supports every way to interact with SAP HANA that is externally supported.

If you develop in JAVA it's certainly the most low-level, "close-to-the-machine" way there is.

Obviously you can also implement access e.g. via ODATA but that would add processing layers on both client and server side.

To develop a native 3rd party driver implementation would be at least pretty difficult. While the network protocol is at least roughly documented (see the SAP HANA reference documentation) there are certainly aspects of the protocol implementation that won't be documented internally.

So, here you are with a proprietary wire-protocol that you can only implement by using reverse-engineering - which violates the license agreements (and the law in come countries).

In my eyes this limits the options to implement an alternative driver (regardless of the API you want to implement it for).

I think more fruitful would be to ask about limitation of each driver and look into how these can be overcome. We (SAP) certainly have an interest in learning what actual requirements customers have.

For example: the current JDBC driver doesn't allow to set a LOB value via a StreamInterface. Instead the binary data has to be assigned via a byte array at once. This is a limitation that other JDBC drivers don't have and although this limitation would require functional enhancements on the SAP HANA server as well ( e.g. you need to have a concept of LOB locator and client side LOBs in order to deal with streaming data) if there is a use case that absolutely requires this feature, it would be very interesting to hear about that.

Anyway, maybe you explain a more in detail what exactly it is you're after...

- Lars

[MartinMaruskin · Accepted solution]

Hi Lars,

thanks for your insight! Background of my question is related to following idea. We are trying to evaluate what type of HANA driver would be the best performant in high data volume exchange environment. Think of this as application that produces vary large data sets very frequently. The data exchange would need to be done as much real-time as possible.

Integration with the application that produces that much data would not be done via BODS or SLT but would be done by app leveraging one of HANA drivers like JDBC/ODBC/ODBO...

As per your reply I understand that JDBC would be more less most convenient fit for this scenario. Are there any other limitation apart those you mentioned (LOB) you are aware of? Can you point me to some sources where these things are discussed maybe?

I recently found SQLDBC listed as interface option for HANA. I'm not sure if I get this right but it seems to me that the SQLDBC is HANA native protocol? Please correct me as I'm not sure in here.

At last I'm wondering how integration of HANA and hadoop is done. As there are few options available (Smart Data Access, BODS, JAVA app using JDBC and SQOOP) in particular I'm interested in option of SQOOP. What technology/driver does utilize the SQOOP?

Thank you again for your valuable feedback.

m./

[lbreddemann · Accepted solution]

Hmm... not too sure why you discard a well scaleable and proven solution like DataServices.

Concerning SQLDBC: that's just another API (for C++ in this case) to communicate with SAP HANA. It's not "more native" than the JDBC driver in that sense.

The most prominent source of information on SAP HANA technology would ... here on SCN .

Besides all that: when you consider high volume data transfer it is important to think "parallel".

Serial data transfer always only ever scales to the limits of a single thread and what the network interface can provide you in terms of bandwidth.

-  Lars

[MartinMaruskin · Accepted solution]

Hi Lars,

I have nothing against BODS. I have seen couple of implementations where it worked perfectly as ETL tool from non/SAP sources. Just idea is to try something w/o these common tools such as BODS.

One more hint in here: What about if I base my data exchange on HANA AFL library? It would hooked on to AFL and data will go through it. To be honest I assume here that SDK for AFL is available which I'm not sure about.

thanks!

m./

[lbreddemann · Accepted solution]

Never worked with it, so I cannot comment on that. Sorry.