Los datos de sensores en tiempo real en Bigtable muestran un rendimiento deficiente. ¿Cómo debería rediseñar las claves de fila para mejorar el rendimiento de las consultas del panel?

La opción correcta es diseñar las claves de fila con un prefijo hash/rotatorio para distribuir las filas uniformemente entre las tabletas (por ejemplo, shard-prefix + id). Bigtable almacena los datos en orden de clave de fila. Si las claves de fila aumentan monótonamente (como un timestamp), todas las escrituras se dirigirán a la misma tableta al final del rango de claves, creando un "hotspot" y degradando el rendimiento. Un prefijo hash o rotatorio distribuye las escrituras de manera más uniforme entre las tabletas, evitando hotspots y mejorando el rendimiento de escritura y lectura para consultas de panel que acceden a datos recientes. Prefijar con una marca de tiempo que aumenta monótonamente (timestampid) es incorrecto porque concentra las escrituras en una sola tableta, causando hotspots. Utilizar prefijos de marca de tiempo inversa (reverseTSid) es útil para buscar los datos más recientes, pero aún puede concentrar las escrituras si los datos llegan en orden cronológico, aunque en el otro extremo del rango de claves. Un valor de clave de fila corto y estático ('') es incorrecto porque todas las escrituras irían a la misma fila, lo cual es ineficiente y no permite almacenar datos de sensores distintos.