4.4.24
Relational databases (SQL) har row ko ek rigid table mein fixed columns ke saath force karte hain, aur strong consistency guarantee karte hain — lekin horizontal scaling ki cost pe. NoSQL = "Not Only SQL " —
databases ki ek family jo kuch guarantees drop karti hai taaki kuch aur gain ho sake :
flexible schema, massive horizontal scale, ya fast specialised access patterns.
Sabse important idea ek hi hai: aap woh data model chunte ho jo aapke access pattern se match kare ,
na ki har problem ko rows-and-columns mein force karo.
Definition Chaar NoSQL data models
Document (MongoDB): self-contained JSON/BSON documents store karta hai jo _id se key hote hain. Schema-flexible.Key-Value (Redis): ek giant in-memory hash map : key → value (blob/string/list/set/hash). Sabse fast.Column-family / wide-column (Cassandra): rows key se partition hoti hain, har row ek sparse map of columns hoti hai. Write-heavy scale ke liye bana.Graph (Neo4j): data as nodes + relationships (edges) with properties . Traversals ke liye bana.
Intuition Documents kyun?Zyaadatar application objects (ek user with addresses, ek blog post with comments) naturally nested hote hain.
SQL unhe kai tables mein split karega aur read time pe JOIN karega. Ek document poore object ko
saath rakhta hai → ek read mein poori entity return hoti hai (locality), koi joins nahi.
// Ek single document — schema per-document hai, per-table nahi { "_id" : ObjectId ( "..." ), "name" : "Asha" , "emails" : [ "asha@x.com" ], // arrays allowed "address" : { "city" : "Pune" , "pin" : 411001 } // nested doc } db.users. find ({ "address.city" : "Pune" }) // nested fields mein query
Indexing : kisi bhi field pe B-tree indexes (nested bhi). Index ke bina query ek O ( N ) Tradeoff : data aksar denormalised/duplicated hota hai → fast reads, lekin duplicated data ko update karna mushkil hota hai.
Intuition Key-value kyun?Agar aap hamesha ek single known key se fetch karte ho (session token, cache entry, counter), to aapko
query engine ki zaroorat hi nahi. Ek hash map ==average O ( 1 ) RAM mein rakhta hai → microsecond latency.
SET session:abc "{...}" EX 3600 # value with 1-hour TTL GET session:abc INCR page:views # atomic counter LPUSH queue task1 # built-in list/set/sorted-set types
Use cases: caching, rate-limiting, leaderboards (sorted sets), pub/sub, queues.
Tradeoff : limited query power (key pata honi chahiye); data mostly memory mein fit hona chahiye.
Intuition Wide-column kyun?Write-heavy, globally distributed workloads ke liye (time-series, event logs), aap chahte ho koi single
master na ho aur linear scaling ho. Cassandra partition key ko hash karta hai yeh decide karne ke liye ki kaunsa node row store karega, isliye writes evenly spread hoti hain. Aap table ko us query ke around design karte ho jo run karni hai , entities ke around nahi.
CREATE TABLE sensor_data ( sensor_id text , ts timestamp , value double, PRIMARY KEY (sensor_id, ts) -- partition key = sensor_id, clustering key = ts );
Partition key → kaunsa node; clustering key → ek partition ke andar sort order.Writes ek log-structured merge (LSM) path use karti hain (commit log + memtable mein append → SSTable mein flush), isliye writes bahut fast aur append-only hoti hain.
Tradeoff : koi joins nahi, koi ad-hoc queries nahi — query patterns pehle se pata hone chahiye.
Jab relationships HI data hain (social networks, recommendations, fraud rings), SQL ko repeated self-joins chahiye jinki cost depth ke saath explode hoti hai. Ek graph DB har node ko apne neighbours ke direct
pointers ke saath store karta hai ("index-free adjacency"), isliye ek hop O ( 1 )
MATCH (a:Person { name : 'Asha' } ) - [: FRIEND ] -> (b) - [: FRIEND ] -> (c) RETURN c.name // friends-of-friends do saste hops mein
Tradeoff : huge bulk aggregations ke liye nahi bana; machines pe shard karna mushkil hai.
Ek distributed store mein, network Partition (P) ke dauran aap sirf ek rakh sakte ho:
C onsistency (har read latest write dekhe) ya A vailability (har request ko non-error response mile).
Isliye real systems partition hone pe CP ya AP choose karte hain.
Definition BASE (AP philosophy)B asically A vailable, S oft state, E ventually consistent — SQL ke ACID ka ulta.
Replicas thodi der ke liye alag-alag ho sakte hain lekin messages flow hone pe converge karte hain. Quorums se tunable:
Worked example Database choose karnaProblem: Ek shopping-cart cache, varying attributes wala product catalog, ek event log, aur ek "jo log X kharide unhone Y bhi khareeda" feature banao.
Cart/session → Redis . Yeh step kyun? Ek session key se fetch hota hai, speed & TTL chahiye → key-value.Catalog → MongoDB . Kyun? Har product ke alag fields hain (book mein author, shirt mein size) → flexible documents.Event log → Cassandra . Kyun? Bahut badi append-only write rate, user_id se partitionable → wide-column.Recommendations → Neo4j . Kyun? Yeh relationship traversal hai (bought→product←bought) → graph.
Worked example Quorum tuningProblem: N = 3 Strong consistency ke liye W , R
W = 2 , R = 2 Kyun? W + R = 4 > 3 = N Alternative W = 3 , R = 1 4 > 3 sabhi 3 ka wait karenge → kam write-available.
W = 1 , R = 1 2 > 3 eventual consistency, sabse fast, lekin read fresh write miss kar sakta hai.
Worked example Mongo nesting SQL joins se kyun better hai ek entity ke liyeEk blog post + 50 comments fetch karna: Mongo = ek document ki 1 read .
SQL = posts read + comments read+join (har comment block ke liye extra index lookup).
Yeh kyun matter karta hai: jab access pattern "poora object do" ho tab kam round-trips aur disk seeks.
Common mistake "NoSQL matlab no schema, isliye kuch design karne ki zaroorat nahi."Kyun sahi lagta hai: aap bina CREATE TABLE ke koi bhi document insert kar sakte ho.
Fix: schema database se aapke application + queries mein shift ho jaata hai. Cassandra mein
aapko table design zaroor karni hogi query ke around (baad mein JOIN nahi kar sakte). "Schema-flexible" ≠ "schema-free".
Common mistake "NoSQL hamesha faster / hamesha SQL se better scale karta hai."Kyun sahi lagta hai: marketing + genuine horizontal-scale wins.
Fix: yeh sirf matching access pattern ke liye faster hai. Ad-hoc queries, multi-entity joins,
aur strong transactions aksar slower ya impossible hote hain. Galat access pattern = slow NoSQL.
Common mistake "CAP mujhe Partition-tolerance drop karne aur C aur A dono rakhne deta hai."Kyun sahi lagta hai: "2 of 3" sunne mein lagta hai aap freely choose karte ho kya drop karna hai.
Fix: distributed system mein partitions HOGI hi (cables, GC pauses). P optional nahi hai,
isliye real choice hai partition ke dauran CP vs AP .
Common mistake "Eventual consistency = database toot gaya / data lose ho gaya."Kyun sahi lagta hai: ek baar read ne stale data return kiya.
Fix: yeh ek temporary divergence hai jo nodes sync hone pe converge karta hai; W + R > N
NoSQL ka full form kya hai? "Not Only SQL" — non-relational databases ki ek family jo specific data models/scale ke liye optimised hai.
Chaar NoSQL families ke naam batao ek-ek example ke saath. Document(MongoDB), Key-Value(Redis), Wide-Column(Cassandra), Graph(Neo4j).
Redis ~O ( 1 ) Yeh ek in-memory hash map hai jo exact keys se keyed hai.
Graph DBs mein "index-free adjacency" kya hai? Har node apne neighbours ke direct pointers store karta hai, isliye ek hop O ( 1 )
Cassandra mein partition key kya decide karta hai vs clustering key? Partition key → kaunsa node row store karta hai; clustering key → us partition ke andar sort order.
CAP theorem state karo. Network partition ke dauran aap sirf Consistency YA Availability rakh sakte ho, dono nahi.
Strong consistency ke liye quorum condition batao. W + R > N
N = 3 W = 2 , R = 2 4 > 3
BASE ka full form kya hai? Basically Available, Soft state, Eventually consistent.
Practice mein CAP mein "P" kyun assume karna padta hai? Network partitions unavoidable hain, isliye real choice CP vs AP hai.
MongoDB SQL joins ko kab beat karta hai? Jab aap ek nested entity fetch karo — yeh ek single document read hai bina joins ke.
Cassandra writes ke liye fast kyun hai? LSM: commit log + memtable mein append, baad mein immutable SSTables mein flush.
Recall Feynman: 12-saal ke bachche ko samjhaoSocho apna samaan rakhne ke chaar tarike.
Redis numbered lockers ki ek row hai — locker number pata hai, toh turant pakad lo, super fast,
lekin number yaad rakhna hoga.
MongoDB ek folder hai jahan har khilona apne complete box mein aata hai, saare chhote parts andar — ek box uthao, sab mil gaya.
Cassandra ek giant warehouse hai kai workers ke saath; naye boxes workers ke beech split ho jaate hain taki kabhi overwhelmed na hon, lekin store karne se pehle boxes label karne padte hain.
Neo4j ek friendship map hai: har bachche ne ek string pakdi hai har dost ki taraf, isliye "dosto ke dost dhundho" sirf strings follow karna hai — poora school search karne ki zaroorat nahi.
Aur CAP : agar do warehouses ke beech phone lines band ho jaayein, to ya toh wait karo jab tak reconnect ho
(sahi lekin slow) ya possibly-purani info ke saath answer do (fast lekin maybe stale). Dono ek saath nahi ho sakta.
Mnemonic Chaar + unki strength yaad karo"Dr. Kev's Cool Graph" → D ocument, K ey-value, C olumn, G raph.
Strengths: D ocument = Detail-rich objects , K ey-value = Quick(K) , C olumn = Colossal writes , G raph = Going through links .
Partition ke dauran CAP: "Choose C or A, P is a given."
NoSQL ke 80% decisions ek sawaal pe aa jaate hain: "Mera dominant access pattern kya hai?"
Single key → Redis. Poora nested object → Mongo. Massive ordered writes → Cassandra. Deep relationships → Neo4j.
Aur hamesha yaad rakho: partition ke neeche freshness vs availability ke liye W + R > N
SQL Relational Databases — ACID, JOINs, normalization (contrast class)CAP Theorem / BASE vs ACID Database Indexing (B-tree, LSM) — Mongo reads vs Cassandra writes kyunHashing and Hash Maps — key-value & partitioning ki basisSharding and Replication Caching Strategies — Redis as a cache layerGraph Traversal Algorithms (BFS/DFS) — Neo4j kya optimise karta hai
Flexible schema and scale
Partition key spreads writes
