How X‑Stor Achieves Multi‑Model, Multi‑Tenant Cloud‑Native NoSQL Performance

1. X‑Stor Overview

X‑Stor is a cloud‑native, multi‑model NoSQL storage system developed by Tencent to address diverse data model, cost, and performance requirements across internal services such as QQ/Qzone, WeChat C2C, WeChat Pay, advertising features, and monitoring, as well as external sensor data workloads for major automotive customers.

It provides a unified storage foundation that offers strong, eventual, and bounded consistency options, supports layered storage media (memory, SSD, COS), and delivers multi‑AZ, cross‑region replication, continuous backup, and second‑level recovery capabilities.

2. Paper Background

NoSQL databases trade relational features for flexibility, high performance, scalability, and varied consistency models. Common NoSQL modalities include key‑value, document, wide‑column, graph, and time‑series, each suited to specific business scenarios (e.g., social graphs, low‑latency key‑value caches, time‑series monitoring).

Operating separate NoSQL systems for each modality leads to three major problems:

Developing and integrating a new NoSQL with a novel data model is complex and results in duplicated effort.

Maintaining multiple systems increases operational complexity and requires staff to understand heterogeneous interfaces.

Deploying independent clusters wastes physical resources.

X‑Stor was created to solve these issues by providing a single platform that natively supports multiple models and multi‑tenant workloads.

3. System Architecture

The standard X‑Stor cluster consists of a control plane and one or more data planes. The control plane centrally manages resource allocation, scheduling, elastic scaling, and health inspection for all data‑plane instances. Each data plane serves a specific data model, allowing independent scaling while sharing the same management interface.

The architecture follows a share‑nothing storage layer and leverages containerized deployment on Tencent Kubernetes Engine (TKE) for elasticity and high availability.

To reduce deployment cost, X‑Stor mixes services on the same physical nodes: stateless gateway services share idle CPU/memory, and different storage‑engine pods (in‑memory, LSM‑tree, time‑series) can co‑locate on the same node.

4. Multi‑Model Design

Existing multi‑model databases (e.g., MongoDB, Redis with modules, ArangoDB) typically extend a single storage engine, which limits extensibility and may degrade performance for added models.

X‑Stor adopts a plugin‑based approach: the core provides a unified API and data structures, while each data model is backed by a lightweight, purpose‑built storage engine plugin. Common services such as WAL and replication run as separate components, enabling independent optimization of each engine.

5. Multi‑Tenant Support

X‑Stor implements process‑level multi‑tenant isolation, meaning multiple tenants share a single DBMS process and its resources. This raises two challenges:

Traditional Kubernetes or cgroup isolation mechanisms are ineffective inside the shared process.

Requests from different tenants exhibit heterogeneous bottlenecks (CPU, memory, I/O, network), making simple QPS‑based throttling inaccurate.

To address these, X‑Stor introduces a standardized metric called Request Unit (RU) that quantifies a request’s consumption of CPU, memory, disk IOPS, and network bandwidth. RU is hardware‑agnostic, pre‑computed in lookup tables, and can be used for fine‑grained resource isolation, serverless‑style billing, and scheduling decisions.

All traffic‑control, replica placement, and load‑balancing components in X‑Stor consider RU values when making decisions.

6. Experimental Evaluation

Performance tests cover three X‑Stor storage‑engine plugins: an LSM‑tree engine, an in‑memory engine, and a time‑series engine. Benchmarks used include db_bench, YCSB, and TSBS, with comparisons against LevelDB, Redis, and InfluxDB respectively.

Results show X‑Stor consistently outperforms the single‑model counterparts across latency and throughput metrics.

RU‑based multi‑tenant isolation experiments demonstrate that, under increasing intra‑pod resource contention, tenants experience significantly lower latency when RU isolation is enabled compared to a naïve shared‑resource scenario.

Live cluster observations of RU‑driven load balancing show that after triggering migrations, overloaded pods are relieved, overall cluster load variance drops, and average request latency improves.