mysql - leewayweb - ¿Cuál es la diferencia entre almacenar datos en un blob y almacenar un puntero a un archivo?
guardar pdf en mysql java (5)
Tengo una pregunta sobre el tipo de datos blob en MySQL.
Leí que el tipo de datos se puede utilizar para almacenar archivos. También leí que una alternativa es almacenar el archivo en el disco e incluir un puntero a su ubicación en la base de datos (a través de una columna varchar).
Pero estoy un poco confundido porque he leído que los campos de blob no se almacenan en la fila y requieren una búsqueda por separado para recuperar su contenido. Entonces, ¿es eso diferente al almacenamiento de un puntero a un archivo en el sistema de archivos?
Leí que el tipo de datos se puede utilizar para almacenar archivos.
De acuerdo con la página de manual de MySQL en Blob, un BLOB es un objeto binario grande que puede contener una cantidad variable de datos.
Dado que es un tipo de datos específico para almacenar datos binarios, es común utilizarlos para almacenar archivos en formato binario, ya que el almacenamiento de archivos de imágenes es un uso muy común en las aplicaciones web.
Para las aplicaciones web, esto significaría que primero tendría que convertir su archivo a formato binario y luego almacenarlo, y cada vez que necesite recuperar su archivo, deberá realizar el proceso inverso de conversión a su formato original.
Además de eso, almacenar una gran cantidad de datos en tu db PUEDE ralentizarlo. Especialmente en sistemas que no están dedicados solo a alojar una base de datos.
También leí que una alternativa es almacenar el archivo en el disco e incluir un puntero a su ubicación en la base de datos
Teniendo en cuenta todas las consideraciones anteriores, una práctica común para las aplicaciones web es almacenar sus archivos en otro lugar que no sea su MySQL y luego simplemente almacenar su ruta en su base de datos. Este enfoque PUEDE acelerar su base de datos cuando se trata de una gran cantidad de datos.
Pero estoy un poco confundido porque he leído que los campos de blob no se almacenan en la fila y requieren una búsqueda por separado para recuperar su contenido.
De hecho, eso dependería del motor de almacenamiento que esté utilizando, ya que cada motor trata los datos y los almacena de diferentes maneras. Para el motor InnoDB, que es adecuado para la base de datos relacional, puede leer este artículo del blog MySQL Performance sobre cómo se almacena el blob en MySQL.
Pero en resumen, en MySQL 5 y reenviar el blob se almacena como sigue:
Innodb almacena un blob completo en la página de la fila o solo un puntero BLOB de 20 bytes, dando preferencia a las columnas más pequeñas que se almacenarán en la página, lo cual es razonable, ya que puede almacenar más de ellas.
Probablemente esté pensando ahora que la mejor manera de hacerlo es almacenarlos como archivos separados, pero hay algunas ventajas de usar blob para almacenar datos, la primera (en mi opinión) es la copia de seguridad. Administro un pequeño servidor y tuve que crear otra subrutina solo para copiar mis archivos almacenados como rutas a otro disco de almacenamiento (no podíamos permitirnos comprar un sistema de copia de seguridad en cinta decente). Si hubiera diseñado mi aplicación para usar blobs, un simple mysqldump sería todo lo que necesitaba para hacer una copia de seguridad de toda mi base de datos.
La ventaja de almacenar blobs para copias de seguridad se explica mejor en este post donde la persona que respondió tuvo un problema similar al mío.
Otra ventaja es la seguridad y la facilidad de administración de permisos y acceso. Todos los datos dentro de su servidor MySQL están protegidos por contraseña y puede administrar fácilmente los permisos para sus usuarios sobre quién accede a qué y quién no.
En una aplicación que se basa en el sistema de privilegios MySQL para la autenticación y el uso. Es cierto que es una ventaja, ya que sería un poco más difícil decir, por ejemplo, que un invasor recupere una imagen (o un archivo binario como un archivo comprimido) de su disco o un usuario sin privilegios de acceso para acceder a él.
Asi que diria eso
Si va a administrar su MySQL y todos los datos que tiene y debe hacer copias de seguridad regulares o tiene la intención de cambiar o incluso considerar un cambio futuro en el sistema operativo, y tener un hardware decente y optimizado su MySQL, vaya a BLOB.
Si no va a administrar su MySQL (como en un host web, por ejemplo) y no tiene la intención de cambiar el sistema operativo o hacer copias de seguridad, quédese con las columnas varchar que apuntan a sus archivos.
Espero que haya ayudado. Aclamaciones
El acceso al sistema de archivos será más rápido que a través de la base de datos. Las columnas de blobs tienen algunas desventajas en términos de indexación / clasificación, etc., que puede hacer con su columna de nombre de archivo si lo desea en el futuro.
La base de datos también puede crecer rápidamente con grandes manchas y luego las tareas como la copia de seguridad se vuelven más lentas. Me gustaría ir con una ubicación de archivo en la base de datos con el almacenamiento físico en el sistema de archivos.
El mejor enfoque es almacenar su archivo en la carpeta del sistema de archivos y señalar sus rutas a través de un campo varchar en la base de datos. Uno de los inconvenientes de guardar archivos en la base de datos es ralentizarla o reducir su rendimiento.
Sí, los blobs de MySQL que no caben en la misma página que una fila se almacenan en las páginas de desbordamiento. Tenga en cuenta que algunos blobs son tan pequeños que se almacenan con el resto de la fila, como en cualquier otra columna. Las páginas de blob no están adyacentes a la página en la que está almacenada la fila, por lo que pueden resultar en E / S adicionales para leerlas.
Por otro lado, al igual que con cualquier otro tipo de página, las páginas de blob pueden ocupar memoria en el grupo de búferes InnoDB, por lo que leer los blobs posteriormente es muy rápido, incluso si están en páginas separadas. Los archivos pueden ser almacenados en caché por el sistema operativo, pero normalmente se leen desde el disco.
Aquí hay algunos otros factores que pueden afectar su decisión:
Blobs se almacenan lógicamente con una fila. Esto significa que si ELIMINA la fila, el blob asociado se eliminará automáticamente. Pero si almacena el blob fuera de la base de datos, termina con archivos de blob huérfanos después de eliminar las filas de la base de datos. Tienes que hacer pasos manuales para encontrar y borrar estos archivos.
Las manchas almacenadas en la fila también siguen la semántica de la transacción. Por ejemplo, un nuevo blob o un blob actualizado son invisibles para otras transacciones hasta que confirme. También puede deshacer un cambio. Almacenar blobs en archivos fuera de la base de datos hace esto mucho más difícil.
Por supuesto, cuando realiza una copia de seguridad de una base de datos que contiene blobs, la base de datos es mucho más grande, pero cuando realiza una copia de seguridad, obtiene todos los datos y blobs asociados en un solo paso. Si almacena blobs externamente, debe hacer una copia de seguridad de la base de datos y también hacer una copia de seguridad del sistema de archivos donde almacena los archivos blob. Si necesita asegurarse de que los datos y los blobs se capturan desde un instante en el tiempo, es casi necesario que use algún tipo de instantáneas del sistema de archivos.
Si usa replicación, la única forma automática de asegurarse de que los blobs se copien al esclavo de replicación automáticamente es almacenar blobs en la base de datos.
Si almacena datos en el campo BLOB, lo está haciendo parte de la abstracción de su objeto.
Ventajas del BLOB:
Si desea eliminar la fila con BLOB, o eliminarla como parte de la relación de la tabla maestro / esclavo o tal vez de toda la jerarquía de tablas, su BLOB se maneja automáticamente y tiene la misma duración que cualquier otro objeto en la base de datos.
Sus scripts no tienen la necesidad de acceder a nada más que a la base de datos para obtener todo lo que necesitan. En muchas situaciones, tener acceso directo a archivos puede abrir toda lata de gusanos sobre cómo omitir el acceso o las restricciones de seguridad. Por ejemplo, con acceso a archivos, es posible que tengan que montar sistemas de archivos que contengan archivos reales. Pero con BLOB en la base de datos, solo tiene que poder conectarse a la base de datos, sin importar dónde se encuentre.
Si lo almacena en un archivo y el archivo se reemplaza, se elimina o ya no se puede acceder a él, su base de datos nunca lo sabría; en efecto, no puede garantizar la integridad. Además, es difícil admitir de manera confiable varias versiones cuando se usan archivos. Si usas y dependes de las transacciones, se vuelve casi imposible.
Ventajas de archivo:
Algunas bases de datos manejan BLOBs bastante mal. Por ejemplo, mientras que el límite oficial de BLOB en MySQL es de 4 GB, pero en realidad solo tiene 1 MB en la configuración predeterminada. Puede aumentar esto a 16-32 MB ajustando la configuración del cliente y del servidor para aumentar el búfer de comandos de MySQL, pero esto tiene muchas otras implicaciones en términos de rendimiento y seguridad.
Incluso si la base de datos no tiene algunos límites de tamaño extraños, siempre tendrá algo de sobrecarga en el almacenamiento de BLOB en comparación con solo un archivo. Además, si BLOB es grande, algunas bases de datos no proporcionan una interfaz para acceder a blob pieza por pieza, o lo
stream, lo que puede ser un gran impedimento para su flujo de trabajo.
Al final, depende de ti. Por lo general, trato de mantenerlo en BLOB, a menos que esto genere problemas de rendimiento irrazonables.