Real-time sensor data in Bigtable shows poor performance. How should you redesign row keys to improve dashboard query performance?

The correct approach is to design row keys with a hashed or rotating prefix to distribute rows evenly across tablets. Bigtable stores data sorted by row key, and uneven distribution (hotspotting) leads to poor performance. A hashed or rotating prefix ensures that related data isn't all written to the same tablet, preventing bottlenecks and improving read/write performance for dashboard queries. Prefixing with a monotonically increasing timestamp (e.g., timestampid) would cause all new data to be written to the same tablet, creating a severe hotspot. Using reverse timestamp prefixes (e.g., reverseTSid) would also lead to hotspotting, as all recent data would still be grouped together, just in reverse order. A short, static row key value (e.g., '') would put all data into a single row, making Bigtable effectively a single-node database and severely limiting scalability and performance.