Si tengo una base de datos estática que consta de carpetas y archivos, ¿el acceso y la manipulación serían más rápidos que las bases de datos del tipo de servidor SQL, teniendo en cuenta que esto se usaría en un script CGI?¿Es más rápido acceder a los datos de los archivos o un servidor de base de datos?
Al trabajar con archivos y carpetas, ¿cuáles son los trucos para un mejor rendimiento?
Voy a agregar a la multitud depende.
Este es el tipo de pregunta que no tiene una respuesta genérica pero que depende en gran medida de la situación en cuestión. Incluso recientemente cambié algunos datos de una base de datos SQL a un sistema de archivos sin formato debido a que la sobrecarga de la base de datos, combinada con algunos problemas de confiabilidad de conexión de la base de datos, hizo que el uso de archivos planos fuera una mejor opción.
Algunas preguntas que me preguntaba a mí mismo al tomar la decisión incluyen:
¿Cómo estoy consumiendo los datos? Por ejemplo, ¿acabo de leer desde el principio hasta el final de las filas en el orden ingresado? ¿O estaré buscando filas que coincidan con múltiples criterios?
¿Con qué frecuencia accederé a los datos durante la ejecución de un programa? ¿Iré una vez para obtener todos los libros con Salinger como autor o iré varias veces para obtener varios autores diferentes? ¿Iré más de una vez por varios criterios diferentes?
¿Cómo voy a agregar datos? ¿Puedo agregar una fila hasta el final y eso es perfecto para mi recuperación o será necesario recurrir a ella?
¿Cuán lógico será el código en seis meses? Hago hincapié en esto porque creo que con demasiada frecuencia esto se olvida en el diseño de las cosas (no solo en el código, este hobby es en realidad de mis días como mecánico de la Marina maldiciendo a los ingenieros mecánicos). En seis meses, cuando tenga que mantener su código (o lo haga después de trabajar en otro proyecto), la forma de almacenar y recuperar datos tendrá más sentido. Si pasar de archivos planos a una base de datos da como resultado una mejora de la eficiencia del 1%, pero agrega una semana para resolver las cosas cuando tiene que actualizar el código, ¿realmente ha mejorado las cosas?
¿Puede agregar qué herramienta usaría si tuviera preguntas? Parece que el patrón es: si la primera parte de la pregunta es sí, entonces use un archivo, si es el segundo use un DB, pero no estoy seguro. – mbigras
Depende de cuál es su información y cuáles son sus patrones de acceso y escala. Dos de los mayores beneficios de las bases de datos relacionales son:
Almacenamiento en caché. A menos que sea muy hábil, no puede escribir un caché tan bueno como el de un servidor de base de datos
Optimizador.
Sin embargo, para ciertas aplicaciones especializadas, ninguno de estos 2 beneficios manifestarse en comparación con los archivos + almacén de datos carpetas - por lo tanto, la respuesta es un rotundo "depende".
En cuanto a los archivos/carpetas, los trucos son:
Tengo que estar en desacuerdo con mucho de lo que has escrito: 1) El almacenamiento en caché en un servidor de bases de datos tiene que ser genérico. Si escribe su propio conocimiento específico de aplicación dado, debería poder golpearlo sin problemas. 2) Optimizador: una vez más, el optimizador debe ser genérico; con el conocimiento específico de la aplicación puede codificar rutas de acceso significativamente más eficientes, también puede utilizar estructuras no disponibles dentro de las opciones típicas de indexación RDBMS. 3) Los directorios grandes solo son más lentos si tiene que 'buscar' archivos; si tiene una ruta completa a un archivo, no necesitará "leer el contenido de un directorio grande". –
@Sinan - OK, colorearme necesitando sacudida de café. ¿Qué hace alusión a los problemas "específicos de CGI" en cuanto a DB vs archivos? – DVK
@ Craig - No sé cuáles son sus patrones de uso. Incluso lo que son sus datos. Entonces sus puntos pueden o no ser válidos, depende. ¿Pero su estructura de archivos personalizada sabe acerca de colocar la mayoría de los datos usados en áreas más rápidas del disco? ¿Eres un experto en escribir buenos cachés?es por eso que dije "depende" - sin conocer los detalles de su aplicación, no estoy preparado para juzgar de una manera u otra sobre lo fácil que es escribir una estructura basada en archivos personalizada para sus necesidades que superará al DB – DVK
Depende del perfil de los datos y la lógica que va a utilizar para acceder a ellos. Si simplemente necesita guardar y recuperar nodos con nombre, entonces una base de datos basada en el sistema de archivos puede ser más rápida y más eficiente. (También podría echar un vistazo a Berkeley DB para ese propósito). Si necesita hacer búsquedas basadas en índices, y especialmente si necesita unir diferentes conjuntos de datos basados en claves, entonces una base de datos SQL es su mejor opción.
Simplemente elegiría la solución que parezca más natural para su aplicación.
Como regla general, las bases de datos son más lentas que los archivos.
Si necesita indexar sus archivos, una ruta de acceso codificada en estructuras de indexación personalizadas siempre tendrá el potencial de ser más rápida si lo hace correctamente.
Pero el "rendimiento" no es el objetivo al elegir una base de datos en una solución basada en archivos.
Debe preguntarse si su sistema necesita alguno de los beneficios que proporcionaría una base de datos. Si es así, la pequeña sobrecarga de rendimiento es bastante aceptable.
Así:
Básicamente, la pregunta es más de lo que sería más fácil de desarrollar. La diferencia de rendimiento entre los dos no vale la pena perder tiempo de desarrollo.
Yo agregaría que el beneficio de rendimiento solo existe si sabes lo que estás haciendo. Crear un esquema de indexación bueno y rápido no es fácil. Las bases de datos han tenido varios años para ajustar sus algoritmos, incluso si son datos genéricos. La mayoría de las personas que conozco que intentan superar una base de datos con archivos planos no lo logran. Pero hay algunos que tienen éxito en el raro caso de que lo necesites. – mpeters
Como han señalado otros: ¡depende!
Si usted realmente necesita saber cuál va a ser más eficaz para sus propósitos, puede generar algunos datos de muestra para almacenar en cada formato y luego ejecutar algunos puntos de referencia. El módulo Benchmark.pm viene con Perl, y hace que sea bastante sencillo de hacer una comparación lado a lado con algo como esto:
use Benchmark qw(:all) ;
my $count = 1000; # Some large-ish number of trials is recommended.
cmpthese($count, {
'File System' => sub { ...your filesystem code... },
'Database' => sub { ...your database code... }
});
Puede escribir perldoc Benchmark para obtener la documentación más completa.
Como han dicho otros, depende: en el tamaño y la naturaleza de los datos y las operaciones que planea ejecutar en él.
En particular, para un script CGI , usted va a incurrir en un golpe de rendimiento para la conexión a un servidor de base de datos en cada página vista. Sin embargo, si crea un enfoque ingenuo basado en archivos, podría crear fácilmente peores problemas de rendimiento ;-)
Además de una solución Berkeley DB File, también podría considerar usar SQLite. Esto crea una interfaz SQL para una base de datos almacenada en un archivo local. Puede acceder a él con DBI y SQL, pero no hay servidor, configuración o protocolo de red. Esto podría permitir una migración más fácil si un servidor de base de datos es necesario en el futuro (ejemplo: si decide tener múltiples servidores de aplicaciones para el usuario, pero necesita compartir el estado).
Sin conocer ningún detalle, sugeriría usando una solución SQLite/DBI y luego revisar el rendimiento. Esto le dará flexibilidad con una puesta en marcha razonablemente simple y un rendimiento decente.
Para acceder rápidamente a los archivos, dependiendo de lo que esté haciendo, un mmap puede ser muy útil. Acabo de escribir sobre esto en el blog Effective Perl como Memory-map files instead of slurping them.
Sin embargo, espero que un servidor de base de datos sea mucho más rápido. Es difícil decir qué sería más rápido para usted cuando no tenemos idea de lo que está haciendo, a qué tipo de datos necesita acceder, y así sucesivamente.
Desde mi pequeña experiencia, las bases de datos basadas en servidor (incluso aquellas servidas en la máquina local) tienden a tener un rendimiento muy lento en comparación con los sistemas de archivos locales. Sin embargo, esto depende de algunas cosas, una de las cuales es la complejidad asintótica. Al comparar el escaneo de una gran lista de archivos con el uso de una base de datos con un índice para buscar un elemento, la base de datos gana.
Mi experiencia es poco con PostgreSQL. Tenía una mesa con tres millones de filas y fui a actualizar solo 8,000 registros. Tardó 8 segundos.
En cuanto a la frase "La optimización prematura es la raíz de todos los males". Me gustaría tomarlo con un grano de sal. Si escribe su aplicación usando una base de datos, entonces descubra que es lenta, puede tomar una gran cantidad de tiempo cambiar a un enfoque basado en el sistema de archivos u otra cosa (por ejemplo, SQLite). Yo diría que su mejor opción es crear un prototipo muy simple de su carga de trabajo, y probarlo con ambos enfoques. Creo que es importante saber cuál es más rápido en este caso.
Es muy útil utilizar archivos en lugar de db cuando se trata de imágenes si la estructura del sitio es adecuada. Cree carpetas que representen sus datos coincidentes y coloque imágenes en su interior. Por ejemplo, tiene un sitio de artículos, almacena sus artículos en db. No tiene que colocar sus rutas de imagen en db, nombrar carpetas con sus claves principales como 1,2,3 .. y poner imágenes dentro. E-books, archivos de música, videos, este enfoque se puede utilizar en todos los archivos multimedia. La misma lógica funciona con archivos xml si no busca algo.
¿Qué piensas hacer con la información? –