How DongSQL Solves E‑Commerce DB Overload, Flash‑Sale, and Plan Drift

DongSQL Overview

DongSQL is JD’s self‑developed, cloud‑native relational database kernel designed for e‑commerce workloads. It adopts a shared‑storage, compute‑separated architecture (the “Coral” database) to lower cost and improve scalability while maintaining compatibility with the existing JED database stack.

Problem 1: Overload During Traffic Spikes

Large promotions generate sudden traffic bursts and repeated timeout‑SQL retries, which can saturate CPU, memory, I/O and lock resources, causing the database to become unresponsive. Business‑side rate limiting is coarse‑grained and often mis‑targets queries.

Solution: SQL‑hint based precise throttling (Hint‑limit)

The kernel can inspect SQL fingerprints and apply throttling directly at the execution layer, allowing administrators to limit specific statements or groups of statements without affecting other traffic.

// Limit based on a specific SQL fingerprint (parallelism can be supplied)
update/*+ ccl_queue_digest(INT<parallelism>) */ t set col1 = col1+1 where 1=id;

// General limit without specifying parallelism
update/*+ ccl_queue_digest() */ t set col1 = col1+1 where 1=id;

Problem 2: Flash‑Sale High‑Frequency Writes

Flash‑sale scenarios produce massive single‑row updates, leading to row‑level lock contention, dead‑lock detection overhead, and ACID‑related performance penalties. Naïve update‑then‑select patterns also risk overselling.

Solution: Customized hint mechanisms for flash‑sale workloads

Hints can queue or throttle updates that target hot values or hot fields, reducing lock contention. An additional hint enables fast commit/rollback for single‑row transactions, delivering >3× performance improvement.

// Limit based on a hot value (e.g., a specific product)
update/*+ ccl_queue_value('baijiu') */ t set c=c+1 where name='baijiu';

// Limit based on a hot field (e.g., order_id)
update/*+ ccl_queue_field(order_id) */ t set c=c+1 where order_id=1 and name='baijiu';

Problem 3: Cache‑Database Consistency

When a distributed cache (e.g., JIMDB) is invalidated, the application must read the updated row and immediately refresh the cache. Under read‑committed isolation, concurrent transactions may still see stale data.

Solution: Implement the RETURNING clause

An UPDATE … RETURNING * statement atomically returns the modified row, eliminating the extra SELECT and guaranteeing that the application receives the latest data.

UPDATE inventory SET stock = stock-1 WHERE id=100 RETURNING *;

Problem 4: Execution‑Plan Drift

During peak periods, optimizer statistics may change, causing a previously fast query to switch from an index‑scan to a full‑table‑scan, dramatically increasing latency.

Solution: Statement Outline to lock proven execution plans

Outlines are stored‑procedure calls that capture a stable plan (including optimizer hints) and force the engine to reuse it, regardless of later statistic changes.

-- Add an optimizer‑hint outline
CALL dbms_outln.add_optimizer_outline(
    'your_db',
    '',
    1,
    '/*+ USE_INDEX(orders idx_create_time) */',
    'SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id '
    'WHERE o.create_time BETWEEN ''2025-10-01'' AND ''2025-10-30'' '
    'AND o.status IN (''PAID'',''SHIPPED'') ORDER BY o.create_time DESC LIMIT 100;');

-- Add a forced‑index outline
CALL dbms_outln.add_index_outline(
    'your_db',
    '',
    1,
    'USE INDEX',
    'idx_status',
    '',
    'SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id '
    'WHERE o.create_time BETWEEN ''2025-10-01'' AND ''2025-10-30'' '
    'AND o.status IN (''PAID'',''SHIPPED'') ORDER BY o.create_time DESC LIMIT 100;');

Problem 5: Thread Congestion (One‑Thread‑Per‑Connection)

Traditional databases spawn a dedicated thread per client connection. Under massive concurrent connections during promotions, thread creation, context‑switch overhead, and lack of prioritization become bottlenecks.

Solution: Integrated thread‑pool

DongSQL incorporates a thread‑pool that reuses a fixed set of worker threads. New connections are assigned to idle workers, reducing thread‑creation cost, lowering context‑switch frequency, and allowing priority handling for critical traffic.