Rendimiento de ODBC frente a JDBC

8 minutos de lectura

avatar de usuario de user3213918
usuario3213918

Tengo una tarea para usar Java y C con la base de datos MySQL y comparar los resultados y dar razones de por qué tal resultado.

No. of Records  Execution time (ms)
Records     Java     C
100         586      76
500         628      216
2000        733      697
5000        963      1056
10000       1469     2178

Como puede ver, con menos registros extraídos de la base de datos, C(ODBC) funcionó mejor. Pero a medida que aumentó la cantidad de registros, Java (JDBC) resultó ganador.

La razón por la que pensé es que puede ser que los controladores ODBC se carguen mucho más rápido que JDBC, pero la velocidad de acceso de JDBC es mejor que la de ODBC, por lo tanto, tales resultados. Sin embargo, no puedo encontrar tal razonamiento en ninguna parte.

¿Alguna sugerencia por favor?

  • Estoy bastante seguro de que es un problema de evaluación comparativa. Escribir puntos de referencia adecuados es en realidad bastante difícil. ¿Puedes mostrar el código C y Java respectivo que estás usando? Estoy bastante seguro de que los números deberían ser casi idénticos. Además, ¿qué tipo de datos estás usando? 500 ms para 100 registros parece ridículamente alto. Incluso los 76 ms en C parecen algo altos. ¿Qué tipo de veces obtienes a través del cliente MySQL?

    – Mikkel Lokke

    17 de febrero de 2014 a las 11:33

Avatar de usuario de Dennis Jaheruddin
dennis jaheruddin

Declaraciones presentadas por trabajos matematicos sitio web, estos parecen ser de aplicación general.

Decidir entre controladores ODBC y JDBC

Use ODBC nativo para:

  • Rendimiento más rápido para la importación y exportación de datos
  • Importaciones y exportaciones de datos con uso intensivo de memoria

Utilice JDBC para:

  • Independencia de la plataforma que le permite trabajar con cualquier sistema operativo (incluidos Mac y Linux®), versión de controlador o bitness (32 bits o 64 bits)
  • Usar funciones de Database Toolbox no admitidas por la interfaz ODBC nativa (como runstoredprocedure)
  • Trabajar con tipos de datos complejos o largos (p. ej., LONG, BLOB, texto, etc.)

Consejo:

  • En los sistemas Windows que admiten controladores ODBC y JDBC, los controladores JDBC puros y la interfaz ODBC nativa proporcionan mejor conectividad y rendimiento que el puente JDBC/ODBC.

Los siguientes puntos pueden ayudar:

Multihilo: – JDBC es de subprocesos múltiples – ODBC no es de subprocesos múltiples (al menos no es seguro para subprocesos)

Flexibilidad: – ODBC es una tecnología específica de Windows – JDBC es específico de Java y, por lo tanto, es compatible con cualquier sistema operativo compatible con Java

Energía : puede hacer todo lo que puede hacer con ODBC con JDBC, en cualquier plataforma.

Idioma: – ODBC es independiente del lenguaje y del procedimiento – JDBC está orientado a objetos y depende del lenguaje (específico de Java).

Carga pesada: – JDBC es más rápido – ODBC es más lento

Limitación de ODBC: es una API relacional y solo puede trabajar con tipos de datos que se pueden expresar en formato rectangular o bidimensional. (no funcionará con tipos de datos como el tipo de datos espaciales de Oracle)

API: La API de JDBC es una interfaz Java natural y se basa en ODBC y, por lo tanto, JDBC conserva algunas de las funciones básicas de ODBC.

  • Gracias por responder. Solo quería preguntar si hay alguna diferencia en la carga del controlador, etc. Porque eso es lo único que justificaría los resultados anteriores.

    – usuario3213918

    15 de febrero de 2014 a las 16:59

  • ODBC es de subprocesos múltiples. Hay controladores para cada declaración y funciona en dichos entornos sin problemas.

    – Michael Niklas

    17 de febrero de 2014 a las 10:57

  • Idioma: uso JDBC con Jython y probablemente pueda ser utilizado por cualquier idioma que funcione con JVM.

    – Michael Niklas

    17 de febrero de 2014 a las 11:04

  • Sí, tampoco estoy convencido por el comentario de velocidad.

    – Simón Nicholls

    21 de julio de 2017 a las 10:44

  • ODBC en sí admite la programación multiproceso, pero no todos los controladores ODBC lo hacen.

    – arana

    13 de mayo a las 20:48

¿Está seguro de que está comparando controladores y no entornos completos?

Veo que para ODBC usas el programa C. Pruebe el controlador ODBC con el mismo programa que usa para probar JDBC, pero ahora use el puente JDBC-ODBC (a menudo uso Jython para tales cosas). Por supuesto, el puente agrega algo de tiempo adicional. Recuerde también que JVM usa JIT: cuanto más tiempo funcione su aplicación, mejor rendimiento.

El rendimiento es importante, pero para mí mucho más importante es la estabilidad de los controladores. Tuve algunos problemas con varios controladores ODBC y ahora prefiero los controladores JDBC. Pero incluso los controladores ODBC pueden funcionar con servidores de subprocesos múltiples de alta carga durante muchos meses.

Siempre encuentro este tipo de discusiones sobre ODBC frente a JDBC rendimiento un poco fuera de lugar, no muy diferente de las discusiones en torno a JPA contra hibernación.

Es probable que una aplicación C++ que utilice un controlador ODBC escrito en C sea muy rápida para la pequeña parte de la interacción con la base de datos. Del mismo modo, un programa Java que se conecta a una base de datos usando el controlador de un proveedor que ha sido optimizado para su base de datos en particular también será bastante rápido.

Pero al observar un ciclo de solicitud-respuesta con una base de datos, la latencia de la red involucrada en realizar la solicitud es significativamente mayor que la sobrecarga de la API. De manera similar, el tiempo que lleva buscar en una base de datos o actualizar un registro o mantener viva una transacción será mucho más significativo que cualquier eficiencia que se obtendría al elegir ODBC en lugar de JDBC.

Utilizar el conductor recomendado por el vendedor dada la idioma estás desarrollando con. Y deje los problemas de rendimiento para que los resuelvan los administradores de la base de datos y los desarrolladores de SQL. Aquí no es donde va a resolver los cuellos de botella de su base de datos.

Avatar de usuario de Davos
davos

El objetivo de la tarea era presentarle un ejemplo de aplicación real que compara las características de rendimiento de un lenguaje precompilado C a un lenguaje interpretado justo a tiempo (JIT)^ Java.

^La diferencia entre el código interpretado y compilado es un argumento pedante, la verdad es que todo el código se interpreta en tiempo de ejecución; incluso el ensamblaje se convierte a lenguaje de máquina en tiempo de ejecución, y el lenguaje de máquina se resuelve en direcciones de memoria e instrucciones de CPU.

La distinción importante aquí es precompilado vs JIT. La diferencia es qué tan cerca se acerca el código al código de máquina en el tiempo de compilación frente al tiempo de ejecución. C se acerca en el momento de la compilación (en su mayor parte, ignorando los avances recientes en la compilación heurística en Java).

Este escenario de asignación agrega la complicación realista de la recuperación de datos de la base de datos, que en parte sirve para aumentar los números para que tenga algo con lo que trabajar, pero principalmente para acentuar que el tiempo del programa consiste en fijo (inicio) y variable (en este caso yo /O enlazado) fases. También podría haber sido un ejemplo vinculado a la CPU, habría surgido el mismo patrón.

Empieza a ser más fácil ver si graficas los valores en un gráfico.

Gráfico que muestra los tiempos de ejecución de la aplicación Java frente a C que ilustra el costo de inicio JIT fijo de Java

Mira la pendiente de las dos rectas. Creo que es una anomalía que, en sus números, el programa C sea más lento en más de 4000 registros, pero eso no es importante y no debería distraer la atención del punto central del ejemplo.

  • La aplicación C comienza con 100 filas en 76 ms, bastante cerca del origen en 0
  • La aplicación Java comienza en 586 ms, bastante cerca de 500.

El tiempo de inicio de la aplicación C es insignificante, por lo que puede ignorarse de manera efectiva.

El tiempo de inicio de la aplicación Java, por otro lado, es de alrededor de 500 ms. Es el compilador JIT que interpreta el código de bytes de Java en la máquina virtual de Java (JVM); es un costo inicial fijo que paga por cada ejecución del código sin importar la cantidad de datos que recupere de la base de datos.

Puede considerar que 500ms es el origen real de sus tiempos de acceso a datos y ver que el programa crece linealmente desde ese punto de 500ms.

No son los controladores JDBC vs ODBC por decir, sin embargo, el controlador JDBC también es una biblioteca Java que es efectivamente una extensión de su programa y está sujeta al mismo JIT, de manera similar, el controlador ODBC también es una biblioteca C precompilada que es efectivamente una extensión de su programa. No sería justo culpar específicamente a los controladores (suponiendo que ambos estén optimizados), se trata más del contexto de la aplicación como un todo.

¿Ha sido útil esta solución?