Databases for Big Data

A is correct — RDBMSs are built around strict schemas and ACID-compliant consistency, which is both a strength and a scalability limitation. B is correct — "NoSQL" is an umbrella term covering key-value, document, column-family, and graph stores — diverse systems united mainly by what they are not (SQL/relational). E is correct — horizontal scaling (adding more machines) is a core advantage of NoSQL over traditional RDBMSs. C is wrong — this is the opposite of reality; RDBMSs struggle at large scale, which is exactly why NoSQL was developed. D is wrong — horizontal scaling means adding more nodes; D describes vertical scaling (upgrading individual nodes).

A is correct — maintaining ACID consistency across distributed nodes requires expensive coordination (e.g., two-phase commit), which creates overhead that limits scalability. E is correct — distributing transactions across multiple nodes is fundamentally difficult for RDBMSs because their transaction model was designed for single-machine operation. B is wrong — vertical scaling means upgrading the same machine (more RAM, faster CPU), not adding new nodes; B has the definition backwards. C is wrong — this describes a strength of RDBMSs, not a challenge; optimisation for smaller datasets doesn't explain horizontal scaling difficulties. D is wrong — this describes NoSQL's advantage, not an RDBMS challenge.

A is correct — ACID (Atomicity, Consistency, Isolation, Durability) guarantees are expensive to maintain across distributed systems, limiting RDBMS scalability. B is correct — many NoSQL systems follow the BASE model (Basically Available, Soft state, Eventually consistent) as a trade-off that enables greater scale. C is wrong — this is the opposite; RDBMSs are weak at horizontal scaling for large datasets. D is wrong — this is exactly backwards; NoSQL was built for large-scale datasets. E is wrong — sharding is primarily a NoSQL/distributed DB technique; traditional RDBMSs are not designed around sharding and implementing it is complex and often problematic.

A is correct — RDBMSs require a predefined schema; adding or changing columns requires migrations, which is costly when requirements evolve rapidly. B is correct — document stores like MongoDB allow each record to have different fields; the schema emerges from the data rather than being enforced upfront. C is wrong — denormalization can be used in RDBMSs for performance, but it is not a typical/default approach; RDBMSs are built around normalization, not denormalization. D is wrong — NoSQL databases typically favour denormalization (embedding data) over normalization, which is the opposite of what D says. E is wrong — RDBMSs do not support flexible data modeling; their rigid schemas are the defining limitation being contrasted here.

A is correct — RDBMSs do use replication (primary-replica setups) and automated failover to maintain availability. B is correct — NoSQL systems like Cassandra and MongoDB are designed from the ground up with distributed, replicated architectures that tolerate node failure automatically. C is wrong — strong consistency does not directly reduce data loss risk; node failures can still result in data loss regardless of consistency model. D is wrong — this is backwards; NoSQL databases typically prioritise availability over consistency (per the CAP theorem), not the other way round. E is partially true in phrasing but is not one of the stated correct answers — the key distinction in the lecture context is that the strategies differ significantly, and the question focuses on what each system is specifically known for.

E is the complete and accurate description — key/value stores (like Redis, DynamoDB) are extremely fast (often in-memory), scale horizontally with ease by hashing keys to nodes, but their simplicity is also a limitation: complex data structures, relationships, and queries are awkward to model as flat key-value pairs. A is wrong — the model is deliberately simple, not complex. B is wrong — many key/value stores are in-memory, making them among the fastest databases available. C is wrong — horizontal scaling is actually a key strength, achieved through consistent hashing. D is wrong — key/value stores are schema-less and not designed for complex queries or indexing.

D is correct — tuple stores are schema-less; unlike relational tables, tuples can have varying numbers of elements and different semantic orderings, giving them significant flexibility over rigid tabular formats. A is wrong — rigid schema is the opposite of what tuple stores offer; the flexibility in length and ordering is the defining characteristic. B is wrong — tuples store ordered sequences of multiple elements, not just pairwise key-value combinations; that describes key-value stores. C is wrong — quick single-record retrieval by unique key is the hallmark of key-value stores, not tuple stores. E is wrong — tuple stores are not specifically optimised for frequent in-place updates to individual elements; immutability is more common in practice.

D is correct — document databases like MongoDB are specifically designed for efficient CRUD operations on self-contained documents, with rich querying and indexing support. E is correct — the schema-flexible nature of document DBs means you can add, remove, or change fields across documents over time without costly migrations, making them ideal when requirements evolve. A is wrong — document databases store structured/semi-structured data (JSON, BSON); they are not specifically optimised for raw binary data, which is better handled by object stores or blob storage. B is wrong — joins across documents are a known weakness; document DBs encourage embedding related data in a single document to avoid joins. C is wrong — multi-document ACID transactions are complex in document DBs and were historically unsupported; they are a strength of RDBMSs instead.

B is correct — graph databases are founded on graph theory; nodes represent entities and edges represent relationships, drawing directly from mathematical graph structures. D is correct — social networks are the canonical use case for graph databases; the friend/follow/like relationships map perfectly to nodes and edges. A is wrong — tabular storage is the hallmark of relational databases; graph databases store nodes and edges, not rows and columns. C is wrong — this is the opposite; graph databases are specifically designed for complex relationships, which is exactly where they outperform other models. E is partially misleading — graph databases do handle many relationship types well, but they are distinct from relational databases; calling it "relational modeling" conflates two separate concepts.

A is correct — MongoDB is designed to remain partially available when some shards go down; it can still serve reads and writes on the available shards rather than failing completely. C is correct — in MongoDB's sharded architecture, mongos is the query router that processes all client requests, directing them to the appropriate shard(s). B is wrong — config servers store cluster metadata (which data lives on which shard), but they do not process client requests; that is mongos's role. D is wrong — while config servers do use replication for reliability, saying they are "implemented as replica sets" in the same way shards are oversimplifies the architecture distinction the question is testing. E is wrong — config servers store the routing metadata, but it is mongos that uses that metadata to decide how to distribute a query.