UNIT – III: KEY–VALUE DATABASES (EXAM
STUDY NOTES)
1. What Is a Key–Value Store
A Key–Value Store is the simplest form of NoSQL database where data is stored as unique
key–value pairs. Each key is unique and used to retrieve a value. The value can be any type of
data — string, JSON, binary, etc. Examples: Redis, Riak, DynamoDB, Voldemort, Memcached.
2. Key–Value Store Features
• Schema-less (no predefined columns or data types).
• Simple operations: PUT, GET, DELETE.
• High read/write performance using hash lookups.
• Supports replication and sharding for distributed systems.
• In-memory or persistent storage (Redis can do both).
• No relationships or joins; one key maps to one value.
3. Consistency
Consistency ensures data uniformity across multiple replicas.
Types:
- Strong Consistency: All reads return the latest write.
- Eventual Consistency: Replicas may temporarily differ, but converge.
- Tunable Consistency: Achieved using quorum (R + W > N).
Example: In DynamoDB, developers can choose read/write consistency per request.
4. Transactions
Key–Value stores often follow BASE instead of ACID properties.
BASE: Basically Available, Soft-state, Eventually Consistent.
Some like Redis support atomic single-key operations (INCR, DECR) or multi-key via
MULTI/EXEC.
5. Query Features
• Data retrieved only using keys.
• No querying or filtering on values.
• Example (Redis):
SET user:101 '{"name":"Sai","age":22}'
GET user:101
• No SQL-like querying; application must handle filtering manually.
6. Structure of Data
Values are opaque to the database. They may be JSON, XML, binary objects, or serialized data.
The database doesn’t interpret internal structure — only the key is indexed.
7. Scaling
Scaling is achieved via:
• Sharding: Splitting key space across nodes using hashing.
• Replication: Duplicating data across nodes for fault tolerance.
• Consistent Hashing: Efficiently distributes data when nodes join/leave.
8. Suitable Use Cases
Key–Value stores are ideal when data access is simple and key-based:
- Session management
- User profiles and preferences
- Shopping carts
- Caching and leaderboard systems
- Real-time analytics metadata
9. Storing Session Information
Session data stored with unique keys and set expiration (TTL).
Example:
SET session:101 '{"user":"Sai"}'
EXPIRE session:101 3600 (1 hour).
10. User Profiles and Preferences
Each user profile stored under a unique key.
Example:
Key: user:201
Value: {'name':'Sai','theme':'Dark','lang':'English'}
Simple to update and retrieve with GET/PUT operations.
11. Shopping Cart Data
Each user’s cart stored as a list or set.
Example (Redis):
LPUSH cart:201 'item1'
LRANGE cart:201 0 -1 → ['item1']
Fast, scalable, and easy to clear upon checkout.
12. When Not to Use
Avoid Key–Value stores when:
- You need relational joins or relationships.
- You need multi-key transactions.
- You must query/filter data by attributes.
- You require analytical or reporting queries.
13. Relationships among Data
Key–Value stores do not store relationships. Each entry is independent.
Links between keys must be handled in the application logic.
14. Multioperation Transactions
Most Key–Value stores don’t support transactions over multiple keys.
Redis provides partial support using MULTI/EXEC for grouped operations.
15. Query by Data
Key–Value stores can’t perform 'query by value' searches like SQL.
Example: You can’t ask “find all users where city='Hyderabad'”. Requires manual secondary index
tables or external indexing systems.
16. Operations by Sets
Redis supports Set operations useful for social and analytics apps:
SADD friends:101 'Sai' 'Teja' 'Ravi'
SADD friends:102 'Ravi' 'Kiran'
SINTER friends:101 friends:102 → ['Ravi']
17. Summary
Key–Value databases provide extreme performance and scalability for simple lookups. They
trade off complex queries and relationships for speed and simplicity.
Examples: Redis, Riak, DynamoDB, Memcached.
Best for: Sessions, Caches, Shopping Carts, User Preferences.
Quick Revision Table
| Aspect | Description |
|--------|--------------|
| Data Model | Key–Value pairs |
| Query Type | By key only |
| Schema | None (flexible) |
| Consistency | Eventual / Tunable |
| Transactions | Single-key atomic |
| Scalability | High via sharding |
| Examples | Redis, DynamoDB, Riak |
| Ideal Use | Sessions, caching, profiles |