Cómo aprovechar las unidades de estado sólido en aplicaciones de bases de datos
En los últimos años, el rendimiento de las SSD ha mejorado drásticamente mientras que los costes han seguido disminuyendo en comparación con los discos duros y la RAM tradicionales. Sin embargo, para aprovechar al máximo estas mejoras es necesario dominar las funciones de almacenamiento, elegir el tamaño de instancia de AWS adecuado, comprender las funciones de la aplicación y utilizar el lenguaje de programación adecuado.
Dominar las opciones de AWS
Las instancias AWS IaaS EC2 se pueden configurar con diferentes niveles de almacenamiento:
A) RAM. Equivalente a la RAM de un ordenador físico tradicional.
B) Almacenamiento de instancias. También llamado almacenamiento temporal. Es equivalente al tamaño de disco de una computadora física tradicional.
C) Almacenamiento suplementario persistente flexible (como EBS y S3). Básicamente, considérelo como un almacenamiento de red para su PC física.
Amazon actualmente utiliza SSD como configuración predeterminada para implementar almacenamiento efímero y de uso general, así como EBS (los tipos de instancias anteriores no usaban SSD de forma predeterminada).
Además, AWS hace que el almacenamiento SSD sea la opción predeterminada para Amazon DynamoDB, y SSD también es opcional para Amazon RDS y Amazon
Redshift. La ventaja de esta configuración es que puede reducir los costos de desarrollo necesarios para las aplicaciones de bases de datos. Sin embargo, si una empresa necesita implementar bases de datos adicionales, existen muchas otras configuraciones que pueden ayudarla
aprovechar el paralelismo de los SSD.
La física del almacenamiento paralelo
Las computadoras físicas generalmente están configuradas con tres tipos principales de almacenamiento: la RAM se instala en la placa base junto a la CPU, que proporciona el mayor rendimiento al mismo tiempo. costo más alto y el Contenido no se conserva después de apagar la computadora.
Los SSD y los discos duros tradicionales son dispositivos de almacenamiento complementarios que se conectan a una computadora, conectados mediante cables PCI-e, SCSI y SATA, o mediante una red eSATA o Fibre Channel.
Un disco duro tradicional contiene un cabezal físico de lectura/escritura que puede leer flujos de datos en múltiples platos físicos al mismo tiempo. Este modo es ideal si los datos se pueden leer secuencialmente (como leer archivos multimedia de audio y video de gran tamaño) o para ciertas aplicaciones de análisis de bases de datos (como aplicaciones Hadoop). Sin embargo, si la lectura de datos implica buscar en múltiples sectores del plato, el rendimiento de los cabezales de lectura/escritura de los discos duros tradicionales cae drásticamente.
Por el contrario, la estructura física de una unidad flash consta de cientos de bloques accesibles aleatoriamente, distribuidos en muchos chips, por lo que el bloque de datos que se lee no afecta el rendimiento del acceso. Las unidades flash tienen dos cuellos de botella: el controlador de memoria entre el procesador de la computadora y el área de memoria de un solo chip y la incapacidad de leer simultáneamente datos aleatorios de diferentes bloques en un solo chip;
La mayoría de los motores de bases de datos hoy en día no tienen la capacidad de acceder a bits aleatorios de datos mediante una unidad flash. El resultado es que la base de datos es más lenta o, aunque sus patrones de acceso se pueden almacenar en caché, requiere más RAM para lograr el mismo efecto de rendimiento. El almacenamiento RAM es ciertamente más rápido que una unidad flash, pero la RAM cuesta diez veces más que una unidad flash por la misma cantidad de espacio de almacenamiento. A nivel físico, la RAM tiene más potencia de procesamiento IO que el SSD, pero también cuesta entre tres y cuatro veces más. Estos costos relativos también se reflejan en los costos relativos de diferentes instancias informáticas en Amazon Web Services.
Cola de escritura
Para aprovechar al máximo la capacidad de acceder a datos en paralelo en varios chips, la clave es tener en cuenta las características de profundidad de la cola al escribir el programa. El aumento de la profundidad de la cola en las aplicaciones de bases de datos permite que las aplicaciones lean y escriban datos de diferentes chips individuales del SSD en paralelo, lo que tiene un impacto directo en la mejora del rendimiento de la base de datos.
Si la profundidad de la cola se establece demasiado alta, aumenta la probabilidad de acceder a diferentes bits de datos desde el mismo chip, lo que también puede afectar el rendimiento. Por lo tanto, la profundidad de cola óptima para la mayoría de las aplicaciones es de 32 a 64 solicitudes simultáneas por unidad, aunque las propias unidades admiten muchas más solicitudes simultáneas. Al optimizar la profundidad de la cola de las aplicaciones de bases de datos que acceden a los SSD, las aplicaciones pueden lograr un mayor rendimiento a un menor costo que solo sería posible con una RAM más costosa.
A nivel de aplicación, los desarrolladores deben considerar cómo poner en cola las solicitudes de la aplicación al sistema de almacenamiento para lograr un procesamiento paralelo. Sin embargo, existen muchos obstáculos en el software para lograr un mejor paralelismo.
Los lenguajes de programación como JavaScript, Ruby y Python tienen dificultades para lograr el paralelismo porque no soportan bien el multihilo, mientras que Java y C# lo tienen relativamente fácil.
C y C++ son los lenguajes de programación más adecuados para implementar código de sistema altamente concurrente porque pueden operar directamente las funciones centrales del sistema operativo. Por ejemplo, la extensión mutex (también conocida como mutex) es una característica del lenguaje que simplifica la programación y genera llamadas paralelas al sistema de bajo nivel. Otra opción es utilizar una base de datos comercial que venga con su propia optimización de almacenamiento SSD, como Aerospike.
Elija la arquitectura adecuada para su aplicación
No todas las aplicaciones de bases de datos requieren capacidades de memoria flash para acceder a datos aleatorios en paralelo. Las bases de datos que manejan una gran cantidad de solicitudes web simultáneas de usuarios pueden aprovechar fácilmente los mayores beneficios de la memoria flash.
Por el contrario, las aplicaciones analíticas como Hadoop son paralelas en cierto sentido, pero a menudo estas aplicaciones terminan necesitando acceder a grandes flujos de datos en la unidad de almacenamiento para completar el acceso a los datos. Por ejemplo,
Procesar los registros de usuarios de un mes para analizar su comportamiento o crear perfiles de usuarios implica básicamente la extracción secuencial de datos, por lo que pasar a SSD no aporta muchos beneficios. Entre estos dos extremos, existen aplicaciones de tipo análisis en tiempo real
que requieren tanto una cierta cantidad de búsqueda aleatoria como de procesamiento de flujo de datos.
Los expertos sugieren que una forma de aprovechar las diferencias de costos entre los diferentes niveles es configurar su base de datos para que los datos se lean utilizando almacenamiento temporal para un rendimiento óptimo. Esto se puede lograr haciendo una copia de seguridad de los datos almacenados en la capa de datos persistentes de EBS. Esta opción proporciona la combinación mejor equilibrada de precio y rendimiento en AWS.
También es necesario considerar los procesos back-end.
Hay otras características sutiles que los arquitectos de aplicaciones de bases de datos deben considerar. Comprender cómo el software de su base de datos utiliza la RAM y descarga los datos en el disco es importante para optimizar la configuración de su aplicación SSD. Igualmente importante es evaluar las diversas formas en que la base de datos interactúa con el sistema de archivos. Las cargas de lectura pesadas más obvias generarán mucha contención de E/S en segundo plano. Otros procesos, como los sistemas de informes y la generación de archivos de registro, deben mantenerse en segundo plano.
Para encontrar el equilibrio adecuado, los expertos recomiendan comparar las implementaciones del mundo real con métricas sólidas para utilizarlas como referencia. Esto puede ayudar a las organizaciones a determinar los beneficios de implementar y optimizar sistemas SSD. Sin embargo, la consideración más importante al elegir entre RAM y SSD es comprender bien el tamaño del conjunto de datos que desea procesar.
Configurar la capacidad adecuada de SSD y RAM Hay muchas combinaciones que pueden agregar complejidad a su base de datos.
Los sistemas de bases de datos más tradicionales implementan un servidor primario y múltiples servidores de respaldo para la recuperación de fallas, y otras configuraciones son simples excepto la configuración a nivel de disco. Los sistemas de bases de datos distribuidas, por otro lado, tienen más variaciones según la cantidad de nodos, la capacidad de RAM y la configuración de la red.
Aunque en la mayoría de los casos, si se centra en la potencia de la tecnología y la operatividad del sistema de base de datos al seleccionar un controlador de hardware, debería haber relativamente pocos sistemas que requieran una evaluación comparativa.