¿Pero es eso realmente importante? Tenga en cuenta que la IU debe realizar una llamada de red a la API; eso es bastante grande (orden de magnitud de milisegundos). Las bases de datos están optimizadas para mantener las cosas en la memoria y ejecutar lecturas muy, muy rápidamente (por ejemplo, SQL Server carga y mantiene todo en RAM y consume casi toda su RAM libre si puede).
La lógica
En teoría, tienes razón. Sin embargo, hay algunos defectos con esta justificación:
Por lo que dijo, no está claro si realmente probó / perfiló su aplicación. En otras palabras, ¿ sabe realmente que las transferencias de red desde la aplicación a la API son el componente más lento? Como eso es intuitivo, es fácil suponer que lo es. Sin embargo, cuando se habla de rendimiento, nunca debe suponer. En mi empleador, soy el líder de rendimiento. Cuando me uní por primera vez, la gente seguía hablando de CDN, replicación, etc., basada en la intuición sobre cuáles deben ser los cuellos de botella. Resulta que nuestros mayores problemas de rendimiento fueron consultas de bases de datos de bajo rendimiento.
Está diciendo que debido a que las bases de datos son buenas para recuperar datos, que la base de datos se ejecuta necesariamente al máximo rendimiento, se está utilizando de manera óptima y no hay nada que se pueda hacer para mejorarla. En otras palabras, las bases de datos están diseñadas para ser rápidas, por lo que nunca debería tener que preocuparme por eso. Otra peligrosa línea de pensamiento. Es como decir que un automóvil debe moverse rápidamente, por lo que no necesito cambiar el aceite.
Esta forma de pensar supone un proceso único a la vez, o dicho de otra manera, sin concurrencia. Se supone que una solicitud no puede influir en el rendimiento de otra solicitud. Se comparten recursos, como E / S de disco, ancho de banda de red, agrupaciones de conexiones, memoria, ciclos de CPU, etc. Por lo tanto, reducir el uso de un recurso compartido por una llamada de la base de datos puede evitar que otras solicitudes se ralenticen. Cuando me uní a mi empleador actual por primera vez, la gerencia creía que ajustar una consulta de base de datos de 3 segundos era una pérdida de tiempo. 3 segundos es tan poco, ¿por qué perder el tiempo? ¿No estaríamos mejor con un CDN o compresión u otra cosa? Pero si puedo ejecutar una consulta de 3 segundos en 1 segundo, digamos agregando un índice, eso es 2/3 menos de bloqueo, 2/3 menos tiempo dedicado a ocupar un hilo y, lo que es más importante, menos datos leídos del disco,
La teoría
Existe una concepción común de que el rendimiento del software se trata simplemente de velocidad .
Desde una perspectiva puramente rápida, tienes razón. Un sistema es tan rápido como su componente más lento. Si ha perfilado su código y descubrió que Internet es el componente más lento, entonces todo lo demás obviamente no es la parte más lenta.
Sin embargo, dado lo anterior, espero que pueda ver cómo la contención de recursos, la falta de indexación, el código mal escrito, etc. pueden crear diferencias sorprendentes en el rendimiento.
Los supuestos
Una última cosa. Usted mencionó que una llamada a la base de datos debería ser barata en comparación con una llamada de red desde la aplicación a la API. Pero también mencionó que la aplicación y los servidores API están en la misma LAN. Por lo tanto, ¿no son ambos comparables como llamadas de red? En otras palabras, ¿por qué supone que la transferencia de API es un orden de magnitud más lento que la transferencia de la base de datos cuando ambos tienen el mismo ancho de banda disponible? Por supuesto, los protocolos y las estructuras de datos son diferentes, entiendo eso, pero disputo la suposición de que son órdenes de magnitud diferentes.
Donde se pone murkey
Toda esta pregunta es sobre llamadas de base de datos "múltiples" versus "únicas". Pero no está claro cuántos son múltiples. Debido a lo que dije anteriormente, como regla general, recomiendo hacer tan pocas llamadas a la base de datos como sea necesario. Pero eso es solo una regla general.
Aquí es por qué:
- Las bases de datos son excelentes para leer datos. Son motores de almacenamiento. Sin embargo, su lógica empresarial vive en su aplicación. Si establece una regla de que cada llamada a la API da como resultado exactamente una llamada a la base de datos, entonces su lógica empresarial puede terminar en la base de datos. Quizás eso está bien. Muchos sistemas hacen eso. Pero algunos no. Se trata de flexibilidad.
- A veces, para lograr un buen desacoplamiento, desea tener 2 llamadas a la base de datos separadas. Por ejemplo, quizás cada solicitud HTTP se enruta a través de un filtro de seguridad genérico que valida desde la base de datos que el usuario tiene los derechos de acceso correctos. Si lo hacen, proceda a ejecutar la función apropiada para esa URL. Esa función puede interactuar con la base de datos.
- Llamando a la base de datos en un bucle. Es por eso que pregunté cuántos es múltiple. En el ejemplo anterior, tendría 2 llamadas a la base de datos. 2 está bien. 3 pueden estar bien. N no está bien. Si llama a la base de datos en un bucle, ahora ha hecho que el rendimiento sea lineal, lo que significa que tomará más tiempo cuanto más haya en la entrada del bucle. Por lo tanto, decir categóricamente que el tiempo de red de la API es el más lento pasa por alto por completo las anomalías, como que el 1% de su tráfico tarda mucho tiempo debido a un bucle aún no descubierto que llama a la base de datos 10,000 veces.
- A veces hay cosas en las que su aplicación es mejor, como algunos cálculos complejos. Es posible que deba leer algunos datos de la base de datos, hacer algunos cálculos y luego, según los resultados, pasar un parámetro a una segunda llamada a la base de datos (tal vez para escribir algunos resultados). Si los combina en una sola llamada (como un procedimiento almacenado) solo por llamar a la base de datos una sola vez, se ha obligado a usar la base de datos para algo en lo que el servidor de aplicaciones podría ser mejor.
- Equilibrio de carga: tiene 1 base de datos (presumiblemente) y múltiples servidores de aplicaciones con equilibrio de carga. Por lo tanto, cuanto más trabaje la aplicación y menos haga la base de datos, más fácil será escalar porque generalmente es más fácil agregar un servidor de aplicaciones que configurar la replicación de la base de datos. Según el punto anterior, puede tener sentido ejecutar una consulta SQL, luego hacer todos los cálculos en la aplicación, que se distribuye en varios servidores, y luego escribir los resultados cuando haya terminado. Esto podría proporcionar un mejor rendimiento (incluso si el tiempo total de la transacción es el mismo).
TL; DR
TLDR: ¿Es realmente importante preocuparse por las llamadas a múltiples bases de datos cuando ya estamos haciendo una llamada de red a través de LAN? Si es así, ¿por qué?
Sí, pero solo hasta cierto punto. Debe intentar minimizar el número de llamadas a la base de datos cuando sea práctico, pero no combine las llamadas que no tienen nada que ver entre sí solo por el hecho de combinarlas. Además, evite llamar a la base de datos en un bucle a toda costa.