From NoSQL to SQL: Tracing Database Evolution and Alibaba’s DRDS Strategy

Preface

The speaker, a senior Alibaba technical expert, introduces the topic "NoSQL to SQL" inspired by a striking diagram that humorously depicts the evolution of database storage.

He outlines the agenda covering milestones from 1970 to 2013 and Alibaba’s technology choices.

1970: We have no SQL

Early data handling relied on static structures like classes. When requirements grew, developers needed dynamic collections, leading to the use of maps (e.g., map.put("轮子", 轮子对象);). Persisting these structures efficiently required B‑tree storage, which reduces random disk seeks by storing data in array‑like pages.

Hierarchical databases model data as nested maps, a concept illustrated with a car example.

1980: Know SQL

Relational databases emerged after IBM’s System R, offering a mathematically grounded model. An example query to find left‑wheel suppliers demonstrates the simplicity of SQL compared to hierarchical code.

Traverse each car, locate the left wheel, check its supplier, keep or discard. SQL equivalent: select * from 轮子表 where 轮子位置='左' and 轮子供应商='DRDS';

The relational engine parses SQL into an AST, optimizes using index statistics, and generates execution plans that ultimately operate on KV stores (hash or ordered trees).

2000: No SQL!

With the rise of distributed systems, NoSQL databases like Cassandra and HBase appeared, promising scalability without strict ACID guarantees. However, early adopters faced operational challenges, and many projects reverted to relational models.

2005: Not only SQL

Attempts to blend NoSQL flexibility with relational features led to hybrid solutions (e.g., CQL for Cassandra, SQL layers for HBase). Yet, no single model could fully replace SQL, and the community recognized the need for coexistence.

2013: No,SQL!

The industry converged on NewSQL: systems that retain SQL’s expressiveness while providing horizontal scalability. Alibaba’s DRDS is presented as a NewSQL product that combines the convenience of relational queries with distributed performance.

Alibaba’s Technical Choice

Alibaba adopts DRDS/TDDL for its broad compatibility and minimal behavioral changes. The system handles massive traffic spikes (e.g., Double 11) by scaling out before peak periods and scaling in afterward, demonstrating its core strength in elastic capacity.

Q&A

Q1: What is ADS and its relation to DRDS?

ADS focuses on ad‑hoc queries without transactions; DRDS supports transactions. They complement each other—ADS for offline workloads, DRDS for online.

Q2: How does DRDS implement JOINs?

Typical join algorithms are hash, index‑nested‑loop, and sort‑merge; no magic involved.

Q3: Thoughts on schema‑less / free databases?

They offer flexibility but increase storage overhead and technical debt; JSON support in MySQL/PostgreSQL mitigates some issues.

Q4: Why avoid MongoDB?

Performance is comparable to SQL when properly configured; many failures stem from misconfiguration.

Q5: Can relational databases handle massive, low‑latency, high‑concurrency workloads?

DRDS is recommended for such scenarios.

Q6: Should unstructured data be stored in NoSQL?

Unstructured data exists regardless; NoSQL marketing often overstates its suitability.

Q7: Relationship between DRDS and RDS?

DRDS emphasizes distribution; RDS emphasizes single‑node simplicity.

Q8: Any better data models than SQL?

So far, no model has surpassed SQL’s practicality; past attempts (object databases) did not gain wide adoption.

Q9: Can new network architectures solve distributed DB latency?

They can improve latency but cannot eliminate the fundamental trade‑offs without deeper theoretical breakthroughs.

Q10: One‑sentence summary of DRDS?

Best scalability among SQL databases and most convenient among NoSQL databases.

Q11: Relationship between WebScaleSQL and DRDS?

They are competitors.

Q12: How does DRDS compare with NewSQL?

DRDS is a NewSQL solution.