Dispositivos de E/S y problemas de latencia

Dispositivos de E/S y latencia

• Los dispositivos de almacenamiento no volátil son un componente clave de los sistemas informáticos modernos, ya que pueden almacenar datos incluso cuando se apaga la energía. A diferencia de los dispositivos de almacenamiento volátil como los registros de CPU, la caché de CPU y la RAM, no requieren suministro eléctrico continuo.

Dispositivos de almacenamiento en cinta

• Desde la década de 1950, las computadoras han utilizado unidades de cinta para el almacenamiento digital no volátil. La cinta es adecuada para almacenar largas secuencias de datos y resulta ideal en situaciones donde se necesita guardar grandes volúmenes de datos de forma segura, pero no es necesario leerlos con frecuencia.
• La cinta ofrece bajo costo y larga vida útil, y todavía se usa en grandes repositorios de datos como los de CERN y AWS.

Unidades de disco duro (HDD)

• Las unidades de disco duro ofrecen un acceso a los datos más rápido que la cinta y almacenan la información en discos metálicos circulares. Toda la superficie del disco está siempre disponible, lo que reduce la latencia al leer y escribir datos.
• Los HDD admiten command queueing, lo que permite ejecutar múltiples comandos en paralelo.

Unidades de estado sólido (SSD)

• Las unidades de estado sólido leen y escriben datos de forma electrónica, sin componentes mecánicos, y utilizan NAND flash para ofrecer almacenamiento no volátil.
• Los SSD pueden optimizar el rendimiento mediante procesamiento en paralelo y recolección de basura. La disposición de los datos puede afectar el rendimiento.

Almacenamiento en la nube

• El movimiento hacia la nube ha traído cambios en el rendimiento de E/S, y muchas empresas han migrado sus servidores y sistemas de bases de datos a la nube.
• En entornos de nube, la separación entre almacenamiento y cómputo es común, lo que ofrece seguridad y flexibilidad para los datos, pero puede provocar degradación del rendimiento.

Separación entre almacenamiento y cómputo

• Tradicionalmente, los servidores usaban dispositivos de almacenamiento no volátil conectados directamente, pero en la nube es común conectar el almacenamiento a través de la red.
• El almacenamiento conectado por red ofrece seguridad para los datos, pero puede afectar negativamente el rendimiento de E/S.

Almacenamiento local vs. en red

• Los SSD NVMe locales ofrecen velocidades de E/S muy altas y menor latencia que el almacenamiento conectado por red.
• El almacenamiento conectado por red puede tener limitaciones en las operaciones de E/S, lo que puede llevar a una disminución del rendimiento.

Solución: Metal

• Metal es una solución de PlanetScale que utiliza unidades SSD NVMe conectadas directamente para ofrecer un rendimiento sobresaliente y escalabilidad.
• Los clústeres de Metal están compuestos de forma predeterminada por un servidor principal y dos réplicas, lo que garantiza la durabilidad de los datos y permite ampliar fácilmente la capacidad de almacenamiento.
• Las bases de datos Metal no tienen límites artificiales en las operaciones de E/S y pueden realizarlas con una latencia mínima.

[GN⁺]

Comentario de Hacker News

• Menciona que el autor del blog claramente se divirtió mucho escribiendo este artículo. Creó visuales interactivos usando miles de líneas de JavaScript
• Señala que ha apoyado SQLite+NVMe desde hace mucho tiempo. Esto representa un patrón nuevo, con potencial para resolver problemas sin escalado horizontal
  • En los problemas de rendimiento, la latencia es lo más importante
  • Es aún más importante especialmente cuando las cosas deben procesarse de forma secuencial
  • Ejecutar SQLite sobre NVMe ofrece ventajas de latencia que otros proveedores no pueden ofrecer
  • En la mayoría de los casos de uso reales, ejecutar en memoria no ofrece una ventaja mucho mayor que la persistencia en NVMe
• Elogia lo informativo que fue, al punto de olvidar que era promoción de producto. Menciona los excelentes visuales y la interactividad
• Dice que la animación de IO de disco le recordó a Melvin Kaye
  • Mel no escribía bucles de espera por tiempo
  • Lo mismo ocurría cuando el Flexowriter necesitaba una demora entre caracteres de salida
  • Colocaba las instrucciones en el tambor para que quedaran justo detrás del cabezal de lectura cada vez que se necesitaran
  • El tambor tenía que dar una vuelta completa para encontrar la siguiente instrucción
• Comenta que el blog es bueno. En general, señala que el almacenamiento en la nube es "anormalmente lento"
  • Menciona que recientemente añadió soporte para almacenar índices incrementales en S3/object storage
  • Dice que siguió usando NVMe por más tiempo debido a las ventajas de rendimiento mencionadas en un artículo anterior
  • Expresa que ojalá alguien revolucione este espacio con una mejor oferta
• Señala un punto sobre el almacenamiento distribuido que este artículo no cubre lo suficiente
  • Algunos sistemas básicamente no admiten replicación
  • Un clúster de Cassandra y MySQL pueden hacer replicación master-slave, pero muchos sistemas no
  • Al usar almacenamiento NVMe en la nube, hay que respetar las ventanas de mantenimiento y los drenajes iniciados por la nube
  • Separar el almacenamiento del cómputo permite al operador cloud mover el cómputo según sea necesario
  • Como los datos son independientes del cómputo, el operador cloud puede administrar el sistema de datos y los drenajes
• Metal se ve muy bien. Menciona que en un trabajo anterior intentaron usar SSD locales de instancia de GCP y tuvieron problemas graves de confiabilidad
  • Había un problema donde bloques del dispositivo perdían datos
  • Se pregunta si esta situación ha mejorado
  • Pregunta qué tipo de máquina están usando
  • Menciona como solución usar el disco de red de Discord
• PlanetScale Metal se ve muy sólido. Siempre es interesante ver grandes reducciones de latencia en un lanzamiento
• Es un artículo excelente. La visualización de escrituras aleatorias está muy bien lograda
  • Otro problema del almacenamiento conectado por red en la nube son los límites de IOPS
  • Muchos proveedores cloud, incluyendo AWS y Google Cloud, usan este modelo y limitan la cantidad de operaciones de IO que se pueden enviar
  • Si el almacenamiento está conectado directamente a la instancia de cómputo, no hay límites artificiales sobre las operaciones de IO
  • Se puede leer y escribir tan rápido como lo permita el hardware
  • Se pregunta si el límite de "IOPS" es una limitación sobre cierto tráfico de red
  • Pregunta si se refiere al tráfico de red del volumen EBS
  • Se pregunta si permite ahorrar costos, si se debe al extraño arbitraje de AWS, o si gana eficiencia al hacer menos networking de EBS
  • Ve claramente que poner almacenamiento y cómputo en la misma máquina tiene ventajas en latencia
  • También se pregunta si hay ventajas en rendimiento por costo
• Se pregunta cómo los proveedores de bases de datos "serverless" publicitan acceso de "baja latencia"
  • Usan object storage como S3, que se esperaría que tuviera una latencia mucho peor que el almacenamiento de red
  • Menciona que construyeron una capa de caché y que mantendrán los datos en NVMe conectado localmente