Para alguien que conoce los aspectos internos de la base de datos, esta puede ser una pregunta fácil, pero ¿alguien puede explicar de manera clara por qué se supone que almacenar grandes blobs (digamos películas de 400 MB) en la base de datos disminuye el rendimiento y qué significa eso exactamente? Este es un reclamo que a menudo se encuentra en Internet, pero nunca lo he visto realmente explicado.
Para ser específicos, me refiero al rendimiento de SharePoint / MSSQL, es decir, el rendimiento de carga de archivos, la exploración del sitio, la visualización de listas, la apertura de documentos, etc., operaciones que se dice que se vuelven más lentas una vez que una base de datos se vuelve demasiado grande. Se supone que la externalización de blobs en el sistema de archivos (que en SharePoint se llama Remote Blob Storage, también conocido como mover archivos fuera de la base de datos, dejando solo una referencia) resuelve esto hasta cierto punto, pero ¿cuál es exactamente la diferencia? Es obvio que las copias de seguridad tomarían más tiempo con archivos gigantes almacenados en la base de datos ... pero ¿qué operaciones se ven afectadas exactamente y cuál es el mecanismo subyacente (es decir, de qué manera se accede a los archivos almacenados en el sistema de archivos fuera de la base de datos o se almacenan de manera diferente)?
Suponga que una tabla simple que contiene columnas ID(guid, PK), FileName(string), Data(varbinary(max)): ¿una Datacolumna grande realmente ralentizaría las operaciones, como mostrar una lista de archivos en un sitio web (lo que supongo internamente significa ejecutar SELECT FileName FROM table) o insertar una nueva fila? No es que las columnas de contenido binario real estén indexadas.
Sé que ya se han hecho algunas preguntas como esta, pero no he encontrado una explicación adecuada.
Respuestas:
Esto realmente depende del sistema de base de datos, pero una cosa importante que debe considerar con los BLOB es el procesamiento de transacciones. Mediante la externalización al sistema de archivos, se eliminan los cambios en los datos binarios de las transacciones. Por lo general, eso dará como resultado operaciones de escritura más rápidas , en oposición a la situación en la que la base de datos le garantiza el cumplimiento de ACID con mecanismos completos de reversión, etc.
Hipotéticamente, también pueden ocurrir operaciones de lectura más lentas, cuando recupera datos de su base de datos de una tabla BLOB sin seleccionar realmente los datos BLOB, ya que el DB puede almacenar las filas restantes más localizadas en el disco, lo que permitirá un acceso de lectura más rápido (pero supongo que la mayoría Los sistemas de bases de datos modernos son lo suficientemente inteligentes como para almacenar los datos binarios reales en un área de disco separada o en un espacio de tablas, por lo que sin probar esto con un escenario del mundo real no se deben hacer suposiciones generales aquí).
fuente
Suele ser un problema con el ancho de banda. Si está sirviendo cientos de videos por hora, entonces está atando el ancho de banda dentro y fuera de la base de datos, principalmente copiando buffers. También es un problema si tiene consultas ingenuas (posiblemente generadas automáticamente por una herramienta ORM) que simplemente seleccionan todas las columnas de una tabla. También está sujeto a la fragmentación de archivos como un sistema de archivos (excepto en este caso es la fragmentación de registros), pero (generalmente) sin ninguna herramienta para des-fragmentar. Si también está modificando el BLOB (p. Ej., Admite algún tipo de edición de video), la base de datos copiará todo el BLOB en el segmento de deshacer o rehacer, luego escribirá el BLOB actualizado en la base de datos. Así que ahora estás copiando esos cientos de megabytes,
fuente
Es posible que desee buscar en las tablas de archivos de SQL Server . La idea es proporcionar lo mejor de ambos mundos: acceso y rendimiento a nivel del sistema de archivos, junto con acceso a la base de datos y seguridad y servicios integrados. La base de datos tiene una sobrecarga de rendimiento en algunos casos. Simplemente compare un archivo HTML codificado en un servidor web con uno que tenga que recuperar el contenido de una base de datos.
Imagine que una aplicación que no encontró el almacenamiento de blobs en la base de datos era un límite significativo para el rendimiento, pero luego la aplicación creció hasta el punto en que se encontraba. Hay menos cambio de codificación con FileTables. Además, puede administrar la transacción a nivel de base de datos y de archivo sin mucha codificación. El archivo y los metadatos están disponibles con SQL.
En Windows Server, se crea una unidad compartida para acceder a los archivos sin utilizar la transacción de la base de datos.
Es un problema común que Microsoft ha intentado manejar "fuera de la caja" con SQL Server 2012. No es una mala característica para justificar una actualización.
fuente
Para saber por qué esto es feo, debe saber cómo se guarda una base de datos en el disco duro (específicamente las filas). El contenido físico de una fila guardada en el disco se divide en sus contrapartes estáticas y dinámicas. Los campos como int, byte, char (n) que tienen una longitud fija se enumeran primero. Lo que sigue es un número de longitud fija que se refiere al número de campos de longitud variable a seguir. Todos los campos variables (independientemente del orden de las columnas que se le presentan, el programador) se agregan al final, cada uno con un número de longitud fija que determina cuánto espacio ocupa el campo de longitud variable.
Para darte un ejemplo concreto. Supongamos que mi tabla es la siguiente:
Ahora supongamos que sí
INSERT INTO mytable (A, B, C) VALUES ('AAA', 'B', 256). En la base de datos, esa fila probablemente se almacenaría de la siguiente manera:El campo A se guarda como cabría esperar. Si hubiera insertado 'A', habría proporcionado un carácter especial para marcar el final prematuro de la cadena después del primer carácter, pero ocuparía el mismo espacio.
El campo C se guarda como el equivalente binario de 256. ¿Por qué C y no B? C es el siguiente campo estático con una longitud fija y, como tal, se agrupa con todos los demás datos estáticos en la fila de la base de datos.
El campo D es metainformación para la base de datos que indica que en la siguiente sección de campos de longitud variable, habrá exactamente 1 campo.
El campo E es nuevamente metainformación para la base de datos que indica que para este campo en particular, tiene como máximo 1 carácter de longitud. Esta información es esencial porque de lo contrario la base de datos no sabría dónde termina el campo B y comienza otro campo de longitud variable.
Todo esto para demostrar cómo manejan las bases de datos guardar campos de longitud variable. BLOB es en gran medida un campo de longitud variable a este efecto. La estructura de la base de datos permite que una fila contenga valores pequeños y grandes en el BLOB, sin embargo, hay otros factores en juego aquí. Las bases de datos normalmente se ocupan de fragmentos de información, ya que los discos no se preocupan por el contenido, sino más bien si encajan en un solo fragmento.
La base de datos intentará ajustar tantas filas en un solo fragmento sin tener que separar una fila en dos partes, porque de lo contrario el efecto es el mismo que tener un archivo fragmentado en su disco duro. Una vez que se carga un fragmento, si la fila desborda ese fragmento en particular, el disco duro debe buscar el resto en otro fragmento. Peor aún, no hay forma de que una base de datos pueda saber que una fila ocupa más que un fragmento sin leer completamente su contenido, ya que tiene una longitud variable, por lo que no puede optimizar al buscar ambos fragmentos a la vez.
Siguiendo esta línea de lógica, si pudiera hacer un BLOB de longitud estática, no tendría este problema de optimización, ya que la base de datos simplemente podría garantizar que el tamaño del fragmento es mayor que el tamaño mínimo de la fila, asegurando así que la mayoría de las filas no tiene que ser dividido en múltiples trozos. Por supuesto, las bases de datos no hacen esto porque significaría dedicar un espacio precioso cuando probablemente no lo necesite.
Los BLOBS están bien cuando se trata de cantidades relativamente pequeñas, pero para archivos grandes como videos y similares, una solución común es simplemente guardar la ruta del archivo en la base de datos y dejar que el software se encargue de cargar el archivo, que casi siempre es más eficiente.
Espero que eso lo explique. :)
fuente