In-memory tier overview

The in-memory tier is a cluster-level setting that uses specialized nodes. Before you read this page, understand instances, clusters, and nodes. We also recommend that you familiarize yourself with the limitations.

The Bigtable in-memory tier is an integrated memory tier as part of the Bigtable node that enables seamless, cost-optimized data tiering based on access patterns and performance needs, all through a single API. Using remote direct memory access (RDMA), the Bigtable in-memory tier significantly reduces response times, mitigates hotspots and ensures high throughput for latency-sensitive data. For more information, see Understand performance.

When to use the in-memory tier

We recommend that you enable the in-memory tier for the following use cases:

  • Sub-millisecond latency requirements: workloads that require read latencies of less than 1ms, typically addressed by fronting a database with a self-managed cache solution.
  • High-throughput point reads: applications with high read traffic throughput requirements on specific subsets of data.
  • Hotspot mitigation: high throughput workloads that may include traffic spikes or hotspots on particular row keys.
  • Cost optimization: scenarios where you want to reduce the number of Bigtable nodes by offloading high read volumes to a more cost-effective in-memory tier.

How the in-memory tier works

In-memory tier support is provided by hybrid storage nodes. These specialized nodes extend Bigtable's compute and storage disaggregation to include a memory tier with vertically scalable throughput. Bigtable can take up to 30 minutes to provision the specialized in-memory tier nodes. During this period, Bigtable continues to serve traffic from persistent storage.

You can enable the in-memory tier at the cluster level.

In-memory tier operates as follows:

  • Getting data in the memory tier: the in-memory tier offers read-through caching behavior. A row goes into the memory tier with read operations through an app profile that you configure for the in-memory tier. A write operation from any app profile updates the memory tier if the row data is already in the in-memory tier.
  • Eviction and invalidation policies: the in-memory tier uses Least Recently Used (LRU) eviction at the row level and applies a time to live (TTL) invalidation policy to maximize the in-memory tier hit ratio.