mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-19 02:02:27 +00:00
Jack Ye
cd0ebe3d12
Namespace and Table were the only objects behind a nested group. Both are now a single page like Database, Materialized view, View and Function, so Manage is a flat list of the things a catalog holds. Namespace merges its two pages, which were a concept page and a usage page for the same object. Table is a new page. The old tables/index was a 672-line basic-usage tutorial whose every section had acquired a better home during the restructure -- connecting, ingesting, searching, filtering, adding and dropping columns -- to the point that its own Next steps cards pointed at the pages that superseded it. It is replaced by a table object page: what a table carries, create, open, list, rename, clone, drop, and links out. Schema evolution, versioning and branching stay as siblings rather than folding in. Merging them would have made one 1,800-line page, which is not what the other object pages look like.
79 lines
3.4 KiB
Plaintext
79 lines
3.4 KiB
Plaintext
---
|
|
title: "Lakehouse and catalog"
|
|
sidebarTitle: "Lakehouse & Catalog"
|
|
description: "What a multimodal lakehouse holds, and how the catalog organizes it."
|
|
icon: sitemap
|
|
keywords: ["lakehouse", "catalog", "database", "namespace", "table", "view", "function"]
|
|
---
|
|
|
|
LanceDB is a **multimodal lakehouse**: data sits in open [Lance](/basics/lance)
|
|
tables on object storage, and a catalog gives those tables names, structure, and
|
|
the operations that act on them.
|
|
|
|
The lakehouse part is why images, embeddings, and the columns you derive from
|
|
them live in one table rather than in a warehouse plus a vector store plus a
|
|
feature store. The catalog part is what this page is about.
|
|
|
|
## The objects {#objects}
|
|
|
|
| Object | What it is |
|
|
| --- | --- |
|
|
| [Database](/management/database) | The root. A connection opens exactly one. |
|
|
| [Namespace](/management/namespace) | A named grouping inside a database. Can nest. |
|
|
| [Table](/management/table) | Rows and columns, versioned. What most operations act on. |
|
|
| [Materialized view](/feature-engineering/materialized-views) | A table whose contents come from a query, computed and stored. |
|
|
| [View](/management/view) | A saved query. Computed when read, not stored. |
|
|
| [Function](/management/function) | Registered code, applied to produce column values. |
|
|
|
|
```
|
|
database
|
|
└── namespace
|
|
├── table
|
|
├── materialized view (a table, defined by a query)
|
|
├── view (a query, not stored)
|
|
└── function
|
|
```
|
|
|
|
A namespace can contain further namespaces, so the hierarchy goes as deep as you
|
|
need. A table is reached by its path through it.
|
|
|
|
This page is about what the objects *are*. For the operations on them --
|
|
connecting, creating, listing, dropping -- see [Management](/management).
|
|
|
|
## A table is more than rows {#tables}
|
|
|
|
A Lance table carries things a warehouse table does not, and most of the rest of
|
|
these docs is about one of them:
|
|
|
|
| | |
|
|
| --- | --- |
|
|
| **Columns** | including vectors, blobs, and columns [computed](/feature-engineering/add-computed-column) from other columns |
|
|
| **Versions** | every write commits one, so reads can [travel back](/tables/versioning) |
|
|
| **Indexes** | vector, full-text, and scalar, built over the columns |
|
|
| **Branches** | isolated lines of change you can [merge or discard](/tables/branching) |
|
|
|
|
That is why "add a feature column" is a normal operation here rather than a
|
|
migration: it writes one new column and leaves the expensive data alone.
|
|
|
|
## Views and materialized views are different objects {#views}
|
|
|
|
The names are close enough to mislead. Both are defined by a query over other
|
|
tables; the difference is when that query runs.
|
|
|
|
- A **materialized view** stores its rows. A refresh computes them, and reads are
|
|
reads of stored data -- fast, and as current as the last refresh.
|
|
- A **view** stores only the query. Every read runs it, so a view is never stale
|
|
and never faster than the query it wraps.
|
|
|
|
Reach for a materialized view when the query is expensive and the data changes
|
|
less often than it is read. Reach for a view when correctness matters more than
|
|
latency, or when the query is cheap.
|
|
|
|
## What is not a catalog object {#elsewhere}
|
|
|
|
**Indexes** belong to a table rather than standing alone, and creating one is a
|
|
performance decision -- see [Maintenance](/indexing).
|
|
|
|
**Jobs** are not stored data at all; they are handles to work the server is
|
|
doing. See [Query and job](/basics/jobs).
|