Understanding Horizontal Sharding in DBLE: Configuration Files Overview

In the previous episode we demonstrated DBLE's installation directory structure; this article introduces its basic functionality.

DBLE's core feature is horizontal data partitioning, which is essential when a single table grows beyond hundreds of millions of rows, causing performance issues for queries and modifications.

The sharding process uses a routing algorithm f to map a sharding key to different databases and tables, reducing the row count per table and enabling scalable expansion through algorithmic control.

The configuration is defined in three XML files.

1. rule.xml defines sharding rules, containing table rule and function sections. Each table rule links a column to a sharding algorithm (e.g., modulus on id ), while functions specify the algorithm details such as name and modulus base.

2. schema.xml describes schemas and tables. Each table references a rule and a datanode . The datanode points to a datahost , which maps to actual database instances. This three‑layer hierarchy (schema → datanode → datahost) establishes the relationship between logical tables and physical databases.

3. server.xml contains system parameters and optional features such as compression, slow‑query logging, XA transaction support, firewall settings, and user definitions. Manager users cannot configure schemas, while normal users can, with passwords stored as encrypted strings and optional read‑only flags.

In summary, rule.xml defines the sharding algorithm, schema.xml links tables to datanodes and datahosts, and server.xml sets DBLE's core parameters and user information. DBLE inherits from Mycat, and while the current XML organization has some inconsistencies for compatibility, future revisions may restructure it for better clarity.

That concludes this part of the DBLE quick‑start series.