Step 4: Distributed Database Sharding

Distributed Database Sharding

A powerful capability of xSQL is its ability to manage a single in-memory or persistent database distributed across a cluster of network nodes. To demonstrate this, we will use the configuration files (more about configuration files in step 5) found in the SDK directory samples/xsql/configs/shards to launch xSQL in three separate command console windows. This example demonstrates a simple distributed in-memory database working with 2 shards managed by xSQL servers; each shard holds only part of the database.

To start the servers, open 3 console windows, navigate to samples/xsql/configs/shards and in console 1 type:

 
    On Unix-Linux:
    ../../../../target/bin/xsql -c shard1.cfg –i
     
    On Windows:
    ..\..\..\..\target\bin\xsql -c shard1.cfg –i
     

In console 2 type:

 
    On Unix-Linux:
    ../../../../target/bin/xsql -c shard2.cfg -i
     
    On Windows:
    ..\..\..\..\target\bin\xsql -c shard2.cfg –i
     

Then start an xSQL client in one more console window(s) by typing:

 
    On Unix-Linux:
    ../../../../target/bin/xsql -c client.cfg -i
     
    On Windows:
    ..\..\..\..\target\bin\xsql -c client.cfg –i
     

Now execute the following 3 queries in the xSQL client (console 3):

 
    XSQL>1:select * from Employee;
    name    dept_no
    -------------------------------
    Han Solo        1
    Luke Skywalker  1
     
    Selected records: 2
     
    XSQL>2:select * from Employee;
    name    dept_no
    -------------------------------
    Darth Vader     2
     
    Selected records: 1
 
    XSQL>select * from Employee;
    name    dept_no
    -------------------------------
    Han Solo        1
    Luke Skywalker  1
    Darth Vader     2
     
    Selected records: 3
     

Note that the leading “1:” tells xSQL to access the shard in server 1, and likewise “2:” accesses the shard on server 2. Executing a select without specifying a server number causes xSQL to aggregate the results from the select on each server - the shards contain only parts of the database.

Clearly the configurations files, shard1.cfg, shard2.cfg and client.cfg are performing some hidden operations here. We will explain and demonstrate more about config files in the next step.