de Martin LE TARNEC.

Tiempo de respuesta, rendimiento y escalabilidad horizontal


Un hardware más grande no significa siempre que sea más rápido, pero generalmente puede manejar más carga. Un hardware más grande es más como una autopista más amplia y no un coche más rápido; no se puede conducir más rápido (¡no se lo permiten!) solamente porque existan más carriles. Esa es la razón por la cual más hardware no mejorará automáticamente sentencias SQL lentas.

Ya no estamos en los años 1990. En aquella época el poder de los servidores de un solo núcleo fue aumentando rápidamente. La mayoría de los problemas de tiempos de respuesta desaparecían con el nuevo hardware solamente porque se incrementó la CPU. Era como si cada año los nuevos modelos de coches fuesen dos veces más rápido que los modelos antiguos. Sin embargo, el poder de un solo núcleo CPU se detuvo durante los primeros años del siglo XXI. Prácticamente ya no existían mejoras en esta dimensión. Para seguir produciendo CPU con más rendimiento, los fabricantes tuvieron que impulsar la tecnología multi-núcleo. Sin embargo, aunque esta tecnología permite múltiples trabajos en ejecución simultáneos, el rendimiento no mejorará si existe solamente un trabajo. El rendimiento no tiene más de una dimensión.

La escalabilidad horizontal (agregando más servidores) tiene las mismas limitaciones. Aunque más servidores pueden procesar más solicitudes, para una sentencia en particular no mejora el tiempo de respuesta. Para hacer la búsqueda más rápida se debe tener una búsqueda del árbol más eficiente, incluso en sistemas no relacionales como CouchDB y MongoDB.

Importante

Indexar correctamente es la mejor manera de reducir los tiempos de respuesta; tanto en las bases de datos SQL relacionales como los sistemas no relacionales.

Indexar correctamente pretende explotar la escalabilidad logarítmica del índice B-tree. Desafortunadamente, la indexación suele realizar de forma descuidada. La gráfica del Impacto del volumen de datos sobre el rendimiento muestra el efecto evidente del descuido en la indexación.

Figura 3.5 Tiempo de respuesta por volumen de datos

La diferencia de tiempo de respuesta entre un índice incorrecto y correcto puede ser enorme. Y difícilmente se puede compensar dicha diferencia agregando más hardware. Aunque se intente reducir el tiempo de respuesta con hardware, es discutible pensar que ésta es la mejor solución para este problema.

Muchos de los llamados sistemas NoSQL aún aseguran resolver todos los problemas de rendimiento con la escalabilidad horizontal. Sin embargo, la escalabilidad es limitada sobre todo para las operaciones de escritura, y donde además se usa la consistencia eventual como modelo de consistencia. Las bases de datos SQL usan un modelo de consistencia estricto que potencialmente frena las operaciones de escritura (para hacerlas consistentes), pero eso no implica necesariamente mal rendimiento. Se aprenderá más acerca de eso en la sección titulada Consistencia eventual y teorema de CAP .

Consistencia eventual y teorema de CAP

Mantener una consistencia estricta en un sistema distribuido requiere una coordinación síncrona de todas las operaciones de escritura entre todos los nodos. Este principio tiene dos efectos desagradables: (1) añade latencia e incrementa los tiempos de respuesta; (2) reduce la disponibilidad total porque los múltiples miembros del sistema distribuido deben estar disponibles al mismo tiempo para finalizar una operación de escritura.

Una base de datos SQL distribuida generalmente está compuesta por una agrupación de servidores ("cluster") que usa un sistema de almacenamiento compartido o replicación de tipo primario-secundario. De hecho, una base de datos distribuida es más como una tienda online, que está integrada con un sistema ERP y generalmente ofrece dos productos diferentes de fabricantes diferentes. La consistencia entre ambos sistemas es todavía una meta atractiva que generalmente se logra usando de commit en dos fases (protocolo 2PC). Este protocolo establece transacciones globales que distribuyen el comportamiento ya famoso del "todo o nada" a través de las múltiples bases de datos. Finalizar una transacción global es solamente posible si todos los miembros activos están disponibles. Esto reduce la disponibilidad global.

Cuanto más nodos tiene un sistema distribuido, más problemática llega a ser la consistencia estricta. Mantener la consistencia estricta es casi imposible si el sistema tiene más de unos pocos nodos. Si se renuncia a la consistencia estricta, se resuelve sin embargo el problema de la disponibilidad del incremento del tiempo de respuesta. La idea fundamental es volver a establecer la consistencia global después de haber finalizado la operación de escritura sobre un subgrupo de los nodos. Esta técnica conlleva deja un problema sin solución: es imposible impedir los conflictos si dos nodos aceptan cambios contrarios. La consistencia se alcanza con la resolución de los conflictos, no evitándolos. En este contexto, consistencia significa que todos los nodos tienen el mismo dato, y no es necesariamente el correcto o el mejor dato.

El Teorema de Brewer o CAP describe las dependencias generales entre Consistencia, Disponibilidad, y la tolerancia al Particionado.

Normalmente, añadir más hardware no mejora los tiempos de respuesta. De hecho, podría hacer el sistema más lento porque la complejidad podría provocar que se añadan más latencias. Las latencias de redes no son el problema si la aplicación y la base de datos se ejecutan sobre el mismo servidor, pero esta configuración es bastante inusual en ambientes de producción en los que la base de datos y la aplicación generalmente se instalan en hardware dedicado. Las políticas de seguridad podrían requerir un cortafuegos entre el servidor de aplicación y la base de datos y, con frecuencia, eso multiplica por dos las latencias de red. Cuanto más compleja es la infraestructura, más latencias se acumulan y más lenta llega a ser la respuesta. Este efecto lleva muchas veces a la observación según la cual el hardware costoso de producción es más lento que el equipo de escritorio barato usado para el desarrollo.

Otra latencia muy importante es el tiempo de búsqueda en el disco. Los discos duros giratorios (en inglés HDD) necesitan bastante tiempo para colocar la parte mecánica hasta que el dato solicitado pueda ser leído, típicamente unos milisegundos. Esa latencia ocurre cuatro veces cuando se recorre un nivel de un B-tree; en total, unas docenas de mili-segundos. Aunque es la mitad de la eternidad para los servidores, sigue estando muy por debajo del umbral de percepción humana...mientras se haga solamente una vez. Sin embargo, es muy fácil desencadenar centenares o miles de tiempos de búsqueda en el disco con una sola sentencia SQL, en particular cuando se juntan múltiples tablas con una operación de unión ("Join"). Aunque la "caché" reduce drásticamente el problema y las nuevas tecnologías, como SSD, reducen el tiempo de búsqueda significativamente, las uniones son, por lo general, sospechosas de ser responsables del mal rendimiento. El siguiente capítulo explicará, por lo tanto, cómo usar índices eficientes para las uniones de tablas.

Si te gusta mi manera de explicar, te encantará mi libro.

Discos de estado sólido (en inglés SSD: Solid State Disks) y la "caché"

Los discos de estado sólido (en inglés: SSD) son una tecnología de almacenamiento masivo que no tiene partes móviles. El típico tiempo de búsqueda de los SSD es significativamente más rápido que el tiempo de búsqueda de los HDD. Los SSD llegaron a estar disponibles para las empresas alrededor del año 2010 pero, debido a su costo excesivo y tiempo de vida limitado, no suelen utilizarse frecuentemente para las bases de datos.

Sin embargo, las bases de datos a menudo tienen acceso a la "caché" en la memoria principal. Es particularmente útil para los datos que son necesarios por cada acceso al índice; por ejemplo, el nodo raíz del índice. La base de datos podría almacenar en su totalidad los índices más usados en la "caché" para que la búsqueda ("lookup") del índice no desencadene ni un sólo tiempo de búsqueda.

Hechos

  • El rendimiento tiene dos dimensiones: tiempo de respuesta y capacidad.

  • Más hardware no mejora el tiempo de respuesta de una sentencia.

  • Indexar correctamente es la forma óptima para mejorar el tiempo de respuesta de una sentencia.

Acerca del autor

Foto de Markus Winand

Markus Winand enseña eficientemente SQL, en casa y online. Minimiza el tiempo de desarrollo utilizando moderno SQL y optimiza el tiempo de ejecución con indexación inteligente. Para ello también ha publicado el libro SQL Performance Explained.

“Use The Index, Luke” de Markus Winand se halla bajo licencia Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Aspectos legales | Contacto | SIN GARANTÍA | Marcas | Privacy | CC-BY-NC-ND 3.0 licencia