3. NoSQL Data Models and Database Families

Introduction and Context

NoSQL databases emerged from the need to manage data whose volume, velocity, variety, and distribution exceeded the practical limits of many traditional relational systems. Although relational databases remain essential, modern applications frequently process semi-structured documents, event streams, social relationships, sensor measurements, search indexes, and high-dimensional embeddings. These data types do not all fit naturally into rows and tables governed by a single normalized schema.

The term NoSQL is best understood as a broad family of database technologies rather than as a single alternative to SQL. Some NoSQL systems do not support SQL at all, while others provide SQL-like languages or compatibility layers. Their common characteristic is that they are designed around particular access patterns, distribution strategies, and data models. Consequently, selecting a NoSQL database is not simply a choice between “SQL” and “NoSQL”; it is a decision about how data should be represented, queried, partitioned, replicated, and operated.

For a full-stack developer, data modeling is especially important because the database model influences application architecture, API design, caching, transaction boundaries, testing, and operational cost. A poor model may produce excessive network requests, inefficient queries, difficult migrations, or unpredictable performance even when the selected database is technically powerful. This chapter examines the principal NoSQL families—key-value, document, wide-column, graph, time-series, search, vector, and multimodel databases—and develops a framework for comparing them.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain why NoSQL databases use multiple data models.

2. Distinguish the structural and operational characteristics of major NoSQL database families.

3. Compare query mechanisms, scalability patterns, consistency choices, and transaction capabilities.

4. Select a suitable database family for a specified application workload.

5. Design an access-pattern-oriented model for a practical system.

6. Evaluate the risks, governance requirements, and operational implications of NoSQL adoption.

7. Explain the roles of search, time-series, vector, and multimodel technologies in contemporary applications.

From a Single Database Model to a Family of Models

A data model defines how information is represented and how relationships among data items are expressed. In a relational model, information is organized into tables with defined columns and relationships represented through keys. NoSQL models relax or replace some of these assumptions. They may permit flexible structures, embed related data, distribute records across many machines, or optimize for a narrow class of queries.

The central design principle is workload alignment. A database should be selected according to the questions an application must answer and the rates at which it must read and write data. For example, an online shopping cart often needs very fast access to one customer’s current state. A graph database, with its explicit relationship traversal, is more suitable for discovering connections among users, products, and recommendations. A time-series database is optimized for measurements ordered by time, whereas a search engine is designed for linguistic analysis, relevance ranking, and filtering.

NoSQL systems commonly achieve scalability through horizontal distribution. Data is partitioned across nodes, often by a partition key, and copies may be maintained through replication. This approach increases capacity and availability but introduces design concerns such as partition skew, cross-partition queries, eventual consistency, and operational complexity. The appropriate model therefore depends not only on the logical shape of data but also on latency requirements, failure tolerance, update patterns, and the acceptable level of consistency.

The Access-Pattern-First Approach

Traditional database design often begins with entities and relationships and then derives tables. NoSQL design frequently begins with application access patterns. The designer asks:

• Which records will be read together?
• What are the most frequent queries?
• Which attributes determine partition placement?
• How large can a record become?
• Which data changes independently?
• Is the workload read-heavy, write-heavy, or mixed?
• Must an operation be strongly consistent across several records?

This method may lead to denormalization, duplication, precomputed views, or separate structures for different queries. Duplication is not automatically poor design in a distributed database; it may reduce joins and network round trips. However, duplicated data creates update responsibilities and can become inconsistent if change propagation is not carefully designed.

A useful evaluation framework considers six dimensions: data shape, query language, scaling method, consistency and transaction model, operational workload, and suitability for the business problem. The sections that follow apply this framework to the major database families.

Key-Value Databases: Simplicity at High Speed

A key-value database stores a value identified by a unique key. The key may be a string, number, or structured identifier, while the value may be an opaque byte sequence, a JSON object, or another application-defined representation. The database generally supports operations such as put, get, update, and delete.

The model resembles a distributed dictionary. Its strength is predictable lookup by key, often with very low latency and high throughput. It is well suited to sessions, shopping carts, feature flags, user preferences, rate-limit counters, authentication tokens, and caching. Values can sometimes have expiration times, allowing temporary information to be removed automatically.

The principal limitation is that the database usually does not provide rich queries over the contents of values. If an application needs all customers whose spending exceeds a threshold, a pure key-value model may require an external index or application-side scanning. Relationships among values are also not naturally represented. The application must therefore know the key or maintain additional access structures.

Key design is critical. A key should be stable, unique, appropriately distributed, and meaningful enough for operational diagnosis. If many requests target one key, that key can become a hot spot. Conversely, poorly designed keys may make related data difficult to retrieve efficiently. Composite keys, prefixes, and controlled randomization are common strategies, but they must be chosen according to actual access patterns.

Document Databases: Flexible Aggregates

Document databases store records as documents, commonly represented using JSON or a binary JSON format. A document may contain scalar fields, nested objects, and arrays. Unlike a relational row, a document can represent an entire application aggregate, such as an order with its delivery address and line items.

Documents provide a natural fit for web and mobile applications because application objects can often be serialized directly into the database. They support queries on fields inside documents, secondary indexes, sorting, aggregation, and—in many systems—transactions involving one or several documents. Schemas may be flexible, but flexibility does not eliminate the need for design discipline. Different document versions should be managed deliberately, and important fields should have documented meanings and validation rules.

Embedding is appropriate when related data is commonly read together, has a bounded size, and does not require independent lifecycle management. An order’s line items may be embedded because the order is usually displayed as one unit. Referencing is preferable when a related entity is large, shared by many documents, updated frequently, or queried independently. For example, a product catalog may be referenced by orders rather than copied without control.

Document databases scale horizontally through partitioning, often using a shard key. A poor shard key can create uneven distribution or route many operations to one partition. Queries that span many partitions may be slower and more expensive than targeted queries. Document systems therefore reward models that align document boundaries and shard keys with common operations.

Wide-Column Databases: Distributed Tables for Known Queries

Wide-column databases organize data into rows identified by a partition key, with columns grouped or stored flexibly within each row. They differ from relational systems in their distribution model and query constraints. Columns may vary between rows, and a row can contain a very large or sparse set of columns. Some systems use column families, while others present a partitioned-table abstraction.

These databases are designed for enormous write volumes, predictable queries, and geographically distributed operation. They are often used for telemetry, event histories, messaging metadata, large-scale user activity, and workloads in which data is naturally grouped by a key such as customer, device, or account.

A wide-column schema is normally designed from queries backward. If an application must retrieve events for a device within a time interval, the partition key might identify the device and a clustering key might order events by timestamp. If the application also needs retrieval by region and date, a separate table or materialized view may be required. Unlike a relational database, the system may not support arbitrary joins or ad hoc queries efficiently.

Partition size and distribution require close attention. A partition that grows without bound may degrade performance, while a partition key with low cardinality may create hot spots. Bucketing by time, such as device-plus-day, can control partition growth. Denormalization is normal, but multiple copies of a logical fact must be updated through reliable application or event-driven processes.

Graph Databases: Relationships as First-Class Data

Graph databases represent information through nodes, edges, and properties. Nodes represent entities, edges represent relationships, and both may contain attributes. A social network, for example, can represent people as nodes and follows, memberships, purchases, or recommendations as edges.

The distinctive capability of graph databases is efficient traversal of connected data. Queries may ask which friends-of-friends have purchased a particular product, whether two accounts are connected through suspicious intermediaries, or which dependencies are affected by a software component. Such questions are often awkward in relational systems when they require repeated joins across variable-depth relationships.

Graph data models are particularly useful when relationships are numerous, meaningful, and frequently traversed. They are less advantageous when the dominant operation is simple key lookup or large-scale numerical aggregation. Graph queries can become expensive when traversals have high branching factors or lack selective constraints. Designers should therefore establish traversal boundaries, indexes, labels, and relationship directions carefully.

Graph databases support use cases such as recommendation engines, identity and access analysis, fraud detection, knowledge graphs, network management, and dependency analysis. A graph model does not automatically solve the problem of graph reasoning: domain semantics, identity resolution, data quality, and governance remain essential.

Time-Series Databases: Data with Temporal Semantics

Time-series databases are optimized for records associated with timestamps, such as sensor readings, application metrics, financial observations, vehicle locations, or industrial measurements. Their designs commonly exploit append-heavy writes, chronological ordering, retention policies, compression, downsampling, and time-window queries.

A time-series record generally contains a timestamp, a measurement, dimensions or tags, and one or more values. Tags such as device type or geographic region support filtering, while fields contain measurements. A good schema distinguishes stable, low-cardinality dimensions from rapidly changing values. Excessive tag cardinality can increase index size and operational cost.

Typical operations include retrieving measurements during an interval, calculating moving averages, identifying anomalies, comparing current performance with historical baselines, and aggregating data by minute, hour, or day. Retention policies may preserve detailed data for a short period and summarized data for longer-term analysis. This approach reduces storage requirements while retaining useful history.

Time-series systems are not necessarily general-purpose transactional databases. They may provide limited support for complex relationships or frequent arbitrary updates to old records. If an application requires strong multi-entity transactions and rich business queries, a relational or document system may remain necessary alongside the time-series store.

Search Databases: Retrieval by Meaning and Relevance

Search databases, often built on inverted indexes, are designed to locate documents according to words, phrases, fields, filters, and relevance. An inverted index maps terms to documents in which they occur. This structure supports full-text search far more efficiently than scanning every document.

Search systems commonly provide tokenization, stemming, synonyms, language-specific analysis, fuzzy matching, faceting, highlighting, ranking, and geospatial filtering. They are appropriate for product search, document discovery, log exploration, site search, and operational observability. A search index may be populated from a primary database through change data capture, event streams, scheduled jobs, or application writes.

A search database should usually not be treated as the authoritative source for transactional business data. Indexes may be eventually consistent with the source, and updates can fail or arrive out of order. Applications should define reindexing procedures, mappings, analyzers, and strategies for handling deleted or changed records. Search relevance is also a product concern: ranking quality must be evaluated using representative queries and user behavior rather than assumed from technical configuration.

Vector Databases: Similarity in High-Dimensional Space

Vector databases store numerical vectors representing text, images, audio, products, users, or other objects. These vectors are often produced by machine-learning models called embedding models. Objects that are semantically or visually similar may be located near one another in vector space.

Vector search retrieves approximate or exact nearest neighbors according to a distance measure such as cosine similarity, Euclidean distance, or inner product. Approximate nearest-neighbor indexes improve speed by avoiding exhaustive comparison with every vector. They are used in semantic search, recommendation, image retrieval, duplicate detection, question answering, and retrieval-augmented generation.

A vector system does not understand meaning independently of the embedding model. If the model fails to represent an important distinction, similarity results may be poor. Metadata filters are therefore important. A search for similar documents may also need constraints such as language, authorization status, date, or tenant. Hybrid search combines lexical matching with vector similarity and can improve retrieval when exact terms and semantic concepts are both important.

Operational issues include embedding version management, index rebuilding, dimensionality, update frequency, access control, and evaluation of retrieval quality. Sensitive information encoded in vectors also requires privacy and governance controls; embeddings should not be assumed to be harmless simply because they are numerical.

Multimodel Databases: Several Models in One Platform

A multimodel database supports two or more data models—such as documents, key-value pairs, graphs, or search—within one platform. The attraction is architectural consolidation. A development team may store user profiles as documents, relationships as graphs, and temporary values as key-value records while using shared security, backup, deployment, and monitoring mechanisms.

Multimodel systems can reduce data movement and simplify some applications, but they do not necessarily provide identical capabilities across all models. A platform may offer a strong document engine and a less mature graph interface, or it may use separate internal indexes with different consistency and scaling characteristics. “One database” does not mean that every workload has the same performance profile.

The decision to adopt a multimodel system should consider whether the related models genuinely benefit from shared governance and transactions. If one workload is exceptionally demanding—for example, massive time-series ingestion or sophisticated search ranking—a specialized database may still be preferable. Multimodel design is therefore a trade-off between integration and specialization.

Comparative Decision Framework

The following conceptual comparison helps align database families with workloads:

| Family | Natural structure | Strongest query pattern | Typical scaling strength | Common workloads |

|---|---|---|---|---|

| Key-value | Key and opaque value | Lookup by exact key | Very high low-latency throughput | Sessions, carts, caching |

| Document | Nested JSON-like document | Field, nested-field, and aggregate queries | Horizontal document distribution | Profiles, catalogs, content |

| Wide-column | Partitioned rows and columns | Queries designed around partition and clustering keys | Massive distributed writes | Events, telemetry, activity histories |

| Graph | Nodes, edges, properties | Relationship traversal | Connected-data workloads | Recommendations, fraud, knowledge graphs |

| Time-series | Timestamped measurements | Time-window and aggregation queries | High ingestion and compression | Metrics, sensors, monitoring |

| Search | Indexed searchable documents | Full-text, filter, and relevance queries | Distributed indexing and retrieval | Site search, logs, discovery |

| Vector | Embeddings and metadata | Nearest-neighbor similarity | Large-scale similarity retrieval | Semantic search, recommendations, RAG |

| Multimodel | More than one model | Model-specific and combined access | Depends on implementation | Integrated application platforms |

This table is a starting point rather than a substitute for benchmarking. Two systems in the same family can differ considerably in consistency, indexing, transaction support, query expressiveness, and operational maturity.

Polyglot Persistence and Architecture

Many substantial applications use polyglot persistence: different database technologies are selected for different workloads. An online marketplace might use a relational database for payments, a document database for product content, a key-value store for sessions, a search engine for product discovery, and a vector database for semantic recommendations.

Polyglot persistence can produce excellent workload fit but increases system complexity. Teams must manage data ownership, synchronization, schema evolution, observability, backup, access control, and failure recovery across systems. A search index or recommendation store may be rebuilt from an authoritative source, whereas a payment ledger cannot be treated as disposable. Architects must explicitly classify each store as authoritative, derived, cached, or temporary.

Event-driven integration is common. A transaction in the source system emits an event; consumers update search indexes, analytics stores, or recommendation indexes. This creates eventual consistency and requires idempotent consumers, retry policies, dead-letter handling, replay capability, and monitoring of replication lag.

Applied Case: A Multi-Channel Retail Platform

Background

Consider an illustrative retailer operating a web application, mobile application, and physical stores. It sells millions of products, records customer activity, receives inventory updates from warehouses, and wants to provide personalized search and recommendations.

Situation and Analysis

The retailer initially stores all information in one document database. Product pages work well, but several problems appear. Search becomes slow when users enter misspelled or partial terms. Inventory events create high write volumes and require historical analysis. Recommendations based on customer-product relationships are difficult to compute. Customer sessions also create large numbers of short-lived updates.

The architecture team analyzes access patterns rather than forcing every requirement into the existing model. Product descriptions, category information, and editorial content are retained in a document store because they form flexible product aggregates. A search engine receives derived product documents and supports text analysis, faceting, spelling tolerance, and relevance ranking. Warehouse and sales measurements are written to a time-series or wide-column system, depending on the required analytical and distribution characteristics. Sessions and temporary carts are stored in a key-value system with expiration. Customer, product, and interaction relationships are represented in a graph or recommendation-oriented data service. If semantic product discovery is required, product and query embeddings are stored in a vector index.

Strategy and Solution

The document database remains the authoritative source for product content. Change events are emitted whenever a product is created or modified. Consumers update the search and vector indexes asynchronously. Inventory data is partitioned by warehouse and time period, allowing high-volume ingestion and time-window analysis. Session keys are designed around customer or device identifiers, with safeguards against hot keys. Graph relationships are updated through idempotent event handlers.

The team defines service-level objectives for each store. Product updates may tolerate a short delay before appearing in search, but payment and inventory reservation operations require stronger transactional controls. Rebuild procedures are tested for derived indexes, and access policies ensure that recommendation and search systems do not expose restricted customer information.

Outcome

The platform achieves better search relevance, scalable event ingestion, and faster session access. However, the architecture becomes more complex. The team therefore introduces centralized observability, data lineage documentation, replayable events, contract testing, and automated consistency checks between authoritative and derived stores.

Learning Points

The case demonstrates that database selection should follow workload boundaries rather than organizational fashion. It also shows that polyglot persistence is valuable only when the benefits of specialization exceed the costs of synchronization and operations. Most importantly, every data store requires an explicit role, ownership model, recovery strategy, and consistency expectation.

Challenges, Risks, and Common Design Errors

A frequent mistake is choosing a database because it is popular rather than because its data model matches the workload. Another is assuming that flexible schema means no schema. Without validation, versioning, and ownership, flexible documents can become inconsistent and difficult to evolve.

Partition-key errors are especially serious in distributed systems. Low-cardinality keys can concentrate traffic, while rapidly increasing partitions can create unbounded storage units. Designers should estimate record size, growth rate, request distribution, and retention before deployment. Cross-partition queries should be measured rather than assumed to be inexpensive.

Eventual consistency can produce confusing user experiences, such as a newly created item not immediately appearing in search. Applications should communicate or tolerate these delays and provide reconciliation mechanisms. Denormalization can also create stale copies, while excessive indexing can increase write cost and storage consumption.

Other risks include vendor lock-in, inadequate backup testing, incomplete disaster recovery, weak authorization on secondary indexes, uncontrolled data retention, and observability gaps. Performance tests must use realistic data distributions; uniform synthetic data often hides hot partitions and skew.

Governance, Security, and Professional Responsibility

NoSQL technologies do not remove obligations relating to privacy, security, or regulation. Developers must classify personal, financial, health, and confidential data before deciding where it will be stored or replicated. Access should follow least privilege, and sensitive fields may require encryption, tokenization, masking, or exclusion from search and vector indexes.

Data lineage is particularly important in polyglot systems. Teams should know which store is authoritative, which stores contain derived copies, how long each copy is retained, and how deletion requests propagate. Backups, replicas, caches, search indexes, and embeddings may all contain personal information.

Professional governance also includes schema contracts, migration plans, audit logging, incident procedures, cost monitoring, and documented service-level objectives. AI-enabled vector retrieval introduces additional concerns, including biased or unsafe retrieval, prompt-injection content in indexed documents, unauthorized semantic search, and inadequate evaluation of generated answers.

Current Developments and Emerging Directions

Several developments are shaping NoSQL practice. Vector search is increasingly integrated with document and search systems, enabling hybrid lexical-semantic retrieval. Distributed SQL systems combine relational querying with horizontal scalability, narrowing the conceptual boundary between SQL and NoSQL. Streaming architectures are making databases more event-aware, while serverless platforms abstract infrastructure management but make usage patterns and cost controls more important.

Database systems are also adding automated indexing, workload recommendations, adaptive partitioning, and machine-learning-assisted operations. These features can reduce administrative effort, but they do not replace architectural judgment. Automated recommendations are only as reliable as the workload data and constraints supplied to them.

Best Practices for Database-Family Selection

A disciplined selection process should:

1. Document business capabilities and concrete access patterns.

2. Estimate read, write, storage, growth, and latency requirements.

3. Identify consistency, transaction, availability, and recovery needs.

4. Select a natural data model before choosing a vendor product.

5. Design partition keys and indexes using realistic distributions.

6. Decide which data is authoritative and which is derived.

7. Benchmark representative workloads, including failure conditions.

8. Plan schema evolution, retention, backup, and disaster recovery.

9. Protect replicated, indexed, cached, and embedded personal data.

10. Review operational complexity and total cost, not only query speed.

Chapter Summary

NoSQL is a family of data models designed for diverse structures, access patterns, and distributed workloads. Key-value databases excel at exact-key, low-latency access; document databases represent flexible aggregates; wide-column systems support highly distributed, predictable queries; graph databases specialize in connected data; time-series databases optimize temporal measurements; search databases provide full-text and relevance retrieval; vector databases support similarity search over embeddings; and multimodel systems combine several representations in one platform.

Effective NoSQL design begins with access patterns, partitioning, consistency requirements, and operational constraints. Denormalization, replication, and asynchronous derived stores can improve scalability, but they introduce synchronization and governance responsibilities. Polyglot persistence may provide strong workload alignment, yet it increases architectural complexity. Professional database selection therefore requires technical comparison, realistic benchmarking, security and governance analysis, and a clear understanding of which system is authoritative for each kind of data.

Key Terms

NoSQL: A broad family of non-relational or distributed database technologies designed for varied data models and workloads.

Data model: A formal way of representing data, relationships, and permitted operations.

Access pattern: A recurring way an application reads, writes, filters, or traverses data.

Key-value database: A database that retrieves values primarily through unique keys.

Document database: A database that stores flexible, nested records such as JSON documents.

Wide-column database: A distributed database organized around partitioned rows and flexible columns.

Graph database: A database representing entities as nodes and relationships as edges.

Time-series database: A database optimized for timestamped measurements and temporal queries.

Search database: A system using indexes and analysis techniques for text retrieval and relevance ranking.

Vector database: A database that stores embeddings and performs similarity search.

Multimodel database: A database supporting more than one data model in one platform.

Partition key: An attribute used to determine where distributed data is stored.

Denormalization: Deliberate duplication or embedding of data to improve access efficiency.

Eventual consistency: A model in which replicas may temporarily differ but converge over time.

Embedding: A numerical representation of an object produced by a machine-learning model.

Inverted index: An index mapping terms to the documents containing them.

Polyglot persistence: Use of multiple database technologies within one application architecture.

Hot spot: A partition, key, or node receiving disproportionately high traffic.

Change data capture: A mechanism for recording source-data changes for downstream consumers.

Review Questions

Short Answer Questions

1. What distinguishes a key-value database from a document database?

2. Why are access patterns important in wide-column data modeling?

3. What types of queries are graph databases designed to support?

4. What is the purpose of an inverted index in a search database?

5. Define eventual consistency and identify one situation in which it may be acceptable.

Long Answer Questions

1. Compare document and wide-column databases in terms of structure, querying, partitioning, and suitable workloads.

2. Explain how time-series and search databases solve different retrieval problems.

3. Discuss the benefits and risks of polyglot persistence in a full-stack application.

4. Explain the role of embeddings, similarity measures, and metadata filters in vector databases.

5. Develop a framework for selecting a NoSQL database family for a new application.

Analytical / Application Questions

1. A logistics company receives millions of vehicle-location updates each day and must display recent routes, calculate hourly summaries, and retain historical data economically. Which database family or combination would you recommend, and why?

2. An online marketplace needs exact cart retrieval, product text search, semantic recommendations, and payment integrity. Design a persistence architecture and identify the authoritative store for each major data type.

3. A social platform experiences slow queries when finding second- and third-degree connections using a document database. Analyze the cause and recommend a more suitable model, including possible operational limitations.

22. Multiple Choice Questions with Answers

Question 1

A shopping-cart service requires very fast retrieval using a known customer or session identifier, with automatic expiration of inactive carts. Which database family is the most natural choice?

A. Key-value

B. Graph

C. Search

D. Time-series

Correct Answer: A. Key-value

Question 2

Which modeling decision is most appropriate for a document database?

A. Embed bounded data that is usually read with its parent aggregate

B. Store every relationship only as a graph edge

C. Partition all records by a low-cardinality status field

D. Use full-text analysis for every field

Correct Answer: A. Embed bounded data that is usually read with its parent aggregate

Question 3

What is a major reason wide-column schemas are designed from access patterns backward?

A. They are optimized for predictable partition and clustering-key queries

B. They require every query to use natural-language ranking

C. They cannot store more than one column per row

D. They represent relationships only through variable-depth traversal

Correct Answer: A. They are optimized for predictable partition and clustering-key queries

Question 4

Which workload most strongly favors a graph database?

A. Retrieving a user session by its identifier

B. Finding connected accounts involved in a multi-step relationship pattern

C. Calculating hourly averages of sensor readings

D. Searching product descriptions for misspelled terms

Correct Answer: B. Finding connected accounts involved in a multi-step relationship pattern

Question 5

Why can excessive tag cardinality be problematic in a time-series database?

A. It can increase index size and operational cost

B. It prevents timestamps from being stored

C. It converts all measurements into graph edges

D. It guarantees strong consistency across unrelated records

Correct Answer: A. It can increase index size and operational cost

Question 6

What is the principal purpose of an inverted index?

A. To map searchable terms to documents containing them

B. To distribute database partitions evenly by timestamp

C. To encode images as numerical embeddings

D. To maintain transactional locks between graph nodes

Correct Answer: A. To map searchable terms to documents containing them

Question 7

A semantic retrieval system returns similar documents but ignores tenant authorization. Which design improvement is most important?

A. Add metadata filtering and enforce authorization during retrieval

B. Remove all embeddings and use random identifiers

C. Store every document in one unpartitioned key

D. Disable indexing so every query scans all records

Correct Answer: A. Add metadata filtering and enforce authorization during retrieval

Question 8

In the retail case, why should the search index generally not be treated as the authoritative source?

A. It is a derived structure that may be temporarily inconsistent with transactional data

B. Search databases cannot store text

C. Search indexes cannot be rebuilt from source data

D. Search systems always require graph traversal

Correct Answer: A. It is a derived structure that may be temporarily inconsistent with transactional data

Question 9

Which situation is a likely consequence of a poor partition key in a distributed NoSQL database?

A. A hot spot receiving disproportionate traffic

B. Automatic elimination of all duplicate data

C. Improved performance for every cross-partition query

D. Guaranteed prevention of eventual consistency

Correct Answer: A. A hot spot receiving disproportionate traffic

Question 10

What is a central trade-off of multimodel databases?

A. They may simplify integration while offering less specialized capability for a particular workload

B. They can store only one kind of record at a time

C. They eliminate the need for backup and governance

D. They always outperform specialized databases

Correct Answer: A. They may simplify integration while offering less specialized capability for a particular workload