Chapter – 3(half unit)

[Link] is a Key-Value Store

Key-Value Store
A Key-Value Store is the simplest type of NoSQL database where data is stored as a
collection of key–value pairs.
 Key: A unique identifier (like an index).
 Value: The data associated with that key (can be string, JSON, binary, etc.).
This model is highly optimized for fast lookups and simple reads/writes.

Characteristics:
 Schema-less: No predefined structure for values.
 Scalability: Easily scales horizontally across servers.
 High Performance: Efficient for read/write-heavy applications.
 Simple Queries: Direct retrieval by key (no joins).

Examples of Key-Value Stores:

 Redis
 Amazon DynamoDB
 Riak
 Memcached

Use Cases:
 Caching: Storing session or frequently accessed data (e.g., web sessions in Redis).
 User Preferences: Key = user ID, Value = profile/preferences.
 Shopping Carts: Key = cart ID, Value = cart items.

Example (Pseudo Data):

Key → Value
"user:101" → {"name":"Alice", "age":25, "email":"alice@[Link]"}
"user:102" → {"name":"Bob", "age":30, "email":"bob@[Link]"}

Advantages:
 Very fast retrieval.
 Handles large-scale data easily.
 Flexible values (binary, JSON, etc.).

Limitations:
 Limited query capability (no complex queries, joins).
 Not suitable for relational/transactional applications.

1 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

[Link]-Value Store Features
A Key-Value Store is the simplest type of NoSQL database where data is stored as a
collection of key-value pairs.
 Key: Unique identifier (like a primary key in SQL).
 Value: Associated data (can be string, JSON, XML, or binary).

1. Simple Data Model

o Data is stored as a collection of key–value pairs.
o Each key is unique and maps to exactly one value.
2. Schema-less
o Values can be any type of data (JSON, string, blob, object, etc.).
o No predefined schema required.
3. Efficient Lookup
o Optimized for fast retrieval using the key.
o Provides constant-time (O(1)) access in most implementations.
4. Scalability
o Supports horizontal scaling by partitioning/sharding data across nodes.
o Handles very large datasets efficiently.
5. High Performance
o Designed for high-speed reads/writes, often in-memory or with efficient disk
usage.
6. Flexible Data Storage
o Values can hold structured, semi-structured, or unstructured data.
7. Eventual Consistency (in distributed systems)

2 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

 o Often trades strong consistency for availability and partition tolerance (CAP
theorem).
8. Replication Support
o Provides redundancy and fault tolerance through replication.
9. Simple Operations
o Main operations: GET, PUT, DELETE.
o Lacks complex queries or joins like SQL.
10. Common Use Cases
 Caching (e.g., Redis, Memcached)
 Session management
 User profiles, shopping carts
 Large-scale web applications needing fast lookup
Examples of Key-Value Stores
 Redis → Caching, real-time analytics, session management.
 Amazon DynamoDB → Large-scale e-commerce, IoT applications.
 Riak → Distributed systems, high availability use cases.
 Memcached → Web caching, reducing database load.

[Link] in a Key-Value Store

1. Introduction
 In key-value stores, data is stored as {Key → Value} pairs.
 Since they are often distributed across multiple nodes, ensuring consistency of data
is a challenge.
 Consistency here means: when multiple clients read/write the same key, they should
see the same value (or a value that makes sense under the model chosen).
2. Types of Consistency
(a) Strong Consistency
 Every read returns the most recent write.
 Guarantees correctness but can cause delays (high latency).
 Example: Traditional Relational DBs or single-node KV stores.
(b) Eventual Consistency
 Updates propagate gradually to all replicas.
 Reads may temporarily return stale data.
 Eventually, all replicas converge to the same state.
 Example: Amazon DynamoDB, Cassandra.
(c) Causal Consistency
 Ensures that if one operation happens-before another, then all clients see them in that
order.
 More relaxed than strong consistency but safer than eventual.
(d) Read-Your-Writes Consistency
 A client always sees its own updates immediately.
 Other clients may still see stale values.
(e) Session Consistency
 Guarantees consistency only within a session between client and server.

3 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

  Example: Shopping cart systems.

3. Challenges in Key-Value Consistency

 Network partitions → Nodes may get disconnected.
 Replication delays → Updates may not reach all replicas at once.
 CAP Theorem → Only two of {Consistency, Availability, Partition Tolerance} can
be fully achieved.

4. Relaxing Consistency in Key-Value Stores

 Many NoSQL KV stores trade strong consistency for:
o Availability (system always responds).
o Performance (low latency, high throughput).
 Applications choose based on their needs:
o Banking → needs strong consistency.
o Social media feeds → eventual consistency is acceptable.

5. Example
 Amazon DynamoDB:
o Offers eventual consistency (default) and strong consistency (optional) for
reads.
o Developers choose based on cost-performance tradeoff.
Key
Consistency in key-value stores is not one fixed model but a spectrum — from strong to
eventual — chosen depending on application needs.

4 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

[Link] in a Key-Value Store
🔹 Introduction
 Key-Value Stores are the simplest form of NoSQL databases.
 They store data as a collection of key-value pairs, where the key is unique and is
used to retrieve the associated value.
 Transactions in Key-Value stores ensure atomicity, consistency, isolation, and
durability (ACID) properties to some extent, depending on the system design.

🔹 Transaction Characteristics in Key-Value Stores

1. Atomic Operations
o Most Key-Value stores allow single key atomic operations (get, put, delete).
o Atomicity across multiple keys is often limited or absent.
2. Consistency
o Many Key-Value databases provide eventual consistency rather than strong
consistency.
o Some systems allow configuration of read/write consistency levels (e.g.,
quorum-based reads/writes).
3. Isolation
o Operations on a single key are isolated.
o Multi-key isolation is harder and not guaranteed in many Key-Value systems.
4. Durability
o Ensured through mechanisms like write-ahead logs (WAL) or replication.
o Durability can be relaxed in exchange for higher performance.

🔹 Transaction Models in Key-Value Stores

1. Single-Object Transactions
o Each read/write operation on a key is atomic.
o Example: PUT(user123, {name:"John", balance:1000}).
2. Multi-Key Transactions
o Supported only in some systems (e.g., Redis with MULTI/EXEC).
o Other systems rely on application-level transaction management.
3. Optimistic Concurrency Control

5 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

 o Some Key-Value stores provide version stamps or compare-and-swap
operations to prevent overwriting concurrent updates.

🔹 Example Systems & Support

 Redis
o Provides transaction blocks with commands like MULTI, EXEC, WATCH.
 Amazon DynamoDB
o Supports ACID transactions for multiple items across one or more tables.
 Riak, Voldemort
o Favor eventual consistency and partition tolerance, weaker multi-key
transaction support.
o
Here are examples of query features that might be involved in transactions within key-value
databases, expressed as key-value pairs or related concepts:

1. Atomicity and Consistency:

 Key: transaction_id
 Value: [ { "action": "update", "key": "user:account:123", "value": {"balance": 100} }, {
"action": "update", "key": "log:transaction:456", "value": {"status": "committed", "amount":
100} } ]
o This represents a single atomic transaction involving multiple updates. If one update fails, the
entire transaction is rolled back, ensuring consistency.

2. Isolation:
 Key: lock_on_key:user:account:123
 Value: transaction_id:T1
o This indicates that a lock is held on user:account:123 by transaction T1 , preventing other
transactions from accessing or modifying this key until T1 completes or releases the lock.

3. Durability:
 Key: transaction:456:state
 Value: committed
o This signifies that the transaction 456 has been successfully committed and its changes are
permanently stored, even in case of system failures.

4. Concurrency control and conflict resolution:

 Key: user:data:version:user_id_1
 Value: 5 (representing the current version of the data)
 Key: transaction:T2:conflict
 Value: {"key": "user:data:version:user_id_1", "expected_version": 4, "actual_version": 5}

6 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

o In systems with optimistic concurrency control, this shows a conflict detected during the
validation phase when a transaction ( T2 ) tried to modify data ( user:data:version:user_id_1 )
that had been updated by another transaction after T2 began.

5. Secondary Indexes (for richer queries):

 Key: user_email:[Link]@[Link]
 Value: user:account:123
o While not directly a transaction feature, secondary indexes are vital for querying beyond the
primary key. This example allows retrieval of the user:account key using the user's email
address as an alternative lookup mechanism.

🔹 Challenges in Key-Value Transactions

 Limited support for multi-key, multi-object transactions.
 Trade-off between consistency, availability, and performance (CAP theorem).
 Applications often need to manage transaction logic at the application layer.

🔹 Summary
 Transactions in Key-Value stores are simpler compared to RDBMS.
 Strong guarantees typically apply to single-key operations.
 For multi-key operations, developers must often rely on application-level
transaction handling or eventual consistency models.

[Link] Features in a Key-Value Store

1. Introduction
 A Key-Value Store is the simplest type of NoSQL database.
 Data is stored as a collection of key-value pairs.
 The key is unique and acts like a primary key in relational systems, while the value is
usually an opaque blob (string, JSON, binary, etc.).
 Because of this simplicity, query features are limited compared to SQL databases.

2. Basic Query Features

1. Get by Key
o The most fundamental query is retrieving a value by its key.
o Example: GET("customer:1001") → returns customer record
2. Put by Key
o Insert or update a value with a specific key.
o Example: PUT("order:2001", {“item”:“Laptop”, “price”:60000})
3. Delete by Key
o Remove a key-value pair from the store.
o Example: DELETE("order:2001")
o

7 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

3. Advanced Query Features (Depending on Implementation)
1. Range Queries (not supported by all systems)
o Some key-value stores support ordered keys (e.g., Riak, Redis, Amazon
DynamoDB).
o Example: fetch all keys between user:1000 and user:2000.
2. Secondary Indexes
o Traditional key-value stores do not support queries on values.
o Some modern stores (e.g., DynamoDB, Redis, FoundationDB) allow
indexing fields inside values.
o Example: query by email instead of userID.
3. Composite Keys
o Keys can be structured (e.g., "user:1001:orders:01").
o Enables hierarchical queries such as fetching all orders for a user.
4. Query by Value (Limited)
o Generally, values are opaque. However, some implementations allow
searching inside JSON or XML documents stored as values.

4. Performance Characteristics
 Queries are fast (constant-time lookup) because retrieval is based on hashing or key
indexing.
 No complex joins or aggregations → better performance at web scale.
 Designed for high availability and horizontal scalability.

5. Use Cases
 Session management (store session tokens).
 Shopping cart (cart ID as key, items as value).
 Caching layer (Redis, Memcached).
 User profiles (userID → profile details).

6. Limitations of Querying in Key-Value Stores

 No ad-hoc queries like SQL.
 No JOINs, GROUP BY, or complex aggregations.
 Requires application logic for handling relationships.

8 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

  Indexing is minimal compared to relational databases.

Summary:
Key-value stores focus on fast, simple queries (by key), with limited advanced querying
(range, secondary indexes, composite keys) depending on the system. They trade query
richness for speed, scalability, and simplicity.

[Link] of Data in a Key-Value Store

 A Key-Value Store is the simplest type of NoSQL database.

 Data is represented as a collection of key-value pairs.
 Each key is unique, and its value can be any kind of data: string, number, JSON,
binary, etc.
 The database functions much like a hash table or dictionary.

2. Structure of Data
 Key → Identifier (unique, often string/UUID).
 Value → Data associated with the key.
 Storage is opaque (database does not interpret the value, only stores/retrieves it).
Representation:
Key → Value
"user:101" → { "name": "Alice", "age": 25, "email": "alice@[Link]" }
"product:501" → { "id": 501, "name": "Laptop", "price": 60000 }
"cart:xyz123" → [501, 502, 503]

3. Characteristics
 Schema-less: No predefined schema; values can be different structures.
 High Scalability: Easy to partition (shard) across multiple servers.
 Fast Lookups: Optimized for O(1) access using keys.
 Flexibility: Values can hold complex objects (JSON, XML, BLOB).

9 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

4. Example Implementations
 Redis – In-memory key-value store.
 Amazon DynamoDB – Scalable key-value store in cloud.
 Riak – Distributed key-value database.

5. Real-World Example
 Session Management:
o Store user sessions in a key-value format.
o session:abc123 → { "user_id": 101, "last_login": "2025-08-17" }
 Caching:
o Frequently accessed data stored in Redis.
 Shopping Carts:
o Each user’s cart stored as a value against their ID.

6. Advantages
 Simplicity: Easy to understand and implement.
 Performance: High throughput and low latency.
 Scalability: Works well in distributed environments.

Key Takeaway:
The structure of data in a Key-Value Store is straightforward: each unique key maps to a
value, with no fixed schema, making it highly flexible, scalable, and ideal for use cases like
caching, session management, and shopping carts.

7. Scaling in a Key-Value Store

 Key-Value Stores (KVS): Simplest type of NoSQL database.
 Data stored as (key, value) pairs.
 Scaling is critical as applications grow in data size and concurrent user requests.

2. Approaches to Scaling
(a) Vertical Scaling (Scaling Up)
 Increase capacity of a single machine (CPU, RAM, Disk).
 Pros: Simple to manage.
 Cons: Limited by hardware constraints, expensive.
(b) Horizontal Scaling (Scaling Out)
 Add more servers (nodes) to the system.
 Each node manages a portion of the data.
 Achieved via partitioning/sharding.

3. Techniques in Horizontal Scaling

i. Sharding (Partitioning)
 Data divided into smaller subsets, stored across multiple nodes.
 Methods:
o Range-based partitioning (based on key ranges).

10 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

 o Hash-based partitioning (using hash function on keys).
 Example: Redis Cluster, DynamoDB.
ii. Replication
 Copy of same data maintained across multiple nodes.
 Provides fault-tolerance and high availability.
 Types:
o Master-Slave Replication (writes to master, reads from slaves).
o Peer-to-Peer Replication (all nodes equal).
iii. Consistent Hashing
 Keys distributed to nodes using a hash ring.
 Reduces data movement when nodes are added/removed.
 Widely used in systems like Amazon Dynamo, Riak.

4. Challenges in Scaling
 Consistency vs. Availability vs. Partition Tolerance (CAP Theorem).
 Balancing load distribution across nodes.
 Managing failures and recovery.
 Handling hotspot keys (frequently accessed keys).

5. Examples of Key-Value Stores and Scaling

 Amazon DynamoDB:
o Scales automatically using partitioning + replication.
 Redis Cluster:
o Supports horizontal scaling using sharding.
 Riak:
o Implements consistent hashing for automatic distribution.

6. Summary
 Scaling in a key-value store ensures performance, availability, and reliability.
 Relies heavily on sharding, replication, and consistent hashing.
 Real-world large-scale systems (Amazon, Facebook, LinkedIn) use these techniques
to manage huge volumes of data.


11 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

[Link] Use Cases in a Key-Value Store
 Key-Value Store is the simplest form of NoSQL database.
 Stores data as a collection of key–value pairs.
 Key → Unique Identifier (like a hash or string).
 Value → Data associated with that key (could be text, JSON, image, video, etc.).
 Very fast for read and write operations because retrieval is based on keys only.

2. Suitable Use Cases

(a) Session Management
 Storing user session data (login status, preferences, temporary cache).
 Example: Amazon DynamoDB, Redis, Memcached widely used for session storage.
(b) Shopping Cart Data
 Each cart can be stored as a key-value pair where:
o Key = User ID
o Value = Items in the cart
 Allows quick updates and retrievals.
 Example: Walmart uses key-value systems for cart management.
(c) User Profile Information
 Profiles are small datasets accessed by unique IDs.
 Keys = User IDs; Values = Profile details (name, email, preferences).
 Example: Facebook and Twitter store user sessions & preferences in key-value
databases.
(d) Caching and Temporary Data
 Used to cache results of expensive operations or frequently accessed pages.
 Speeds up system performance.

12 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,

  Example: YouTube, Netflix use Redis/Memcached for caching video metadata and
search queries.
(e) Real-Time Analytics (High Speed Requirements)
 Applications where low-latency data access is crucial.
 Example: Gaming industry (storing leaderboards, scores, and player states).
(f) IoT Data Collection
 IoT devices continuously send small key-value data points (sensor → value).
 Example: Smart home applications use DynamoDB/Redis to log sensor readings.

3. Advantages of Key-Value Stores

 High performance for simple queries.
 Scalable (horizontal scaling).
 Schema-less (flexible structure).
 Ideal for applications with simple access patterns.

4. Limitations (When Not Suitable)

 Not ideal when:
o Complex queries needed.
o Relationships between entities matter.
o Multi-field search is required.

Summary
Key-Value stores are best suited for session data, shopping carts, caching, user profiles,
IoT data, and real-time analytics where high speed and scalability are more important than
complex queries.

13 | NOSQL DATABASES-Unit-III / [Link] B.E.,M.E.,(Ph.D).,MBA.,