2010-03-09 10 views
5

Estoy escribiendo un servicio de alojamiento de recursos Http genérico y estoy almacenando objetos más grandes como BLOB en una base de datos Oracle. Quiero poder configurar el encabezado 'Content-Length' cuando devuelvo un objeto almacenado, lo que significa que necesito saber el tamaño del BLOB antes de comenzar a escribirlo en el cliente (sé que podría usar la codificación fragmentada, y soy en algunos casos). ¿Alguien tiene alguna experiencia con el impacto en el rendimiento que dbms_lob.getlength() tendrá en cada lectura o debería calcular el tamaño del BLOB en INSERT y almacenarlo en la tabla? En promedio, esperaría que las tasas de escritura fueran más altas que las tasas de lectura. Estoy escribiendo un punto de referencia en este momento para tratar de ver cuál es el impacto, pero parece una pregunta tan común que pensé que alguien ya podría haberlo descifrado. Además, usando JDBC/Spring 3, ¿cómo puedo calcular el tamaño de BLOB en write? (y no puedo usar disparadores o procedimientos almacenados) Gracias.Blobs de Oracle: ¿almacenar o calcular?

+1

Mida, mida, mida. Las conjeturas son solo conjeturas. – skaffman

+0

Como siempre, pero con algo así como Oracle (utilizado por miles), este parecía un paradigma bastante frecuente y que muchos DBA ya han abordado. Si hubiera algún "truco" al respecto, me gustaría saberlo. – Gandalf

Respuesta

6

Hice una comprobación rápida seleccionando un BLOB de una tabla y luego una LONGITUD (BLOB) y DBMS_LOB.GETLENGTH (BLOB). Al seleccionar el BLOB en sí, obtuve 44 coincidencias. Cuando seleccioné la longitud (por cualquier método) obtuve 7 constantes.

En función de eso, cuando obtengo la longitud, no recupero toda la burbuja y calculo la longitud. Es sensato suponer que la longitud que almacenaba al comienzo del BLOB (como la longitud de un valor VARCHAR2) se almacena y esto se usa directamente.

Como tal, no debe haber una gran sobrecarga en la obtención de la longitud en lugar de almacenarla. También reduce la posibilidad de una inconsistencia.

+0

Hay un INDICE DE LOB que es un segmento separado, por lo que si su LOB no se puede almacenar en línea, puede encontrar rápidamente cuántos bloques se deben usar. En resumen, el OP debe, al obtener un único LOB, obtener DBMS_LOB.GETLENGTH() al mismo tiempo en lugar de almacenar un valor que es potencialmente incorrecto. –

+0

Además, con 11g puede usar una columna virtual para proporcionar la longitud del blob. – JavaRocky

0

Dado que no veo ninguna respuesta todavía ..

no he medido personalmente nada, pero nuestro DBA recomienda almacenar su tamaño (lo sé, es sólo que me lo dijo). Él es bastante bueno, así que personalmente creo que almacenar el tamaño es el camino a seguir, al menos si es crítico para el rendimiento (tendríamos que haber llamado a .length() MUCHO).

+2

Algunos DBA dirán cualquier cosa anterior. Un buen DBA podrá utilizar un ejemplo de código para justificar sus afirmaciones. – APC

2

Debido a que nuestros BLOBS comprimen bien, en general, que han adoptado este enfoque: -

  • tienda BLOB comprimido. La compresión se realiza en el lado de Java, ya que transmitimos en en el BLOB
  • registro el tamaño descomprimido en bytes en otra columna en la misma tabla
  • descomprimir a través de una corriente mientras enviamos el BLOB de nuevo, sabiendo lo que el tamaño de contenido será

Puede considerar este enfoque si sus BLOB son compresibles.

Cuestiones relacionadas