¿Cuándo es el tamaño de la llamada a la base de datos más caro que la frecuencia de las llamadas?

Question

¿Alguien me puede dar una idea relativa de cuándo tiene más sentido golpear la base de datos muchas veces para obtener resultados de consultas pequeños frente al almacenamiento en caché de un gran número de filas y consultas?

Por ejemplo, si tengo una consulta que devuelve 2.000 resultados. Y luego tengo consultas adicionales sobre esos resultados que toman tal vez 10-20 elementos, ¿sería mejor guardar en caché los resultados de 2000 o acceder a la base de datos cada vez para cada conjunto de 10 o 20 resultados?

Answer 1

Otras respuestas aquí son correctas: el RDBMS y sus datos son factores clave. Sin embargo, otro factor clave es cuánto tiempo tomará clasificar y/o indexar sus datos en memoria versus en la base de datos. Tenemos una aplicación en la que, para el rendimiento, agregamos código para tomar aproximadamente 10,000 registros en una memoria DataSet y luego hacemos subconsultas en eso. Como resultado, mantener esos datos actualizados y seleccionar subconjuntos es realmente más lento que simplemente dejar todos los datos en la base de datos.

Así que mi consejo es: hágalo de la manera más simple posible, luego perfórelo y vea si necesita optimizar el rendimiento.

Answer 2

Esto probablemente varía de RDBMS a RDBMS, pero mi experiencia ha sido que tirar a granel es casi siempre mejor. Después de todo, tendrá que sacar los 2000 registros de todos modos, por lo que también podría hacerlo todo a la vez. Y 2000 registros no es realmente una gran cantidad, pero eso depende en gran medida de lo que está haciendo.

Mi consejo es hacer un perfil y ver qué funciona mejor. Los RDBMS pueden ser bestias difíciles en cuanto a rendimiento y el almacenamiento en caché puede ser igual de complicado.

Answer 3

El tipo de datos que trae también afecta la decisión. No desea almacenar en caché los datos o datos volátiles para posibles actualizaciones que pueden quedar obsoletas.

Answer 4

Depende de una variedad de cosas. Voy a enumerar algunos puntos que vienen a la mente:

• Si usted tiene una aplicación web .Net que se caché de datos en el cliente, que no quiero tirar de 2k filas.

• Si tiene un servicio web, casi siempre son mejores Chunky que Chatty debido a la sobrecarga adicional de XML en el transporte.

• En una base de datos bastante decentemente normalizada y optimizada, realmente debería haber muy pocas veces que tenga que extraer 2k filas a la vez a menos que esté haciendo informes.

• Si los datos subyacentes están cambiando a un ritmo rápido, entonces realmente debe tener cuidado al guardarlos en el nivel medio o en la capa de presentación, porque lo que presente estará desactualizado.

• Los informes (cualquier DSS) extraerán y procesarán conjuntos de datos mucho más grandes, pero dado que no son interactivos, los desnormalizamos y les permitimos que se diviertan.

• En casos de desplegables en cascada, las técnicas AJAX demostrarán ser más eficientes y efectivas.

Creo que realmente no le doy una respuesta a su pregunta. "Depende" es lo mejor que puedo hacer.

Answer 5

En general, la latencia de ida y vuelta de red es varios órdenes de magnitud mayor que la capacidad de una base de datos para generar y alimentar datos en la red y la capacidad de un cliente para consumirla desde una conexión de red.

Pero mira a la anchura de su bus de red (bits/seg) y que para comparar el tiempo de ida y vuelta promedio para una llamada base de datos ...

En Ethernet 100BaseT, por ejemplo, que están a unos 12 MBytes/velocidad de transferencia de datos sec Si su tiempo promedio de ida y vuelta es, por ejemplo, 200 ms, su bus de red puede entregar 3 MBytes en cada llamada de ida y vuelta de 200 ms ..

Si está en gigabit ethernet, ese número salta a 30 Mbytes por viaje redondo ...

Así que si divide una solicitud de datos en dos viajes de ida y vuelta, bueno eso es 400 ms, y cada consulta debería tener más de 3Mb (o 30Mb para gigibit) antes de que sea más rápido ...

Answer 6

"Supongo que realmente no le doy una respuesta a su pregunta". Depende "es lo mejor que puedo hacer".

sí, "depende". Depende de la volatilidad de los datos que tiene la intención de almacenar en caché, y depende del nivel de "precisión" y confiabilidad que necesita para las respuestas que genera a partir de los datos que tiene la intención de almacenar en caché.

Si la volatilidad en sus datos "base" es baja, entonces cualquier almacenamiento en caché que realice en esos datos tiene una mayor probabilidad de permanecer válido y corregir durante un tiempo más prolongado.

Si "caching-fault-tolerance" en los resultados que devuelve a los usuarios es cero por ciento, no tiene opción.

Answer 7

A menos que haya un gran problema de rendimiento (por ejemplo, una conexión db altamente latente), me quedaré con dejar los datos en la base de datos y dejar que el DB se encargue de usted. Muchas cosas se hacen de manera eficiente en el nivel de base de datos, por ejemplo

• niveles de aislamiento (lo que ocurre si otras transacciones actualizan los datos que está caching)
• acceso rápido mediante índices (el PP puede ser más rápido acceda a algunas filas de las que busca en los elementos en caché, especialmente si esos datos ya están en la memoria caché de db como en su escenario)
• actualizaciones en su transacción a los datos en caché (¿desea tratar la actualización de sus datos en caché como bien o "actualizar" todo desde el db)

Hay muchos problemas potenciales que puede encontrar si hace su propio almacenamiento en caché. Debe tener una muy buena razón de rendimiento antes de comenzar a ocuparse de toda esa complejidad.

Entonces, la respuesta corta: depende, pero a menos que tenga algunas buenas razones, esto me huele a una optimización prematura.