2010-10-04 19 views
6

Hace mucho tiempo me di cuenta de que bcp es solo un pequeño programa en C que llama al bit especial de la API del cliente de sybase para hacer que los datos masivos se muevan a la base de datos. Miente trucos y robos y salta restricciones de verificación todo en nombre de la velocidad. Genial, estoy totalmente de acuerdo. En sybase 12 noté que la API estaba expuesta en la biblioteca del cliente C, pero no en la de Java.¿Admite sybase 15 la API de bcp en java?

He estado buscando pero no he encontrado nada que diga que todavía lo han implementado en la biblioteca del cliente de sybase 15 java. ¿Alguien sabe si esto está disponible o no en sybase 15?

Respuesta

3

No estoy de acuerdo con sus comentarios sobre Java utilizando una API de BCP. Aunque estoy de acuerdo con las limitaciones de Java y ODBC/JDBC, eso no significa que no haya ventajas de usar una API de Java BCP. Tenemos un sistema con mucho Java y no es práctico o muy efectivo para pagar desde Java y ejecutar la utilidad de línea de comandos BCP.

La ejecución de la utilidad de línea de comandos no proporciona informes de errores muy buenos ni reintentos de interbloqueo. También requiere la escritura de datos en un archivo que va a aumentar el número de operaciones y ralentizar todo el proceso. En algún momento ni siquiera podemos escribir un archivo porque está en una cuadrícula que no tiene un sistema de archivos y tmp es demasiado pequeño.

En cuanto a la velocidad, el JBCP es más lento que el API nativo, sin embargo es aceptable y ciertamente más rápido que llamar comandos de inserción repetidos.

Mwillett (autor de JBCP)

+1

No soy una persona terriblemente articulada, pero en mi alma sé que cada programador sabe, como usted ha mencionado, que no acaba de conchatar a los programas de línea de comando para hacer las cosas. Simplemente no lo haces. Gracias por pronunciarlo tan bien. – stu

1

No estoy pensando, puede ser más un problema al ajustar esa operación en la especificación JDBC.

Veo un proyecto JBCP en SourceForge, pero no tengo ninguna experiencia con él.

+0

Creo que tienes razón. Es triste que una especificación dificulte que una empresa escriba software útil. – stu

1

La respuesta es NO.

Pero, ¿por qué en la Tierra le gustaría mover una gran cantidad de datos de Java al servidor? (1) Java no está diseñado para eso, por lo que será muy lento (2) bcp nativo o C + bcp o perl + bcp o cualquier comando de shell + bcp gritará círculos alrededor de él, y lo desplazará de todos modos. Es como querer ejecutar bcp a través de ODBC o JDBC.

Tenemos que alejarnos del Martillo Maslow y usar la herramienta adecuada para el trabajo.


más detalle, respondiendo a los comentarios:

  1. un programa común que se conecta al servidor ASE (estilo cliente-servidor) utiliza la biblioteca Open Client proporcionado; esto es nativo y mueve los paquetes TDS de manera eficiente. La conexión es una manguera de jardín de una pulgada disponible universalmente. Los PROGRAMAS escritos en C, C++, COBOL, Perl y PowerBuilder usan este transporte.

  2. ODBC (y por lo tanto JDBC porque está construido sobre ODBC) es un método simple de conexión al servidor que utiliza una manguera de un milímetro. Si bien esto es bastante adecuado para tareas como el uso de Excel para dibujar gráficos directamente desde tablas ASE, donde la velocidad de transferencia de datos no es relevante; es bastante inadecuado para mover datos de cualquier volumen sustancial, para el acceso normal de la aplicación a un servidor de datos (excepto cuando el "programador" ignora el hecho de que [1] está disponible).
    .
    Java no tiene [1] y está limitado a este [2] transporte.

  3. bcp es una utilidad PROGRAM (existe por sí misma) suministrada por el proveedor que se conecta al servidor mucho más estrechamente. No es un "bit especial de la API del cliente". No se trata de "mentir y hacer trampa", todas las restricciones están dirigidas por el DBA que realiza la tarea. La conexión es una manguera contra incendios de dos y media pulgadas, generalmente no disponible para el público. Está diseñado para mover grandes volúmenes de datos a velocidad. Si se usa en el mismo servidor que el servidor, dado que la manguera no se reticula a través de la red, mueve los datos aún más rápido.

  4. Mucho más tarde, el proveedor puso a disposición la capacidad de bcp como Biblioteca (API en sus términos), que por lo tanto puede invocarse desde cualquier compilador razonablemente diseñado. C, C++, COBOL y Perl son tales, y producen PROGRAMAS, y por lo tanto proporcionan acceso a esta biblioteca directamente desde su código. La conexión es la misma manguera de fuego de dos y media pulgadas, pero debido a las capas adicionales, funciona a la velocidad máxima de una manguera contra incendios de dos pulgadas.

(Nota a los lectores que esperan que esto sea una lista completa: Hay otras dos opciones que no he detallan aquí, ya que son servidor-servidor y no es relevante para este tema).

Dado que los PROGRAMAS Java están actualmente limitados a la conexión de un milímetro con el servidor ASE, no es útil proporcionar la API bcp a Java (simplemente tendrá una manguera de bomberos de dos y media pulgadas reticulada a través de la red; con un FLUJO de un milímetro), es una empresa absurda. Hay una razón por la cual, a pesar de los millones que muchas organizaciones han invertido en Java, durante su bastante larga progresión, ninguno de ellos ha gastado dinero en proporcionar una estación de bomberos que mueva goteos y caídas.

No se puede obtener la velocidad de un galgo de un perro salchicha, no tiene sentido dárselo a los entrenamientos. Puedes dejar de susurrar promesas al oído.

En segundo lugar, Java no puede manejar grandes conjuntos de datos (fuente) de manera eficiente, no fue diseñado para eso. Por lo tanto, incluso si se eliminó la estrangulación de JDBC (por ejemplo, se implementó una biblioteca de cliente abierto nativa), aún no puede mover datos tan rápido como C, C++, COBOL, Perl, PB; moverá los datos en un chorrito (¿un cuarto de pulgada?) en la manguera de una pulgada. Por lo tanto, incluso entonces, sería absurdo proporcionar la capacidad de bcp a la biblioteca de Java; eso valdría la pena si y cuando Java (que fue diseñado con otras prioridades en mente) está ungido con una gran capacidad de transferencia de datos.

Puede ser útil alejarse de su Java, Java y nada más que Java mentalidad, y Usar la herramienta correcta (PROGRAMA) para el Trabajo. Si usted es un "programador" de Java, al menos debe familiarizarse con la capacidad y las limitaciones de su lenguaje de programación y las bibliotecas disponibles. La pregunta original demuestra ignorancia completa de eso, por lo tanto tuve que proporcionarlo en mi publicación revisada.

Programadores que no están limitados a Java, piensen dónde se encuentra la gran fuente de datos; minimizar las transferencias de datos a través de las redes; piense en qué PROGRAMAS ya están escritos y que pueden usarse (en lugar de escribir los suyos aislados del resto del planeta); y usarlos.

Finalmente, para entender, incluso si obtuvo la capacidad de bcp en alguna Biblioteca, y la implementó, cuando coloca el "programa" en el mundo real, cualquier DBA razonable lo rechazará debido a su velocidad de transporte de datos de velocidad , y use bcp con su manguera de fuego en su lugar.

+0

http://catless.ncl.ac.uk/Risks/26.20.html#subj2 – stu

+0

Encontré este excelente artículo sobre por qué no deberías ejecutar proyectiles para hacer las cosas. – stu

+1

Está buscando evidencia para respaldar su posición fija. El idiota que implementó el sistema informado no entiende cómo configurar la seguridad en un sistema Unix. MySQL RUby, etc., todos los freeware están abiertos a la piratería, los dbs empresariales no lo son. Pero no nos distraigamos, hay millones (tal vez miles de millones) de scripts de shell y perl que se ejecutan con éxito en el planeta (más seguros, pero algunas tiendas de mickey mouse no están garantizadas). – PerformanceDBA

1

Si no te importa el programa Java no ser portátil más, puede enlazar a cualquier biblioteca de C a través de JNI. Esto es preferible a tener que volver a escribir la aplicación, o llamando a una tarea independiente a los datos BCP

Asumo prefiere no volver a escribir toda su aplicación en C++ ;-)

+0

ese es un muy buen punto, no sé por qué eso no se me ocurrió hace 4 años. :-) Pero, por desgracia, ese problema ya no es un problema, pero esta habría sido una muy buena idea viable. – stu

Cuestiones relacionadas