Evolution of MySQL, Rise of NoSQL, and In‑Depth Redis Data Types and Usage

1. MySQL Evolution

In the 1990s a single‑node MySQL architecture (APP → Middleware → MySQL) was sufficient; as traffic grew, vertical sharding and read/write splitting (master‑write, slave‑read) became necessary. Cache layers such as file caching and later Memcached were added to relieve pressure. Eventually horizontal scaling with multiple MySQL clusters and database/table partitioning became the norm.

Storage engines also changed: early MySQL used MyISAM (table‑level locking, no transactions), later switching to InnoDB (row‑level locking, ACID support, crash recovery, foreign keys).

New challenges from mobile and social applications led to the adoption of NoSQL for user profiles, geolocation, and social graphs.

2. The Rise of NoSQL

2.1 What is NoSQL?

NoSQL (Not Only SQL) offers flexible data models (key‑value, document, column, graph), schema‑less design, and high scalability for massive data workloads.

2.2 RDBMS vs. NoSQL Comparison

Comparison

RDBMS

NoSQL

Data structure

Structured tables

Flexible (key‑value, document, column, graph)

Query language

SQL

API or SQL‑like

Consistency

Strong

Eventual (CAP theorem)

Transaction support

ACID

Weaker, favoring scalability

Typical use cases

Finance, legacy systems

Social media, content delivery, log storage

Typical enterprise stack: MySQL + Redis .

2.3 NoSQL Use Cases (e.g., Taobao product page)

Structured product info & comments → MongoDB

Large images → FastDFS , OSS

Search keywords → ElasticSearch

Hot items & flash‑sale cache → Redis , Tair , Memcached

Transactions/payments → relational DB (MySQL)

2.4 Four Main NoSQL Categories

Type

Representative Products

Description

Key‑Value store

Redis, Tair, Memcached

Fast access, ideal for caching

Document DB

MongoDB

JSON‑like flexible structure

Column store

HBase, Cassandra

Optimized for massive writes and analytics

Graph DB

Neo4j

Handles complex network relationships (social, recommendation)

3. Redis Overview

3.1 What is Redis?

Redis stands for Remote Dictionary Server. It is an in‑memory data store offering extreme speed, optional persistence, rich data structures, and capabilities such as pub/sub, geospatial queries, timers, and counters.

3.2 Installation & Quick Start

Windows: download redis-cli.exe , redis-server.exe , redis-benchmark.exe .

Linux:

sudo apt-get install redis-server && systemctl start redis && redis-cli -p 6379

Performance test example:

redis-benchmark -h localhost -p 6379 -c 100 -n 10000

Default port is 6379 . Simple connectivity test: ping → pong .

4. Redis Core Concepts

4.1 Database Management

Redis provides 16 logical databases (0‑15). Common commands:

select 0   # switch DB
DBSIZE       # key count in current DB
flushdb      # clear current DB
flushall     # clear all DBs

4.2 Single‑Threaded High Performance

Redis uses a single‑threaded event loop, avoiding lock contention; bottlenecks are usually memory or network bandwidth, not CPU.

4.3 Persistence Mechanisms

RDB snapshot : periodic dump of memory to disk.

AOF log : append‑only log of every write operation, replayable for recovery.

4.4 Memory Management & Eviction Policies

Configure maxmemory to cap RAM usage. When exceeded, Redis can evict keys using LRU, LFU, or TTL policies.

5. Redis Data Types

5.1 String

Basic binary‑safe byte array. Supports set/get, expiration, append, incr/decr, range queries, batch operations (mset/mget), and storing JSON objects.

Implementation uses SDS (Simple Dynamic String) for small strings and integer encoding for pure numbers, providing O(1) length access and reduced memory.

5.2 List

Ordered collection usable as stack, queue, or blocking queue. Core commands: LPUSH , RPUSH , LPOP , RPOP , LRANGE , RPOPLPUSH , LSET , LINSERT . Internally Redis uses ziplist for small lists and quicklist (compressed ziplist + linked list) for larger ones.

Typical uses: message queues, task buffers, recent‑activity feeds, limited‑size logs.

5.3 Set

Unordered collection of unique elements. Core commands: SADD , SREM , SISMEMBER , SCARD , SINTER , SUNION , SDIFF , SRANDMEMBER , SPOP . Small integer sets use intset ; larger or non‑integer sets use hash tables.

Common scenarios: user tags, deduplication, follower/following relationships.

5.4 Hash

Key‑to‑field map, ideal for storing object attributes. Commands: HSET , HGET , HDEL , HINCRBY , HGETALL , HSCAN . Small hashes use ziplist; larger ones switch to a hash table automatically.

Typical uses: user profiles, product SKU caches, counters per field.

5.5 Sorted Set (Zset)

Unique members each associated with a floating‑point score, ordered by score. Implemented with a hash table for O(1) member lookup and a skiplist for O(log N) range queries.

Key commands: ZADD , ZINCRBY , ZREM , ZRANGE , ZREVRANGE , ZRANGEBYSCORE , ZREVRANK , ZSCAN . Small Zsets use ziplist; larger ones use the full hash‑plus‑skiplist structure.

Typical use case: real‑time leaderboards (e.g., game player scores), where you need top‑N queries, rank lookup, score updates, and range scans.

6. Special Redis Structures (Brief)

6.1 Geospatial Index

Stores longitude/latitude pairs and provides radius queries.

6.2 HyperLogLog

Probabilistic cardinality estimator using ~12 KB constant memory.

6.3 Bitmap

Bit‑level storage for massive boolean flags (e.g., daily active users).

Typical enterprise combination: MySQL + Redis