Database Architecture, Concepts, and Design
This domain tests how you reason about a database as layered architecture: the instance (memory plus background processes) versus the database (persistent files), the engine's concurrency model, and how logical design choices such as normalization, indexing, and partitioning map onto Nutanix Database Service (NDB) provisioning and placement decisions.
Core distinctions
- An instance is the running memory and process footprint; a database is the set of physical files. One instance normally mounts one database, while clustered engines (Oracle RAC, SQL Server failover cluster instances or availability groups) blur that boundary.
- NDB automates VM, profile, and storage-policy placement but does not change engine architecture. You still size SGA/PGA, tempdb, or shared_buffers for the engine you provision.
- OLTP design favors third normal form, short transactions, and selective B-tree indexes. Analytics favors star schemas, columnar storage, and partition pruning.
Worked example
A 50-million-row orders table is queried mainly by customer_id plus an order_date range, and inserts are frequent. Keep the table in 3NF, add one composite index on (customer_id, order_date) rather than two single-column indexes, and partition by order_date range only if old data is regularly purged. Reasoning: the composite index matches the predicate order and supports the trailing range; two separate indexes invite an index-merge or bitmap conversion and add write overhead. Partitioning pays only when pruning or retention actually uses the partition key.
Traps
- Treating instance and database as synonyms in architecture questions.
- Adding an index for every column; write amplification and optimizer confusion follow.
- Designing for the engine while ignoring NDB placement, storage policy, and clone behavior.
- Assuming a larger buffer cache fixes a design problem caused by missing predicates or bad data types.