2012-03-07 23 views

Respuesta

39

Tiene básicamente dos opciones. Puede almacenar los datos directamente en la fila o puede usar el recurso de objeto grande. Dado que PostgreSQL ahora utiliza algo llamado TOAST para mover campos grandes fuera de la tabla, no debería haber una penalización de rendimiento asociada con el almacenamiento de datos grandes en la fila directamente. Sigue habiendo un límite de 1 GB en el tamaño de un campo. Si esto es demasiado limitado o si desea una API de transmisión, puede usar el recurso de objetos grandes, que le ofrece algo más parecido a los descriptores de archivos en la base de datos. Almacena la ID LO en su columna y puede leer y escribir desde esa ID.

personalmente sugeriría a evitar la instalación objeto grande a menos que no lo necesita. Con TOAST, la mayoría de los casos de uso se cubren con solo usar la base de datos de la manera esperada. Con los objetos grandes, usted se da una carga de mantenimiento adicional, porque debe hacer un seguimiento de los ID de LO que ha usado y asegurarse de desvincularlos cuando ya no los use (pero no antes) o se sentarán en su el directorio de datos ocupa espacio para siempre. También hay muchas instalaciones que tienen un comportamiento excepcional a su alrededor, cuyos detalles me escapan porque nunca los utilizo.

Para la mayoría de las personas, la gran penalización de rendimiento asociada con el almacenamiento de datos grandes en la base de datos es que su software ORM extraerá los datos grandes en cada consulta a menos que específicamente le indique que no lo haga. Debe tener cuidado de decirle a Hibernate o lo que sea que esté usando que trate estas columnas como grandes y solo las busque cuando se soliciten específicamente.

+0

Una respuesta agradable, muy gracias. ¿El tipo bytea se usa para almacenar el contenido en la tabla? –

+2

bytea los datos se almacenarán en la tabla de forma predeterminada si son pequeños, y se moverán a la tabla auxiliar ("tostado") y se comprimirán para valores más grandes. Ver: http://www.postgresql.org/docs/9.1/static/storage-toast.html para una introducción. Puede deshabilitar la compresión del almacenamiento auxiliar, lo que mejorará el rendimiento de recuperar solo partes de los valores. – araqnid

+0

'bytea' es una buena opción para datos binarios. También puede usar 'text' o' varchar' si los datos son textuales y en la misma codificación que la base de datos. –

8

El BLOB (LO) escriba almacena los datos en trozos 2KB dentro de las páginas PostgreSQL montón estándar, que por defecto a 8 KB de tamaño. No se almacenan como archivos independientes y cohesivos en el sistema de archivos; por ejemplo, no podría ubicar el archivo, hacer una comparación de byte a byte y esperar que sea el mismo que el archivo original que usted cargado en la base de datos, ya que también hay encabezados y estructuras de la página del montón de Postgres que delinean los fragmentos.

Usted debe evitar el uso de la interfaz del objeto grande (LO) si su aplicación tendría que actualizar con frecuencia los datos binarios, y particularmente si que participan una gran cantidad de, acceso aleatorio pequeño escribe, que debido a la forma en PostgreSQL implementa concurrencia control (MVCC) puede provocar una explosión en la cantidad de espacio en disco utilizado hasta que VACÍO en la base de datos. El mismo resultado probablemente también sea aplicable a los datos almacenados en línea en una columna con el tipo bytea o incluso TOAST'd.

Sin embargo, si sus datos siguen un patrón Write-Once-Read-Many (por ejemplo, cargar una imagen PNG y nunca modificarla después), debería estar bien desde el punto de vista del uso del disco.

Ver this pgsql-general mailing list thread para continuar el debate.

Cuestiones relacionadas