Q12Big Data Analytics

Relational databases (RDBMS) are table-based, highly structured, and strictly adhere to ACID properties, making them suitable for complex queries. NoSQL databases can be document-based, key-value pairs, graph, or wide-column stores. They offer horizontal scalability, flexible data models, and are better suited for hierarchical data and large-scale big data applications.

Key points of comparison

• Schema: RDBMS enforces a fixed schema defined before data is inserted (schema-on-write); NoSQL stores are typically schema-less or apply the schema only when data is read (schema-on-read), letting each document or row carry a different set of fields.
• Scaling model: RDBMS traditionally scales vertically (bigger server, faster CPU/disk); NoSQL systems are designed to scale horizontally by adding commodity nodes and sharding data across them.
• Consistency guarantees: RDBMS guarantees strong consistency and ACID transactions across tables via joins and foreign keys. Most NoSQL databases favor the BASE model (Basically Available, Soft state, Eventually consistent) and the CAP theorem trade-offs, sacrificing strict consistency for availability and partition tolerance.
• Query language: RDBMS uses standardized SQL with powerful joins and aggregations. NoSQL query APIs vary by product (MongoDB's query language, CQL for Cassandra, key lookups for Redis) and generally avoid expensive cross-partition joins.
• Use cases: RDBMS (MySQL, PostgreSQL, Oracle) suits banking, ERP, and any domain needing transactional integrity. NoSQL (MongoDB, Cassandra, Redis, Neo4j) suits high-velocity, high-volume workloads like social feeds, session stores, sensor data, and recommendation graphs where write throughput and flexible schemas matter more than joins.
• Joins: RDBMS supports arbitrary multi-table joins natively at the query engine level; most NoSQL databases avoid joins altogether, favoring denormalized documents or pre-computed aggregates so a single read can be served from one partition without cross-node coordination.

In practice, large systems rarely pick one model exclusively -- a typical big data architecture keeps transactional order and payment records in an RDBMS for strict consistency, while routing high-volume clickstream and log data into a NoSQL store like Cassandra or a document store like MongoDB for cheap horizontal scaling and flexible schema evolution.