Databases, Tables and Columns: Difference between revisions
No edit summary |
Wikiservice (talk | contribs) (Refresh MemCP documentation: accuracy, operational guidance, performance profile and maintained API reference) |
||
| Line 1: | Line 1: | ||
<!-- Copyright (C) 2026 Carl-Philip Haensch --> | |||
<!-- SPDX-License-Identifier: GPL-3.0-or-later --> | |||
= Databases, Tables and Columns = | |||
A database is a catalog entry and namespace. With the local backend it normally corresponds to a directory below the configured data path. A JSON backend configuration can instead map it to S3-compatible object storage or optional Ceph/RADOS. | |||
A table contains its logical schema and one or more shards. Ordinary columns have stored values; computed and order-dependent columns have logical definitions whose physical caches may be created, repaired, invalidated, or evicted. SQL views store a SELECT definition and are expanded before logical planning. | |||
Each table selects one of the <code>safe</code>, <code>logged</code>, <code>sloppy</code>, <code>memory</code>, or reconstructible <code>cache</code> engines. This changes durability and eviction semantics, not the SQL column types. See [[Persistency and Performance Guarantees]] before changing an existing table's ENGINE. | |||
Primary, unique, and adaptive secondary indexes are represented separately from the column values. User and hidden triggers enforce constraints or maintain derived structures. Physical scans obtain shard access and read columns in batches; application code should use SQL rather than depending on internal shard or record-ID representation. | |||
See [[Shards, RecordIDs, Main Storage, Delta Storage]], [[Columnar Storage]], and [[Storage Backends]]. | |||
Latest revision as of 11:59, 28 August 2026
Databases, Tables and Columns
A database is a catalog entry and namespace. With the local backend it normally corresponds to a directory below the configured data path. A JSON backend configuration can instead map it to S3-compatible object storage or optional Ceph/RADOS.
A table contains its logical schema and one or more shards. Ordinary columns have stored values; computed and order-dependent columns have logical definitions whose physical caches may be created, repaired, invalidated, or evicted. SQL views store a SELECT definition and are expanded before logical planning.
Each table selects one of the safe, logged, sloppy, memory, or reconstructible cache engines. This changes durability and eviction semantics, not the SQL column types. See Persistency and Performance Guarantees before changing an existing table's ENGINE.
Primary, unique, and adaptive secondary indexes are represented separately from the column values. User and hidden triggers enforce constraints or maintain derived structures. Physical scans obtain shard access and read columns in batches; application code should use SQL rather than depending on internal shard or record-ID representation.
See Shards, RecordIDs, Main Storage, Delta Storage, Columnar Storage, and Storage Backends.