¿Múltiples accesos a bases de datos o un acceso masivo?

¿Cuál es un mejor enfoque cuando se trata del rendimiento y la utilización óptima de los recursos: acceder a una base de datos varias veces a través de AJAX para obtener solo la información exacta necesaria cuando es necesario, o realizar un acceso para recuperar un objeto que contiene toda la información que podría ser necesaria , con una alta probabilidad de que no todo sea realmente necesario?

Sé cómo comparar las consultas reales, pero no sé cómo probar qué es lo mejor cuando se trata del rendimiento de la base de datos cuando miles de usuarios acceden a la base de datos simultáneamente y cómo entra en juego la agrupación de conexiones.

No hay una respuesta correcta a esto; como cualquier optimización, depende en gran medida del contexto / uso.

Sin embargo, considere lo siguiente como regla general:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

Recuerde la primera regla de optimización: medir, no adivinar . Pruebe ambos, instruméntelos con algún tipo de código de cronómetro y vea qué lleva más tiempo.

Y también tenga en cuenta la vieja broma de que "solo hay dos problemas difíciles en informática: la invalidación de caché y nombrar bien las cosas". Si extrae todo de la base de datos a la vez y lo guarda en la memoria, tiene un caché. Y ahora tiene un nuevo problema: cada vez que algo cambia en cualquier parte del sistema , tiene que hacer el mismo cambio en dos lugares: la base de datos y el caché. Si tiene más de un servidor hablando con la base de datos, o varias API para que el servidor modifique los datos, esto puede volverse muy complicado muy rápidamente.

No hay solución de bala de plata para esta pregunta. Supongo que debe PROBAR las posibles compensaciones y ajustar su (s) servidor (es) para lograr lo mejor.

Primer punto: antes de comenzar a realizar cualquier mejora, debe establecer su punto de referencia de rendimiento actual , medirlo y tomarlo como punto de referencia en comparación con las posibles soluciones para mejorarlo.

La segunda cosa es que el uso de la aplicación debe ser rastreado. La forma en que los usuarios finales utilizan la aplicación. Reducir los números sin procesar de datos devueltos que no son necesarios para los usuarios finales puede ahorrarle muchos recursos valiosos del servidor . Por ejemplo: no tiene sentido devolver 5000 registros mientras los usuarios están interesados ​​en los primeros 50.

Tercer punto: debe comprender la frecuencia de las llamadas y las posibles implicaciones. Por ejemplo: si la mayoría de las llamadas son consultas de tabla de valores de búsqueda, entonces probablemente podría crear una infraestructura para almacenar en caché estas llamadas . En otras palabras, si sus datos no cambian con frecuencia, considere la opción de almacenamiento en caché. Y, por supuesto, minimizar el número de llamadas siempre debería ayudar a aumentar el rendimiento.

Obtener todo de una vez le dará un mejor rendimiento, a menos que "todo" incluya cosas como BLOB u objetos de datos de gran tamaño similar. El rendimiento general para serializar todo, moverlo a través del cable y luego deserializarlo en el otro extremo es bastante significativo, con una latencia de red muy importante. La memoria es más barata que el ancho de banda de la red, y probablemente lo seguirá siendo por un tiempo todavía. Su única respuesta real vendrá de un punto de referencia, pero si solo está tratando de medir uno sobre el otro, esa es la forma en que me inclinaría.

Si está tomando una decisión arquitectónica, REST es una opción. Con REST, siempre solicita un recurso varias veces, es decir, no envía una solicitud para obtener 2 objetos porque cada objeto tiene su propia URL. La preocupación por el rendimiento al hacer este estilo probablemente se resolverá cuando salga HTTP / 2.0. De lo contrario, simplemente se optimiza para hacerlo lo más rápido posible. Muchas empresas lo están haciendo de esta manera.