mirror of
https://github.com/lancedb/lancedb.git
synced 2026-11-13 22:26:53 +00:00
## Summary - **Define Storage Integration**: un-gates the Python (and Rust, for S3) `create_storage_integration` examples, drafted against #4618 and held back until it shipped -- it's now in v0.42.0-beta.0+, and the signature matches the drafts exactly. - **Naming rules**: drops the `Branch` row and its "Learn more" link, consistent with de-emphasizing branches elsewhere in this nav. - **Distributed RTE Write**: removes the REST path, the `__lance_mem_wal` index name, and "WAL node" terminology in favor of an abstract framing -- a query node routes writes to RTE nodes, each of which can host shards from many different tables. Both diagram variants are updated to match. - **Data Page Cache / Tiered Index Cache / Cache Prewarm**: drop Helm-specific and exact-percentage detail (disk-budget math, `startup_prewarm_block_query_ready`/`healthPort`/failure-policy table) in favor of a short feature → architecture → why-it-matters shape, each closing with a contact-sales pointer. Data Page Cache's on-demand prewarm section is removed outright. ## Note I wasn't able to get a clean visual render of the updated Distributed RTE Write diagram in local preview -- Mermaid isn't rendering in headless Chrome in this environment for *any* page right now, confirmed against an unmodified reference page showing the identical symptom. The diagram source follows the exact pattern already shipped and working in the 21 diagrams from the earlier brand-theming pass, and `mint validate`/`mint broken-links` both pass clean. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
80 lines
3.2 KiB
Plaintext
80 lines
3.2 KiB
Plaintext
---
|
|
title: "Data Page Cache"
|
|
sidebarTitle: "Data Page Cache"
|
|
description: "How LanceDB Enterprise caches table data pages to avoid re-reading object storage."
|
|
icon: "database"
|
|
availability:
|
|
embedded: unavailable
|
|
enterprise: available
|
|
---
|
|
|
|
The data page cache holds fixed-size pages of raw table data read from
|
|
object storage, keyed by their location, so a later read of the same range
|
|
is served from memory or local disk instead of round-tripping to the
|
|
backing store. Plan executors and query nodes each keep their own cache for
|
|
the pages they serve. A background prewarm job can populate a cache ahead
|
|
of a request that needs it, rather than filling it lazily on first read.
|
|
See [Architecture](/index#architecture).
|
|
|
|
<div className="hidden dark:block">
|
|
|
|
```mermaid
|
|
%%{init: {"theme": "base", "themeVariables": {
|
|
"background": "#171513", "primaryColor": "#1e1b19", "primaryTextColor": "#f4ebe8",
|
|
"primaryBorderColor": "#4c443f", "lineColor": "#847770", "textColor": "#f4ebe8",
|
|
"edgeLabelBackground": "#171513", "fontFamily": "Inter, sans-serif", "fontSize": "18px"
|
|
}}}%%
|
|
flowchart LR
|
|
R["Read request<br/>for a data page"] --> M{"In memory?"}
|
|
M -->|hit| Return["Served from memory"]
|
|
M -->|miss| D{"In local disk cache?"}
|
|
D -->|hit| Promote["Loaded into memory,<br/>served"]
|
|
D -->|miss| O[("Object storage")]
|
|
O --> Fill["Fills memory and disk,<br/>served"]
|
|
classDef default fill:#1e1b19,stroke:#4c443f,stroke-width:1px,color:#f4ebe8
|
|
```
|
|
|
|
</div>
|
|
|
|
<div className="block dark:hidden">
|
|
|
|
```mermaid
|
|
%%{init: {"theme": "base", "themeVariables": {
|
|
"background": "#ffffff", "primaryColor": "#ffffff", "primaryTextColor": "#221d19",
|
|
"primaryBorderColor": "#ad9e95", "lineColor": "#6b625c", "textColor": "#221d19",
|
|
"edgeLabelBackground": "#ffffff", "fontFamily": "Inter, sans-serif", "fontSize": "18px"
|
|
}}}%%
|
|
flowchart LR
|
|
R["Read request<br/>for a data page"] --> M{"In memory?"}
|
|
M -->|hit| Return["Served from memory"]
|
|
M -->|miss| D{"In local disk cache?"}
|
|
D -->|hit| Promote["Loaded into memory,<br/>served"]
|
|
D -->|miss| O[("Object storage")]
|
|
O --> Fill["Fills memory and disk,<br/>served"]
|
|
classDef default fill:#ffffff,stroke:#ad9e95,stroke-width:1px,color:#221d19
|
|
```
|
|
|
|
</div>
|
|
|
|
A table's local disk cache shares one configurable budget with the
|
|
[tiered index cache](/enterprise/tiered-index-cache#disk-budget)'s disk
|
|
tier where both are enabled on the same executor.
|
|
|
|
## Why it matters {#why-it-matters}
|
|
|
|
Object storage is durable and cheap, but every round trip to it adds
|
|
latency and egress cost. For workloads that read the same ranges
|
|
repeatedly -- a hot subset of embeddings, a frequently-filtered column --
|
|
the data page cache turns most of those reads into local memory or disk
|
|
hits instead, so performance stays predictable as traffic grows and you
|
|
pay object storage once per page, not once per read.
|
|
|
|
[Contact us](https://www.lancedb.com/contact) to learn more about how
|
|
caching is sized and tuned for your workload.
|
|
|
|
## Cache interfaces {#interfaces}
|
|
|
|
- [Tiered Index Cache](/enterprise/tiered-index-cache) for the related
|
|
cache that holds deserialized index structures instead of raw data pages.
|
|
- [Query plans](/basics/sql#query-plans) for inspecting what a query actually read.
|