4. Big Data Storage and Data Management

Introduction and Context

Data-intensive organisations do not merely need more storage; they need storage that matches the way data is produced, accessed, protected, governed, and analysed. A transaction-processing system, an Internet-of-Things platform, a recommendation engine, and a regulatory archive may all store “data,” but their requirements differ substantially. One may require millisecond updates and strict consistency, another economical retention of billions of files, and a third rapid analysis across historical records.

Big data storage and data management therefore concern architectural choice rather than the selection of a single database product. The central question is how data should be represented and distributed so that the system achieves an acceptable balance among scalability, availability, consistency, performance, cost, governance, and operational complexity. This chapter examines distributed file systems, cloud object storage, relational databases, and major NoSQL models: key-value, document, column-family, graph, and time-series databases. It also develops a decision framework for selecting among them.

Storage decisions are closely connected with data engineering and analytics. Storage influences ingestion design, data quality, query performance, machine-learning pipelines, backup procedures, security controls, and the reliability of business reporting. A technically impressive analytics model may still produce poor outcomes if the underlying data is duplicated, stale, inaccessible, or incorrectly governed.

Learning Objectives

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

1. Explain the role of distributed storage in big data architectures.

2. Distinguish distributed file systems from cloud object storage.

3. Compare relational and NoSQL data models.

4. Explain scalability, consistency, availability, partition tolerance, and workload patterns in storage selection.

5. Evaluate key-value, document, column-family, graph, and time-series databases.

6. Design a storage strategy for mixed analytical and operational workloads.

7. Identify risks involving security, governance, data quality, cost, and vendor dependence.

8. Apply a structured framework to a realistic data-management case.

The Storage Problem in Big Data

Traditional storage assumptions are challenged by the volume, velocity, variety, and distribution of modern data. Data may arrive from applications, sensors, clickstreams, enterprise systems, mobile devices, and external partners. It may be structured, semi-structured, or unstructured. It may need to be retained for years but queried only occasionally, or it may support continuous decisions within milliseconds.

Three properties are particularly important. Scalability is the ability to accommodate increasing data or workload by adding resources. Vertical scaling increases the capacity of one machine, while horizontal scaling distributes data and processing across multiple machines. Horizontal scaling is central to big data because it can support very large datasets and reduce dependence on a single server.

Availability refers to the probability that a service is accessible when requested. Consistency describes the conditions under which users observe the same or correct data. Strong consistency makes a completed update visible immediately or according to a specified guarantee. Eventual consistency permits temporary differences between replicas, provided that replicas converge if updates cease. Strong consistency is useful for financial balances, whereas eventual consistency may be acceptable for social-media counters or product recommendations.

A distributed system must also address failures. Machines, networks, disks, and software components can fail independently. Replication, partitioning, checksums, retry mechanisms, failover, and recovery procedures are therefore fundamental storage capabilities rather than optional enhancements.

Data Models and Workload Shapes

A data model is a way of representing entities, attributes, relationships, and operations. A workload describes how the system is used. Important workload dimensions include:

• read-to-write ratio;
• point lookups versus range scans;
• transaction size and frequency;
• latency requirements;
• analytical aggregation requirements;
• schema stability;
• relationship complexity;
• retention period and deletion obligations; and
• concurrency and geographic distribution.

The same dataset can require different storage models for different workloads. Customer profiles may be stored in a document database for application access, copied into a columnar analytical warehouse for reporting, and archived in object storage for long-term retention. This is not necessarily wasteful duplication; it is purposeful duplication governed through pipelines, lineage, and retention policies.

Distributed File Systems and Cloud Object Storage

Distributed File Systems

A distributed file system presents files and directories while storing their contents across multiple machines. Large files are divided into blocks, and blocks are commonly replicated to tolerate machine or disk failure. A metadata service records file names, permissions, block locations, and related information. Computation may be moved close to the data to reduce network transfer.

Distributed file systems are well suited to large sequential reads and writes, batch processing, and data-lake environments. They are less suitable for millions of tiny files, highly concurrent transactional updates, or applications requiring low-latency random access. File size, block size, replication factor, metadata load, and data locality influence performance.

A major operational concern is the metadata layer. If a single metadata service becomes a bottleneck or fails without a resilient design, the apparent distribution of file contents does not eliminate a critical point of failure. Modern implementations address this through high availability, federation, or managed services.

Cloud Object Storage

Object storage stores data as objects within containers commonly called buckets. Each object consists of content, a key or name, and metadata. Unlike a conventional file system, object storage normally does not provide a general-purpose hierarchical directory structure or in-place modification of arbitrary byte ranges. Applications usually write a new object or a new version.

Object storage is attractive because it offers elastic capacity, high durability, broad geographic availability, lifecycle management, and a pay-as-used model. It is commonly used for data lakes, backups, media, logs, software artifacts, and machine-learning datasets. Storage classes can place frequently accessed data in fast tiers and rarely accessed data in lower-cost archival tiers.

Object storage should not be confused with a database. It does not ordinarily provide joins, multi-row transactions, or flexible query processing by itself. These functions are supplied by query engines, metadata catalogs, table formats, or external databases. Performance may also depend on object size, request rate, partitioning of object names, network distance, and the format in which data is stored.

Columnar formats such as Parquet and ORC are frequently used in analytical object-storage environments. They store values by column rather than by row, enabling query engines to read only relevant columns and compress similar values efficiently. Partitioning by date, region, or another selective attribute can reduce scanning, but excessive partitioning creates many small files and increases metadata overhead.

Data Lakes and Lakehouse Patterns

A data lake stores large quantities of raw or lightly processed data, often in object storage. Its flexibility supports exploratory analysis and future use cases, but uncontrolled data lakes can become “data swamps” containing duplicated, undocumented, stale, or insecure content. A lakehouse pattern adds transaction management, schema enforcement or evolution, cataloguing, and analytical table abstractions to lake storage. It aims to combine low-cost object storage with stronger management features traditionally associated with warehouses.

These patterns do not remove the need for modelling and governance. A catalogue should record ownership, business meaning, sensitivity, lineage, quality indicators, and retention requirements. Open table formats and transaction logs can improve reliability, but their effectiveness depends on disciplined operational practices.

Relational Databases: Structure and Guarantees

Relational databases represent information in tables consisting of rows and columns. Relationships are expressed through keys, and SQL provides a declarative language for filtering, joining, grouping, and updating data. A schema defines data types and structural rules. Normalisation reduces unnecessary duplication and update anomalies, although analytical systems may deliberately denormalise data to improve read performance.

The relational model remains valuable because it supports expressive queries, mature integrity constraints, and transactions. The ACID properties are commonly described as follows:

• Atomicity: a transaction is treated as an indivisible unit.
• Consistency: a transaction preserves defined integrity rules.
• Isolation: concurrent transactions do not interfere in unacceptable ways.
• Durability: committed changes survive appropriate failures.

Relational systems are particularly appropriate for financial transactions, inventory, orders, billing, master data, and workloads involving complex joins and strict integrity. They can scale vertically and, through partitioning, replication, sharding, distributed SQL, or specialised analytical systems, can also scale horizontally. However, distributed relational architectures introduce coordination, latency, operational complexity, and sometimes restrictions on transactions or joins.

The choice is not simply “SQL versus NoSQL.” Many contemporary systems combine relational databases with caches, search engines, object storage, and specialised databases. The correct question is which guarantees and access patterns are required for each workload.

NoSQL Models and Their Appropriate Workloads

NoSQL systems are not one uniform category. They generally relax or redesign some relational assumptions to achieve particular scalability, flexibility, or performance goals. Schema flexibility does not mean the absence of structure; it means that structure may be enforced by applications, validation services, or conventions rather than by a single central schema.

Key-Value Stores

A key-value database stores a value associated with a unique key. The value may be opaque to the database or may have limited internal structure. Operations are usually simple: get, put, update, and delete.

This model is effective for session data, shopping carts, caching, user preferences, feature flags, and high-volume point lookups. It can provide very low latency and straightforward horizontal partitioning. Its weakness is limited querying across values. If an application needs filtering, joins, or ad hoc analysis, those capabilities must be added elsewhere or supported by a different model.

A key-value design requires careful key selection. Poorly distributed keys can create hot partitions, while keys that lack meaningful access structure may force expensive scans. Expiration policies are useful for temporary data but must be designed so that automatic deletion does not remove information required for audit or recovery.

Document Databases

Document databases store records as documents, often represented using JSON-like structures. A document can contain nested objects and arrays, allowing an aggregate such as an order and its line items to be retrieved together. Documents are useful when application objects are naturally self-contained and when attributes evolve over time.

Document systems support indexes and queries over selected fields, but joins may be limited or more expensive than in relational systems. Duplication is often intentional: customer details may be embedded in an order snapshot, for example. This improves read performance and preserves historical context, but it creates update and consistency issues if the duplicated information is expected to remain current.

Document modelling should begin with access patterns. Frequently retrieved together data may be embedded; data with independent lifecycles or many-to-many relationships may be referenced separately. Schema validation, versioning, and migration are important because flexibility can otherwise produce incompatible document variants.

Column-Family Databases

Column-family databases organise data into rows and families of related columns, often distributing rows across a cluster. They are designed for large-scale writes and predictable query patterns. Unlike a relational table, a column-family design is commonly created around known queries rather than around a fully normalised universal schema.

These databases are effective for event histories, telemetry, message records, and workloads requiring high write throughput across many nodes. They typically favour denormalisation and may provide limited joins and transactions. A well-designed partition key distributes data evenly, while clustering columns arrange data within a partition for efficient range retrieval.

A common error is selecting a partition key that concentrates most records in one partition. Another is creating queries that require scanning many partitions. Modelling must therefore consider both data distribution and the exact query paths used by applications.

Graph Databases

Graph databases represent entities as nodes and relationships as edges, with properties attached to either. They are valuable when relationships are central to the problem rather than merely incidental. Typical applications include fraud detection, recommendation, identity resolution, network analysis, knowledge graphs, and dependency management.

Graph traversal can express questions such as “which accounts are connected through shared devices and suspicious transfers within three steps?” naturally. In a relational system, the same question may require multiple joins whose cost and complexity increase with traversal depth. Graph systems are not automatically superior for all relationship data; large scans, simple aggregations, and regular tabular reporting may be more efficient in relational or columnar systems.

Graph modelling requires attention to traversal direction, relationship types, cardinality, indexing, and path constraints. Unbounded traversals can create unpredictable workloads, so production queries should normally impose depth, time, or result limits.

Time-Series Databases

Time-series databases are optimised for measurements associated with time. Examples include temperature readings, application metrics, financial observations, equipment telemetry, and user activity rates. They commonly support time-window queries, downsampling, retention policies, compression, and aggregation functions.

A time-series schema may include a timestamp, measurement, tags identifying the source or dimensions, and one or more values. High-cardinality tags can create excessive series and metadata overhead. The design must balance granularity, retention, query frequency, and the need to correct late-arriving data. Raw data may be retained briefly while hourly or daily aggregates are retained longer.

Time-series databases are particularly useful for operational monitoring, but they should not automatically replace a durable event store or analytical warehouse. The appropriate architecture depends on whether the measurements must support replay, audit, complex joins, or machine-learning feature construction.

A Framework for Storage Selection

Storage selection should be treated as a requirements-analysis exercise. A practical evaluation can proceed through six questions.

First, what are the access patterns? Identify point lookups, range queries, joins, traversals, aggregations, and full scans. A database optimised for one pattern may perform poorly for another.

Second, what guarantees are required? Determine whether operations need ACID transactions, read-after-write consistency, monotonic reads, eventual convergence, or merely durable append. Avoid purchasing strong guarantees that the business process does not require, but do not weaken guarantees that protect customers or regulatory obligations.

Third, how will the system scale? Estimate data volume, growth rate, peak requests, concurrent users, object counts, and geographic distribution. Evaluate whether scaling is vertical, horizontal, automatic, or operationally intensive.

Fourth, what failure behaviour is acceptable? Examine replication, recovery-point objectives, recovery-time objectives, regional failure handling, backup restoration, and data-loss scenarios.

Fifth, what is the total cost? Include storage, requests, data transfer, compute attached to queries, licensing, support, operations, migration, and staff expertise. Low storage price can be outweighed by high retrieval or egress charges.

Sixth, how will data be governed? Consider classification, encryption, access control, lineage, retention, deletion, residency, auditability, and quality monitoring.

A simplified decision matrix is useful:

| Requirement | Likely fit | Reason |

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

| Strict multi-record transactions | Relational database | Mature integrity and ACID support |

| Durable, low-cost large-scale retention | Object storage | Elastic capacity and lifecycle tiers |

| Very fast key-based access | Key-value store | Simple operations and low latency |

| Flexible aggregate-oriented records | Document database | Nested structures and evolving attributes |

| High-volume predictable writes | Column-family database | Distributed write scaling |

| Deep relationship traversal | Graph database | Native path-oriented operations |

| Timestamp-window analytics | Time-series database | Temporal indexing and retention features |

| Large batch analytics | Distributed file or object storage with query engine | Parallel scans and columnar formats |

The matrix is a starting point, not a substitute for benchmarking. Representative data, realistic concurrency, failure tests, and production-like queries are necessary before committing to an architecture.

Data Management Across the Lifecycle

Storage technology is only one part of data management. Data should be governed from creation to disposal. Ingestion processes should validate formats, timestamps, identifiers, and required fields. Metadata should identify the source, owner, sensitivity, transformation history, and quality status. Data-quality controls should monitor completeness, accuracy, consistency, timeliness, and uniqueness.

Partitioning and indexing improve retrieval but create maintenance costs. Indexes consume storage and slow writes; partitions can improve pruning but may produce skew. Compaction, vacuuming, clustering, and archival policies should be managed according to workload rather than applied indiscriminately.

Security must operate at several layers: identity and authentication, authorisation, network control, encryption in transit and at rest, secret management, key rotation, monitoring, and incident response. Fine-grained controls may be required for sensitive columns or document fields. Backups must be tested through restoration exercises; a backup that has never been restored is an assumption rather than demonstrated resilience.

Data governance also includes lawful collection, purpose limitation, retention, access rights, correction, and deletion. Replication and immutable logs can complicate deletion obligations. Organisations must understand where copies, caches, derived datasets, and backups exist, and must define how legal or policy-based deletion is propagated.

Applied Case: A Regional Logistics Platform

Background

This illustrative case concerns RouteFlow, a fictional logistics company operating a delivery platform. Its systems receive vehicle-location events, manage customer orders, assign drivers, process payments, and provide operational dashboards. Management initially proposed storing all information in one distributed NoSQL database to simplify architecture.

Situation and Problem

The platform generates frequent location measurements, while order and payment records require reliable transactional updates. Customer-service staff need flexible access to order details. Analysts require historical data for route optimisation and demand forecasting. The proposed single database produced several risks: financial updates were difficult to reconcile, location queries generated uneven load, and historical analytics competed with operational traffic.

Analysis

The workloads are materially different. Payment and order state require strong consistency and atomic changes. Location events are append-oriented, time-based, and high volume. Customer-service access is aggregate-oriented, with occasional schema evolution. Analytical workloads involve large scans and joins across months of history. Retention also differs: recent telemetry is operationally valuable, whereas older raw events can be archived after aggregates are created.

Approach and Solution

RouteFlow adopts a polyglot storage architecture. A relational database stores orders, invoices, payment status, and driver assignments. A time-series store handles recent location and vehicle-health measurements, with retention and downsampling policies. A document database maintains customer-facing order views, built from authoritative events and transactional records. Object storage receives immutable raw events in partitioned columnar files for historical analysis and model training. A distributed query engine reads curated analytical tables without placing reporting load on the transactional database.

The architecture includes an event pipeline, schema validation, a metadata catalogue, encryption, role-based access, quality checks, and reconciliation jobs. Each dataset has an owner and a stated source of truth. The customer-facing document view is explicitly treated as derived data; if it becomes inconsistent, it can be rebuilt from authoritative records.

Outcome

The design separates operational and analytical workloads, allows each storage model to be tuned for its principal access pattern, and provides a lower-cost archive for historical data. It also introduces additional pipeline and governance complexity. The organisation therefore documents lineage, monitors replication delay, tests recovery, and reviews storage costs periodically.

Learning Points

The central lesson is not that multiple databases are always preferable. Rather, storage should follow business guarantees and workload characteristics. A single technology may simplify procurement but create hidden compromises. Conversely, a polyglot design is justified only when the benefits of specialised models exceed the cost of operating and governing them.

Challenges, Risks, and Common Mistakes

A frequent mistake is choosing a database because it is fashionable or familiar rather than because its access patterns fit the workload. Another is treating schema flexibility as permission to ignore data modelling. Poorly documented structures eventually create data-quality and integration problems.

Premature denormalisation can create conflicting copies, while excessive normalisation can produce expensive runtime joins. Hot partitions, unbounded queries, oversized documents, uncontrolled indexes, and small-file proliferation are common performance problems. Eventual consistency can also produce confusing user experiences if interfaces do not communicate processing delays or if business processes require immediate visibility.

Distributed systems introduce operational complexity: monitoring, capacity planning, version upgrades, cross-region replication, incident response, and cost control. Cloud services reduce infrastructure administration but do not eliminate architecture responsibility. Vendor-specific APIs may accelerate delivery while increasing switching costs and migration difficulty.

Analytical data may contain personal, confidential, or commercially sensitive information. Copying data into lakes, caches, warehouses, and development environments expands the attack surface. De-identification, tokenisation, least-privilege access, environment separation, and retention controls should be planned before replication becomes widespread.

Contemporary Developments

Modern data architectures increasingly separate storage and compute, allowing the same durable data to serve different analytical engines. Open table formats, metadata catalogues, and interoperable columnar files aim to reduce dependence on a single processing engine. Streaming architectures support continuous ingestion and near-real-time decisions, while change-data-capture techniques propagate updates from operational systems to analytical stores.

Managed databases increasingly provide automated scaling, tiering, replication, backups, and serverless execution. These features improve agility but can conceal cost behaviour and configuration limits. AI applications are also influencing storage design: vector indexes support similarity search, feature stores provide reusable machine-learning inputs, and retrieval systems combine document storage with embeddings and access controls. Such additions do not replace established governance; vector representations may still reveal sensitive information and require provenance and deletion processes.

Best Practices for Professional Practice

1. Begin with business operations and access patterns, not product names.

2. Define the source of truth for every important data element.

3. Separate operational, analytical, archival, and caching responsibilities where appropriate.

4. Model partition keys, indexes, and retention policies using realistic volumes.

5. Make consistency requirements explicit for each operation.

6. Use columnar, compressed, and appropriately partitioned formats for large analytical data.

7. Catalogue data ownership, lineage, sensitivity, quality, and retention.

8. Test failure recovery, restoration, scaling, and cost under realistic conditions.

9. Monitor data freshness, replication lag, skew, query performance, and spending.

10. Treat derived copies as rebuildable products with documented dependencies.

11. Apply least privilege, encryption, auditing, and secure deletion.

12. Reassess the architecture as workload, regulation, and organisational capability change.

Chapter Summary

Big data storage is an architectural discipline concerned with matching data models and platforms to workload, scalability, consistency, availability, cost, and governance requirements. Distributed file systems support large file-oriented processing, while object storage provides elastic and economical persistence for data lakes, archives, and analytical datasets. Relational databases remain essential where transactions, integrity, and expressive joins are central.

NoSQL models address specialised needs: key-value stores support fast point access, document databases support aggregate-oriented and evolving records, column-family databases support predictable large-scale writes, graph databases support relationship traversal, and time-series databases support temporal measurements and retention-aware analysis. No model is universally superior. Sound selection begins with access patterns and business guarantees, followed by capacity, resilience, governance, security, and total-cost analysis.

The RouteFlow case demonstrates why organisations often combine several storage technologies. Such polyglot architectures can improve fit and performance but require strong lineage, ownership, monitoring, and operational discipline. Contemporary developments such as object-based lakehouses, streaming, managed services, and vector search expand possibilities while making governance even more important.

Key Terms

Distributed file system: A storage system that distributes file contents across multiple machines while presenting a file-oriented interface.

Object storage: A system that stores data as objects identified by keys within containers and accompanied by metadata.

Data lake: A repository for storing large quantities of raw or lightly processed data for varied future use.

Lakehouse: An architecture combining object-storage economics with table management, cataloguing, and analytical controls.

Scalability: The ability of a system to accommodate increasing data or workload by adding resources.

Horizontal scaling: Increasing capacity by adding machines or nodes to a distributed system.

Consistency: The guarantees governing what values and versions users observe after updates.

Eventual consistency: A model in which replicas may temporarily differ but converge when updates stop.

Availability: The degree to which a service remains accessible when requested.

Partitioning: Dividing data across storage or processing units according to a chosen key or rule.

Replication: Maintaining multiple copies of data to improve resilience or availability.

ACID: Transaction properties of atomicity, consistency, isolation, and durability.

Key-value database: A database that associates values with unique keys for simple, rapid access.

Document database: A database that stores semi-structured records as documents, often with nested fields.

Column-family database: A distributed database organised around rows and column families for predictable high-scale access.

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

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

Data lineage: A record of data origins, transformations, movements, and downstream uses.

Hot partition: A partition receiving disproportionate traffic or data, causing a performance bottleneck.

Polyglot persistence: The deliberate use of multiple storage technologies within one architecture.

Review Questions

Short Answer Questions

1. Distinguish vertical scaling from horizontal scaling.

2. Why is object storage not, by itself, a complete analytical database?

3. State the four ACID properties.

4. What is a hot partition, and why is it harmful?

5. Identify one suitable application for a graph database and explain why relationships matter in that application.

Long Answer Questions

1. Compare distributed file systems and cloud object storage in terms of structure, scalability, access patterns, and operational use.

2. Explain how relational and NoSQL databases differ, and discuss why the choice should be based on workload rather than ideology.

3. Describe key-value, document, column-family, graph, and time-series models, including an appropriate use case and a limitation for each.

4. Develop a storage-selection framework incorporating consistency, availability, scalability, cost, security, and governance.

5. Explain how a data-lake or lakehouse architecture can support analytics while avoiding data-quality and governance problems.

Analytical / Application Questions

1. A banking application must update an account balance, record a transfer, and prevent contradictory concurrent updates. Which storage model would you select, and what guarantees must it provide? Justify your answer.

2. An industrial firm collects billions of sensor readings, needs immediate alerts, retains hourly summaries for five years, and occasionally trains models on raw history. Design a multi-store architecture and explain the role of each store.

3. An organisation proposes putting customer profiles, payments, event logs, dashboards, and archival data into one document database. Critically evaluate the proposal and recommend a more appropriate strategy.

22. Multiple Choice Questions with Answers

Question 1

A company must store large historical datasets cheaply, apply lifecycle policies, and allow different analytical engines to read the data. Which storage option is the most appropriate foundation?

A. Cloud object storage

B. A key-value cache

C. A graph database

D. A relational transaction database

Correct Answer: A. Cloud object storage

Question 2

Which workload is most naturally suited to a key-value database?

A. Finding all paths among thousands of connected entities

B. Retrieving a shopping cart by its unique session key

C. Joining invoices with products across many years

D. Calculating moving averages over sensor readings

Correct Answer: B. Retrieving a shopping cart by its unique session key

Question 3

Why can a poorly selected partition key harm a distributed column-family database?

A. It prevents all data from being encrypted

B. It forces every query to use a graph traversal

C. It can concentrate traffic and data on one partition

D. It automatically converts rows into unstructured objects

Correct Answer: C. It can concentrate traffic and data on one partition

Question 4

Which requirement most strongly favours a relational database?

A. Flexible documents with frequently changing fields

B. Strict multi-record transactions and integrity constraints

C. Deep traversal of variable-length relationships

D. Automatic expiration of temporary session values

Correct Answer: B. Strict multi-record transactions and integrity constraints

Question 5

A social platform can tolerate a short delay before a follower count is identical on every replica. Which consistency approach may be appropriate?

A. Eventual consistency

B. Serializable consistency for every read

C. No replication under any circumstance

D. Manual file locking across all users

Correct Answer: A. Eventual consistency

Question 6

Which feature is especially characteristic of a time-series database?

A. Relationship traversal through edges

B. Time-window queries and retention policies

C. Foreign-key enforcement across many tables

D. Opaque values accessed only through session keys

Correct Answer: B. Time-window queries and retention policies

Question 7

In the RouteFlow case, why was object storage used for raw historical events?

A. It provided the strongest multi-row transaction guarantees

B. It was optimised for graph traversal

C. It offered durable, economical retention for analytical use

D. It replaced the need for metadata and governance

Correct Answer: C. It offered durable, economical retention for analytical use

Question 8

What is the principal risk of treating a derived customer document view as the authoritative source?

A. The view may be difficult or impossible to rebuild accurately

B. The system cannot store nested objects

C. The database will always become strongly consistent

D. Object-storage lifecycle policies will stop working

Correct Answer: A. The view may be difficult or impossible to rebuild accurately

Question 9

Which practice best addresses the risk of a data lake becoming a data swamp?

A. Allowing every team to create undocumented copies

B. Removing all schema and ownership requirements

C. Using cataloguing, lineage, quality monitoring, and retention controls

D. Storing all data in a single unpartitioned file

Correct Answer: C. Using cataloguing, lineage, quality monitoring, and retention controls

Question 10

Why might an organisation deliberately use several database technologies in one architecture?

A. Each workload may require a different access pattern and consistency model

B. Polyglot persistence eliminates operational complexity

C. NoSQL systems cannot store any structured information

D. Multiple systems guarantee that data duplication never occurs

Correct Answer: A. Each workload may require a different access pattern and consistency model