To connect to the AWS Redshift we can use JDBC or ODBC drivers. Recently I have heard that the JDBC drivers performance is about 40% better than ODBC ones. Unfortunately, I cannot find such information somewhere in the documentation.
Do you have any experiences which drivers perform better on AWS Redshift?
There may be minor differences in query execution time for different driver types due to the following:
https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html#compiled-code
The execution engine compiles different code for the JDBC connection protocol and for ODBC and psql (libq) connection protocols, so two clients using different protocols will each incur the first-time cost of compiling the code. Other clients that use the same protocol, however, will benefit from sharing the cached code.
Note that first time compilation cost has been dramatically reduced in recent Redshift releases.
Related
Is there a tool to synchronise an Oracle and a Grakn database in real time? I couldn't find any information online so any help would be greatly appreciated.
I know Grakn offers GRPC through its client drivers which I'm assuming is the way to go to push things into Grakn.
And I'm aware there are triggers in the Oracle tables, but not sure if will slow down the application layer on the Oracle DB. How would this impact the performance of the BD?
Thanks!
There aren't any such tools that you can use OOTB. If you need to keep the Oracle system running then I think you've got two options:
Intercept the data as it comes in and dispatch to both Oracle and Grakn.
Find a triggering mechanism, and as you outline, read from Oracle and push the data to Grakn through its driver(s).
GRPC is built in to Grakn's drivers, and is the only way to communicate with a Grakn server. These drivers are optimised as such!
Sun's JDBC-ODBC bridge driver was meant as a short term solution when JDBC drivers weren't widely available, not recommended for production, etc etc. Yet due to a conjunction of many stupid decisions made on the part of many others, we're forced to use this to connect to Oracle rather than JDBC.
Are there any ODBC-JDBC bridge drivers out there, better than Sun's implementation...which are also free?
There are some options:
Easysoft JDBC-ODBC Bridge Driver
Openlinksw Single-Tier JDBC to ODBC Bridge
Other options ( in second answer due to strange security check in stackoverflow, possibly they do not want new users)
Openlinksw Multi-Tier JDBC to ODBC Bridge Driver
Simba SDK allows to build custom jdbc or odbc drivers and bridges
can anyone tell me How does jdbc work? How it manages to communicate with a DBMS? since DBMS may be written with some other programming language.
Communication with the database is handled by JDBC drivers that can use various strategies to "talk" to a database (from "translation" to the use of "native" language). Depending on the strategy used, drivers are categorized into 4 types. Types of JDBC technology drivers provide a good description of each of them:
A JDBC-ODBC bridge provides JDBC API access via one or more ODBC
drivers. Note that some ODBC native
code and in many cases native database
client code must be loaded on each
client machine that uses this type of
driver. Hence, this kind of driver is
generally most appropriate when
automatic installation and downloading
of a Java technology application is
not important. For information on the
JDBC-ODBC bridge driver provided by
Sun, see JDBC-ODBC Bridge Driver.
A native-API partly Java technology-enabled driver converts
JDBC calls into calls on the client
API for Oracle, Sybase, Informix, DB2,
or other DBMS. Note that, like the
bridge driver, this style of driver
requires that some binary code be
loaded on each client machine.
A net-protocol fully Java technology-enabled driver translates
JDBC API calls into a DBMS-independent
net protocol which is then translated
to a DBMS protocol by a server. This
net server middleware is able to
connect all of its Java
technology-based clients to many
different databases. The specific
protocol used depends on the vendor.
In general, this is the most flexible
JDBC API alternative. It is likely
that all vendors of this solution will
provide products suitable for Intranet
use. In order for these products to
also support Internet access they must
handle the additional requirements for
security, access through firewalls,
etc., that the Web imposes. Several
vendors are adding JDBC
technology-based drivers to their
existing database middleware products.
A native-protocol fully Java technology-enabled driver converts
JDBC technology calls into the network
protocol used by DBMSs directly. This
allows a direct call from the client
machine to the DBMS server and is a
practical solution for Intranet
access. Since many of these protocols
are proprietary the database vendors
themselves will be the primary source
for this style of driver. Several
database vendors have these in
progress.
As we can see, there are various strategies to make interoperability possible, including implementing the network protocol used by a given database in Java (type 4). And because of their ease of use (no extra stuff to install, no JNI) and their good performances (they perform as well as type 2 drivers now), type 4 are actually the most frequently used nowadays.
From Wikipedia:
JDBC drivers are client-side adapters (installed on the client
machine, not on the server) that convert requests from Java programs
to a protocol that the DBMS can understand. [edit] Types
There are commercial and free drivers available for most relational
database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Most database systems support ODBC (Open Database Connectivity or whatever). This is meant to allow applications (e.g., Access) to work with multiple RDBMS implementations at the cost of some performance hit. When JDBC was first released, there was a driver that allowed you to connect to an ODBC provider. Later on, some vendors provided JDBC drivers specific to their RDMS.
From a developer's perspective, JDBC is used as a set of interfaces. All the actual details are hidden in loading the driver. The driver is a Java class that can use any trick of the book, including native code or just sending network traffic to the RDBMS.
From Wikipedia:
JDBC is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.
JDBC was first introduced in the Java 2 Platform, Standard Edition, version 1.1 (J2SE), together with a reference implementation JDBC-to-ODBC bridge, enabling connections to any ODBC-accessible data source in the JVM host environment.
Without going into too much detail, you can think of JDBC as an abstraction layer that lets you talk to different databases. The implementation-specific details are hidden from you, but the interface for querying a database (be it MySQL or Oracle or whatever) is the same.
What this means is that in future, if there was a new database, someone only needs to use the existing interface. The method names would be the same, but the methods would contain implementation-specific code for that particular database. This is a common software-engineering pattern.
The entity that contains the implementation-specific code is called the JDBC driver. The JDBC driver provides a connection to the database and it also implements the specific protocol for sending the query to the database and the result-set back to the client.
Can't say I know the exact answer to your question, but here is some information to help.
Here's a great place to start:
http://java.sun.com/products/jdbc/overview.html
The JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is the lower-level JDBC driver API for driver writers.
Information for JDBC Driver Developers. Basically there are a set of interfaces that a developer implements to create a JDBC driver for a particular DBMS.
http://java.sun.com/products/jdbc/driverdevs.html
As far as a DBMS being written in a different language. That DBMS most likely exposes some API (in various languages and/or formats) that allow for drivers, such as JDBC, to communicate with the DBMS.
From the wikipedia page:
Types
There are commercial and free drivers available for most relational database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Reading a bit about the four types of JDBC drivers might enlighten you.
i am looking for an Delphi component to connect to an ORACLE database server in an direct way without install the oracle client.
i knew the Oracle Data Access (ODAC) from DevArt. there are any other component with this capability?
ODAC offers two connection modes to
the Oracle server: connection through
the Oracle Call Interface in Client
mode and direct connection over TCP/IP
in Direct mode. ODAC-based database
applications are easy to deploy, do
not require installation of other data
provider layers.
Thanks in advance.
No, there is no other Delphi Win32 libraries allowing to connect to Oracle without the installed Oracle Client. And, IMHO, that is correct, because:
OCI (Oracle Call Interface) is quite complex piece of software. I will say, it is most complex closed sourced DBMS Call Level Interface in the World. And it is changing from version to version. Oracle has official rule - the Oracle Client v X supports Oracle Server v X-1 ... X+1. Because even such company as Oracle, dont want to spend resources to support and test all the protocol nuances across all possible versions. So, I dont think, that DevArt ever will implement 99.9% stable Oracle SQL*Net protocol implementation. And the INet posts proof that ...
AFAIK, the ODAC Net mode does not support some of the Oracle Client important features and has some important limitations. Although it works well for simple data access scenarious.
If you will purchase Oracle support, then it will decline all your support requests, if they will know, that you are not using official client software. That is just Oracle rule.
If you dislike to install and tune the full scale Oracle Client, then you can just use Oracle Instant Client. Which does not require install or setup procedure. And you will be in safety in case of the different data access scenarious and Oracle Server versions.
PS: Although I may be considered as a biased person :)
There is also Allround Automations Direct Oracle Access, it do require Oracle SQL*Net or Net8. but is a brilliant component suite.
The only solution I found is ODAC, and it's working very nice, I have been using it since years without getting any problem with the direct mode.
there's some limitation with the direct mode, but most of users will not get these limitations with their application.
Is there a way to tune the Oracle client (InstantClient or the normal one)?
We have a software that runs on multiple DMBS (MySQL, PGSQL and MS SQL Server) I'm wondering why the Oracle version of the product consume more resources than the other ones.
UPDATE: I'm using the C++ API (OCI).
Well depending on the version of oracle and client you can tune your connection to oracle, largely through using the tnsnames.ora and sqlnet.ora. you can change all sorts of things like buffer sizes, etc. This is an example of one: SDU & MTU sizes. As for resources, the DLL from the oracle client is HUGE and will consume more memory/disk space then the other ones. I know the OCI.dll we use is 100+ mb dll. Other then that I would ask you to be more specific as what resources you would like to tune?