What Is NewSQL? Exploring TiDB’s Distributed Database Features

What Is NewSQL?

NewSQL combines the scalability of NoSQL with the strong ACID guarantees of traditional relational databases, supporting complex queries and high‑availability distributed architectures.

Traditional SQL Limitations

As internet services grew, single‑node relational databases hit performance ceilings. Scaling by upgrading hardware has limits; data sharding introduces complexity, especially for cross‑shard joins and transactions.

NoSQL Advantages and Drawbacks

High availability and horizontal scalability.

Relaxed consistency for better performance.

Flexible data models without relational constraints.

Missing strong consistency, limited SQL support, and lack of transactions for many use cases.

Key Features of NewSQL

SQL support with complex queries and analytics.

Full ACID transactions and isolation levels.

Elastic horizontal scaling transparent to applications.

Automatic fault‑tolerance and high availability.

TiDB – A NewSQL Distributed Database

TiDB, developed by PingCAP, is an open‑source HTAP database compatible with MySQL 5.7 protocol. It provides horizontal elastic expansion, Raft‑based strong consistency, real‑time HTAP via TiKV (row store) and TiFlash (column store), and deep integration with Kubernetes for cloud‑native deployments.

Architecture

The cluster consists of three core components:

TiDB Server – stateless SQL layer that parses queries and communicates with storage.

PD (Placement Driver) – metadata service handling region placement, load balancing, and global transaction IDs.

TiKV Server – distributed transactional key‑value store that manages data in regions replicated via Raft.

TiSpark enables large‑scale OLAP processing on TiKV data, while TiFlash provides columnar storage for analytical workloads.

High‑Availability Design

TiDB, PD, and TiKV all use Raft consensus to tolerate node failures. Deploying multiple instances of each component ensures automatic leader election and data replication without service interruption.

Application Scenarios

Replacing MySQL for seamless migration with minimal code changes.

Scaling out MySQL sharding and merging via TiDB’s distributed layer.

Serving as a data warehouse for HTAP workloads, supporting TPC‑H style queries.

Acting as a storage engine for other systems, e.g., as a replacement for HBase or Redis.

Compatibility and Limitations

TiDB supports most MySQL 5.7 syntax and tools, but it does not implement stored procedures, triggers, events, foreign keys, temporary tables, full‑text indexes, and several other MySQL‑specific features.

Configuration Differences

Default character set is utf8mb4 with collation utf8mb4_bin.

Case‑sensitivity follows lower_case_table_names=2.

Timestamp columns auto‑update by default ( explicit_defaults_for_timestamp=ON).

Foreign‑key enforcement is disabled ( foreign_key_checks=OFF).

NewSQL vs. Traditional SQL vs. NoSQL

SQL

NoSQL

Real‑time

High‑real‑time requirements, write‑focused.

Lower real‑time needs, often batch‑updated.

Data volume

Typically tens to hundreds of MB‑GB.

Hundreds of GB to TB for analytical workloads.

Design focus

Entity‑relationship, application‑oriented.

Star or snowflake schema, topic‑oriented.

TiDB Core Features

Horizontal elastic scaling.

100% ACID transaction support.

Financial‑grade high availability via Raft.

Real‑time HTAP with TiKV and TiFlash.

Cloud‑native deployment on Kubernetes.

Full MySQL 5.7 protocol compatibility.

TiDB Components

TiDB Server – receives SQL, stateless, horizontally scalable.

PD Server – stores metadata, schedules regions, provides global transaction IDs.

TiKV Server – stores data in regions, uses Raft for replication.

TiFlash – columnar storage for analytical queries.

TiSpark – Spark plugin for large‑scale OLAP on TiKV.

Source: cnblogs.com/jiagooushi/archive/2023/03/24/17251486.html