Almacenamiento Cloud Bigtable: Elegir entre SSD y HDD

Cuando creamos una instancia y un clúster de Cloud Bigtable, elegimos si deseamos almacenar los datos del clúster en unidades de disco duro (HDD) o unidades de estado sólido (SSD):

• El almacenamiento Cloud Bigtable SSD es la elección más rentable y eficiente para la mayoría de los casos de uso.
• El almacenamiento en HDD a veces es apropiado para conjuntos de datos muy grandes (> 10 TB) que no son sensibles a la latencia o que se accede con poca frecuencia.

Independientemente del tipo de almacenamiento que elijamos, nuestros datos se almacenarán en un sistema de archivos distribuido y replicado que se extiende a través de varias unidades físicas.

Las pautas en este post nos pueden ayudar a elegir entre SSD y HDD.

En caso de que tengamos duda, elijamos el almacenamiento SSD

Hay diversas razones por las que por lo general es mejor usar almacenamiento SSD para su clúster de Cloud Bigtable:

SSD tiene un rendimiento más predecible que HDD y es significativamente más rápido. En un clúster Cloud Bigtable, el almacenamiento SSD brinda latencias de 6 ms para las escrituras y lecturas para el 99% de todas las solicitudes.

Por el contrario, el almacenamiento en disco duro ofrece latencias de escritura de 50 ms y latencias de lectura de 200 ms en el mismo punto de referencia.

El rendimiento de HDD es bastante más limitado que el rendimiento de SSD. En un clúster que utiliza almacenamiento HDD, es simple alcanzar el rendimiento máximo antes de que el uso de la CPU llegue al 100%.

Para subir el rendimiento, debemos agregar más nodos, pero el costo de los nodos adicionales puede exceder fácilmente sus ahorros al usar almacenamiento en HDD.

El almacenamiento SSD no tiene esta limitación, ya que ofrece mucho más rendimiento por nodo: por lo general, un clúster que usa almacenamiento Cloud Bigtable SSD alcanza el rendimiento máximo solo cuando usa toda la CPU y la memoria disponibles.

Las lecturas de filas individuales en HDD son muy lentas. Debido al tiempo de búsqueda de disco, el almacenamiento en disco duro solo permite el 5% de la QPS de almacenamiento Cloud Bigtable de SSD. A pesar de ello, los escaneos de varias filas grandes no se ven tan afectados.

El ahorro de costes del disco duro es mínimo, en relación con el coste de los nodos en su clúster Cloud Bigtable, a menos que guarde grandes cantidades de datos.

Por esta razón, como regla general, no debe pensar en el uso de almacenamiento HDD a menos que esté almacenando al menos 10 TB de datos.

Casos de uso para almacenamiento Cloud Bigtable HDD

El almacenamiento en HDD es adecuado para casos de uso que cumplan los siguientes criterios:

• Espera almacenar al menos 10 TB de datos.
• No utilizará los datos para respaldar una aplicación sensible al usuario o sensible a la latencia.
• Principalmente ejecutará cargas de trabajo por lotes con escaneos y escrituras, en lugar de ejecutar con frecuencia lecturas aleatorias de un número pequeño de filas.

Por ejemplo, si planea almacenar datos históricos extensos para una gran cantidad de dispositivos de detección remota y luego utilizar los datos para generar informes diarios, el ahorro de costos para el almacenamiento Cloud Bigtable en HDD puede justificar la compensación del rendimiento.

Por otro lado, si planea usar los datos para mostrar un tablero de instrumentos en tiempo real, probablemente no tendría sentido usar el almacenamiento de HDD: las lecturas serían mucho más frecuentes en este caso, y las lecturas son mucho más lentas con el almacenamiento de HDD.

Cambiar entre almacenamiento Cloud Bigtable SSD y HDD

Cuando crea una instancia y un clúster Cloud Bigtable, su elección de almacenamiento SSD o HDD para el clúster es permanente. No puede usar Google Cloud Platform Console para cambiar el tipo de almacenamiento que se utiliza para el clúster.

Si necesita convertir un clúster de HDD existente a SSD, o viceversa, puede exportar los datos de la instancia existente e importar los datos en una nueva instancia. Alternativamente, puede escribir un trabajo de Cloud Dataflow o Hadoop MapReduce que copie los datos de una instancia a otra. Tenga en cuenta que la migración de una instancia completa llevará tiempo y requerirá más nodos Cloud Bigtable que los clústeres de su instancia normalmente.

A continuación dejamos una lista de temas de Cloud Bigtable que también pueden resultarte interesantes de leer:

• Puedes ver una introducción y caracteristicas generales en Cloud Bigtable: Introducción y características generales
• Para crear una instancia en Cloud te recomendamos Crear una instancia de Cloud Bigtable
• Si quieres saber que tipo de almacenamiento elegir, mira: Instalación de Cloud SDK para Cloud Bigtable