1. Hierarchical Layers of a Modern Database Structure
A database structure defines the systematic organization of data across logical schema definitions, in-memory data structures, and physical non-volatile storage layouts. Database engineering separates the logical representation of information from its underlying byte-level persistence. This architectural separation is known as physical data independence. It allows application developers to query logical entities using declarative SQL statements without manually managing disk sector offsets, memory pointers, or file system blocks.
At the logical tier, a relational database structure organizes information into catalogs, schemas, tables, views, columns, and tuples. Tables enforce strict structural regularity by requiring every row to conform to predefined column data types, length limits, and integrity constraints. Primary keys uniquely identify individual tuples within a table, while foreign keys establish relational links between separate tables. At the physical tier, the storage engine maps these logical tables into operating system files, data extents, fixed-size or variable-size pages, and memory cache buffers.
2. Physical Storage Layouts: Page-Oriented vs. Log-Structured Engines
The physical database structure governs how tuple bytes are arranged on disk to optimize read throughput, write latency, and storage space utilization. Traditional relational engines utilize a page-oriented storage structure based on B+ trees. In a page-oriented layout, disk files are divided into fixed-size pages, typically 8 kilobytes or 16 kilobytes in length. Each page contains a header with metadata, an array of row offset pointers, and the actual serialized tuple payloads. When an application updates a column value in place, the storage engine locates the target page in memory, modifies the byte offset, and eventually flushes the entire dirty page back to disk. While B+ tree page structures provide fast point lookups, frequent random updates cause severe page fragmentation and disk write amplification.
To overcome random write bottlenecks, modern high-concurrency databases implement a Log-Structured Merge-tree (LSM-tree) physical database structure. An LSM-tree engine avoids overwriting disk blocks in place. Instead, incoming inserts, updates, and deletes are appended sequentially to a write-ahead log (WAL) and inserted into a sorted in-memory structure called a MemTable. Once the MemTable reaches its capacity threshold, the engine flushes the sorted data sequentially to disk as an immutable Sorted String Table (SSTable). Background compaction processes periodically merge multiple SSTable layers to discard obsolete tuple versions and reclaim disk capacity, converting random I/O into high-throughput sequential disk writes.
3. Row-Oriented, Column-Oriented, and Indexing Structures
Within physical storage blocks, the internal data layout can follow a row-oriented (N-ary Storage Model), column-oriented (Decomposition Storage Model), or hybrid PAX (Partition Attributes Across) structure. A row-oriented database structure stores all attributes of a single tuple contiguously inside a data block. This layout is optimal for Online Transaction Processing (OLTP) workloads that insert, update, or fetch entire records by primary key. Conversely, a column-oriented structure stores values of a single column contiguously across thousands of rows. Columnar organization enables high data compression ratios—such as dictionary encoding and run-length encoding—and accelerates Online Analytical Processing (OLAP) aggregations that scan only a subset of columns using vectorized CPU execution.
Auxiliary indexing structures accelerate data retrieval by bypassing full table scans. Primary indexes dictate the physical sort order of the underlying table tuples, whereas secondary indexes store only the indexed column values alongside pointers to the corresponding primary key or row identifier. Beyond standard B-tree and LSM-tree scalar indexes, modern multimodal database structures incorporate inverted indexes for full-text search and hierarchical proximity graphs (such as HNSW) for high-dimensional vector similarity traversal.
4. Distributed Sharding and Multi-Replica Partition Topologies
When data volumes and transaction concurrency exceed the hardware limits of single-server machines, the database structure expands horizontally across a distributed cluster. Distributed databases divide logical tables into horizontal partitions known as shards or tablets using hash, range, or list partitioning strategies. Each tablet functions as an independent structural unit containing its own local storage blocks and index trees.
To ensure high availability and fault isolation, the distributed database structure replicates each tablet across multiple physical server nodes located in distinct availability zones. Consensus protocols such as Paxos or Raft bind the replicas of each tablet into a synchronized state machine. A global metadata catalog tracks the physical node placement of every partition replica across the cluster, enabling distributed query optimizers to route execution fragments directly to the relevant storage nodes.
5. OceanBase Unified Distributed Database Structure
OceanBase implements an enterprise-grade, distributed database structure built upon a native Log-Structured Merge-tree (LSM-tree) storage engine and a shared-nothing multi-tenant architecture. At the cluster topology level, OceanBase horizontally partitions user tables into granular tablets. Every tablet is managed by an autonomous Paxos consensus group across isolated fault zones, ensuring zero data loss (RPO = 0) and sub-8-second automated failover (RTO < 8s) without relying on shared disk hardware. Furthermore, OceanBase's multi-tenant structure allows a single cluster to host multiple isolated virtual database instances, each provisioned with dedicated CPU threads, memory pools, and storage quotas.
At the physical storage layer, OceanBase organizes each tablet using a tiered LSM-tree structure consisting of an in-memory MemTable and immutable disk-based SSTables. Each SSTable is subdivided into 2-megabyte macroblocks, which are further segmented into variable-size microblocks. Within these microblocks, OceanBase supports a hybrid row-column storage structure (PAX) alongside independent columnar replicas. Using fine-grained encoding and adaptive compression algorithms, OceanBase reduces storage footprints by up to 70 percent compared to traditional page-based engines. Moreover, OceanBase natively embeds high-dimensional vector indexes alongside relational B-tree structures within the same storage kernel, empowering enterprises to execute transactional OLTP, real-time OLAP analytics (HTAP), and AI vector retrieval within a single unified database structure.
