¿Cuál es la latencia DENTRO de un centro de datos? Pregunto esto asumiendo que hay órdenes de magnitud de diferencia


17

Estoy tratando de descubrir algo para lo que simplemente no puedo encontrar una buena respuesta.

Si he dicho un caché REDIS (o algún caché externo en memoria) ubicado en un centro de datos, y un servidor de aplicaciones ubicado en el mismo centro de datos, ¿cuál será la velocidad de la conexión de red (latencia, rendimiento) para leer datos entre estas dos máquinas?

¿La "velocidad" de la red, por ejemplo, seguirá siendo al menos un orden de magnitud mayor que la velocidad de la RAM que busca mis datos fuera de la caché en REDIS?

Mi última pregunta es: ¿tener todo esto en memoria en REDIS realmente proporciona alguna utilidad? En contraste con si REDIS estaba almacenando todo esto en un SSD? La memoria es cara. Si la red no es un cuello de botella DENTRO del centro de datos, entonces la memoria tiene valor. De lo contrario, no lo hace.

Supongo que mi pregunta general es a pesar de las grandes incógnitas en los centros de datos y la incapacidad de generalizar, así como las variaciones, ¿estamos hablando de órdenes de magnitud suficientes entre la latencia de la memoria en un sistema informático e incluso las mejores redes internas de un DC que la memoria ¿Las latencias reducidas no proporcionan una mejora significativa del rendimiento? Entiendo que hay muchas variables, pero ¿qué tan cerca está? ¿Está tan cerca que estas variables son importantes? Por ejemplo, adopte una postura hiperbólica, una unidad de cinta es MUCHO más lenta que la red, por lo que la cinta no es ideal para un caché.


1
También depende de la cantidad de viajes de ida y vuelta por transacción, a menudo este es el verdadero problema que se serializa en una secuencia de consultas. Una interfaz de consulta más compleja, un procedimiento del lado del servidor o un caché denormalizwd pueden reducir el impacto.
Eckes

Respuestas:


19

Hay varias versiones de los "gráficos de latencia que todos deberían conocer", tales como:

La cuestión es que, en realidad, hay más que solo latencia. Es una combinación de factores.

Entonces, ¿cuál es la latencia de red dentro de un centro de datos? Latencia, bueno yo diría que es "siempre" por debajo de 1 ms. ¿Es más rápido que la RAM? No. ¿Está cerca de la RAM? No lo creo.

Pero la pregunta sigue siendo relevante. ¿Es ese el dato que necesitas saber? Tu pregunta tiene sentido para mí. Como todo tiene un costo, debe obtener más RAM para que todos los datos puedan permanecer en la RAM o está bien leer de disco de vez en cuando.

Su "suposición" es que si la latencia de la red es mayor (más lenta) que la velocidad de la SSD, no obtendrá ganancias al tener todos los datos en la RAM, ya que tendrá la lentitud en la red.

Y parece que sí. Pero también debes tener en cuenta la concurrencia. Si recibe 1,000 solicitudes de datos a la vez, ¿puede el disco hacer 1,000 solicitudes concurrentes? Por supuesto que no, entonces, ¿cuánto tiempo tomará atender esas 1,000 solicitudes? En comparación con la RAM?

Es difícil reducirlo a un solo factor, como cargas pesadas. Pero sí, si tuviera una sola operación, la latencia de la red es tal que probablemente no notará la diferencia de SSD frente a RAM.

Al igual que hasta que apareció un disco de 12 Gbps en el mercado, un enlace de red de 10 Gbps no se sobrecargaría con una sola transmisión, ya que el disco era el cuello de botella.

Pero recuerde que su disco está haciendo muchas otras cosas, su proceso no es el único proceso en la máquina, su red puede transportar cosas diferentes, etc.

Además, no toda la actividad del disco significa tráfico de red. La consulta de la base de datos que proviene de una aplicación al servidor de la base de datos es solo un tráfico de red muy mínimo. La respuesta del servidor de la base de datos puede ser muy pequeña (un solo número) o muy grande (miles de filas con múltiples campos). Para realizar la operación, un servidor (servidor de base de datos o no) puede necesitar realizar múltiples búsquedas, lecturas y escrituras en el disco, pero solo enviar un pequeño bit de regreso a través de la red. Definitivamente no es uno-por-uno-red-disco-RAM.


Hasta ahora evité algunos detalles de su pregunta, específicamente, la parte de Redis.

Redis es un almacén de estructura de datos en memoria de código abierto (licencia BSD), que se utiliza como agente de base de datos, caché y mensaje. - https://redis.io/

OK, eso significa que todo está en la memoria. Lo sentimos, este disco SSD rápido no te ayudará aquí. Redis puede conservar los datos en el disco, por lo que puede cargarse en la RAM después de un reinicio. Eso es solo para no "perder" datos o tener que repoblar un caché en frío después de un reinicio. Entonces, en este caso, tendrá que usar la RAM, pase lo que pase. Tendrá que tener suficiente RAM para contener su conjunto de datos. No hay suficiente RAM y supongo que su sistema operativo usará swap, probablemente no sea una buena idea.


Gracias. Esto es realmente útil. De hecho, hay muchas variaciones contextuales aquí que tienen relación con esto. Si ignoramos las cargas pesadas por un momento, parece por su respuesta que, de hecho, la latencia de la red es el cuello de botella, por lo que la latencia adicional de SSD vs RAM simplemente no es lo suficientemente importante como para importar. Pero ahora, si tenemos en cuenta las cargas pesadas, las diferencias de latencia de ese SSD en relación con la RAM comienzan a agravarse, y ahora, la RAM brillará. ¿Es esto a lo que se reduce entonces?
Neeraj Murarka

1
Es difícil reducirlo a un solo factor de cargas pesadas. Pero sí, si tuviera una sola operación, la latencia de la red es tal que probablemente no notará la diferencia de SSD frente a RAM. Al igual que hasta que apareció un disco de 12 Gbps en el mercado, un enlace de red de 10 Gbps no se sobrecargaría con una sola transmisión, ya que el disco era el cuello de botella. Pero recuerde que su disco está haciendo muchas otras cosas, su proceso no es el único proceso en la máquina, etc.
ETL

1
Tenga en cuenta también que hay muchos otros factores a considerar además de la latencia, en particular que la mayoría de los servicios reales necesitan ejecutar múltiples instancias del programa del servidor en diferentes máquinas, por lo que "todo en la RAM localmente" normalmente no es una opción práctica.
chrylis -on strike-

Pero un enlace de red de 10 g es de gama baja. Mis servidores están conectados a mi red troncal con 200 gigabit (sí, enlaces 2x100g).
TomTom

3

Hay muchas capas de caché en los sistemas informáticos. Insertar uno en la capa de aplicación puede ser beneficioso, almacenando en caché las consultas de la base de datos y la API. Y posiblemente datos temporales como sesiones de usuario.

Los almacenes de datos como Redis proporcionan dicho servicio a través de una red (rápida) o un socket UNIX (incluso más rápido), de forma muy similar a como usaría una base de datos.

Debe medir el rendimiento de su aplicación, pero inventemos un ejemplo. Digamos que una solicitud de usuario común realiza 5 consultas API que toman 50 ms cada una. 250 ms es latencia detectable por el usuario. Contraste al almacenamiento en caché de los resultados. Incluso si el caché está en una zona de disponibilidad diferente en la ciudad (no es óptima), los hits son probablemente de 10 ms como máximo. Lo que sería una aceleración de 5x.

En realidad, la base de datos y los sistemas de almacenamiento también tienen sus propios cachés. Sin embargo, por lo general, es más rápido obtener un resultado previamente obtenido que volver a pasar por el motor de la base de datos y las capas del sistema de almacenamiento. Además, la capa de almacenamiento en caché puede quitar una carga significativa de la base de datos detrás de ella.

Para ver un ejemplo de este tipo de caché en producción, no busque más que el blog de infraestructura Stack Overflow sobre arquitectura . Cientos de miles de solicitudes HTTP que generan miles de millones de visitas de Redis son bastante significativas.

La memoria es cara.

La DRAM a tiempos de acceso de 100 ns es aproximadamente 100 veces más rápida que el almacenamiento permanente en estado sólido. Es relativamente barato para este rendimiento. Para muchas aplicaciones, un poco más de RAM compra una velocidad y un tiempo de respuesta valiosos.


¿Puede aclarar cómo calculó que cada una de esas 5 consultas API toma 50 ms cada una? Es bajo la apariencia de que la aplicación golpea la base de datos y hace la consulta y calcula el conjunto de resultados, en lugar de simplemente golpear un caché en toda la ciudad que resulta haber almacenado en caché la cadena de consulta como la clave, y tener una copia en caché de ese resultado ¿conjunto?
Neeraj Murarka

1
Hice esos números, pero sí. Es probable que hacer una consulta y calcular un resultado nuevamente sea más lento que obtener ese resultado precalculado. Las implementaciones como Redis tienden a estar en memoria por simplicidad y velocidad. Atravesar una red IP o el transporte de sockets UNIX también puede ser bastante rápido. Dicho todo esto, este material de almacenamiento en caché no es necesario para todos los diseños.
John Mahowald

Entendido. Creo que lo entiendo más o menos. Parece que en muchos casos, pero no todo el tiempo, incluso si se desplaza fuera del centro de datos a un caché cercano que tal vez esté en el mismo estado de EE. UU. (O provincia canadiense, etc.) (tal vez la región es una buena semántica) a menudo Sería una gran ventaja sobre el proceso que intenta volver a calcular el valor algorítmicamente a partir de su propia base de datos local, si de hecho resulta en un acierto de caché. Pero entonces, el caché que podría estar sentado de forma remota no ofrece mucho valor al estar en la memoria. También puede estar basado en SSD.
Neeraj Murarka

1
El centro de datos remoto es el peor de los casos, idealmente el nivel de caché está a menos de 1 ms de sus clientes. Quizás la misma zona de disponibilidad, o incluso en el mismo host. Puede almacenar en caché a un almacenamiento persistente si lo desea. O bien, puede usar ese almacenamiento de estado sólido para la base de datos primaria, acelerar todas las consultas y posiblemente no necesite un nivel de almacenamiento en caché. Hay múltiples diseños posibles.
John Mahowald
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.