Velocidad de acceso de archivos frente a la velocidad de acceso a la base de datos

Question

El sitio que estoy desarrollando en php hace que muchas solicitudes de bases de datos MySQL por página sean vistas. Aunque muchas son pequeñas solicitudes con índices diseñados correctamente. No sé si valdrá la pena desarrollar un script de caché para estas páginas.

1) ¿La E/S de archivos generalmente es más rápida que las solicitudes de bases de datos? ¿Esto depende del servidor? ¿Hay alguna forma de probar cuántos de cada servidor puede manejar?

2) Una de las páginas verifica un nombre de archivo en la base de datos, luego verifica si el servidor existe y luego decide qué mostrar. ¿Supongo que esto se beneficiaría de una vista de página en caché?

También, si hay alguna otra información sobre este tema que pueda enviarme a eso, sería muy apreciada.

Gracias

Answer 1

Si está accediendo a la lectura (buscando nombres de archivos, etc.) puede beneficiarse del memcached. Puede almacenar los datos "más recientes" (más recientemente creados, usados ​​recientemente, según su aplicación) en la memoria, y luego solo consultar el DB (y posiblemente los archivos) cuando el caché falla. El acceso a la memoria es mucho, mucho más rápido que la base de datos o los archivos.

Si necesita acceso de escritura pesada, una base de datos es el camino a seguir. Si está utilizando MySQL, use tablas InnoDB u otro motor que admita el bloqueo a nivel de fila.Eso evitará que las personas bloqueen mientras otra persona escribe (o, lo que es peor, escribe de todos modos).

Pero en última instancia, depende de los datos.

Answer 2

Esto realmente depende de muchos factores. Si tiene una base de datos rápida con muchos datos almacenados en caché en la memoria RAM o en un sistema RAID rápido, es probable que gane mucho con el simple almacenamiento en caché del sistema de archivos en el servidor web. También piensa en la escalabilidad. Bajo una gran carga de trabajo, un simple mecanismo de almacenamiento en caché puede convertirse fácilmente en un cuello de botella, mientras que una base de datos está bien diseñada para manejar grandes cargas de trabajo.
Si no hay tantas solicitudes y usted (o el sistema operativo) puede mantener la memoria caché en la memoria RAM, es posible que pueda obtener algún rendimiento. Pero ahora surge la pregunta, si es realmente necesario realizar el almacenamiento en caché con poca carga de trabajo.

Answer 3

Depende de cómo se estructuren los datos, cuánto hay y con qué frecuencia cambia.

Si tiene cantidades relativamente pequeñas, de datos relativamente estáticos con relaciones relativamente simples, entonces los archivos planos son la herramienta adecuada para el trabajo.

Las bases de datos relacionales se vuelven suyas cuando las conexiones entre los datos son más complejas. Para las "tablas de búsqueda" básicas, pueden ser un poco exageradas.

Pero, si los datos cambian constantemente, entonces puede ser más fácil simplemente usar una base de datos en lugar de manejar la administración de configuración a mano, y para grandes cantidades de datos, con archivos planos, tiene el problema adicional de ¿Cómo encuentras el bit que necesitas de manera eficiente?

Answer 4

Desde una perspectiva de rendimiento simple, es más sensato sintonizar el servidor de la base de datos y no complicar la lógica de acceso a los datos con cachés de archivos intermedios. Un buen servidor de base de datos haría el almacenamiento en caché por sí solo si los resultados son almacenables. (No estoy seguro de cuál es el caso con mysql).

Si tiene problemas de rendimiento, debe perfilar las páginas para ver los cuellos de botella reales. Incluso cuando eres -como yo- un entusiasta de los códigos optimizados, poner un hardware más fuerte/más en la ecuación es más barato a largo plazo.

Si aún necesita usar cachés, considere usar una solución existente, como memcached.