Distributed database is based on sharding JDBC sub database and sub table

1, Introduction

shardingsphere is a product of Apache, mainly including Sharding JDBC and Sharding Proxy. The former can be regarded as an enhanced version of JDBC, and the latter is an independent proxy system without coupling in the code. In this regard, it is very similar to Mycat

2, What did ShardingJDBC do for me?

When using Sharding JDBC, we need to configure rules in the configuration file. This rule is used to tell it how to parse an SQL we send, such as the following figure, logical table ksd_order does not exist at all. It will judge the data source and the table of the corresponding data source according to the configured rules, and finally send the SQL conversion to the corresponding data source for execution.

How does distributed Sharding JDBC ensure distributed transaction management?

1. Local non cross database

In this case, local transactions can be used, for example, the @ Transactional annotation can be used directly

2. Distributed cross database

In this case, there is good support for two-phase XA transactions. Dependency is introduced and implemented with the annotation @ ShardingTransactionType

Rigid - XA transactions

XA transaction provides an implementation mechanism based on two-phase commit protocol. The so-called two-stage submission, as the name suggests, is divided into two stages, one is the preparation stage and the other is the implementation stage. In the preparation phase, the coordinator initiates a proposal and asks each participant whether they accept it. In the execution phase, the coordinator commits or terminates the transaction according to the feedback of the participants. If all participants agree, submit, and terminate as long as one participant disagrees.

At present, there are also some mainstream tool libraries in the industry when implementing XA transactions, including Atomikos, Narayana and Bitronix. ShardingSphere integrates these three tool libraries and uses Atomikos by default to complete the two-phase submission.

Flexible - use BASE transactions

Compared with XA transactions, the process of integrating BASE transactions in business code is relatively complex, because we need to do this with the help of an external framework. Here, we will demonstrate how to use BASE transactions based on the Seata framework provided by Alibaba.

The only thing to do when switching from XA transaction to BASE transaction is to reset the TransactionType, that is, modify a line of code:

	@Override
	public void processWithBASE() throws SQLException {
		TransactionTypeHolder.set(TransactionType.BASE);
		 
		insertHealthRecords();
	}

Configuration item of Sharding JDBC data fragmentation

dataSources: # Omit the data source configuration, please refer to the user manual

rules:
- !SHARDING
  tables: # Data fragmentation rule configuration
    <logic-table-name> (+): # Logical table name
      actualDataNodes (?): # It consists of data source name + table name (refer to Inline syntax rules)
      databaseStrategy (?): # Sub database policy: default indicates that the default sub database policy is used. Only one of the following sub database policies can be selected
        standard: # Standard slicing scenario for single slicing key
          shardingColumn: # Partition column name
          shardingAlgorithmName: # Partition algorithm name
        complex: # Composite sharding scene for multi sharding key
          shardingColumns: #Fragmented column names, multiple columns separated by commas
          shardingAlgorithmName: # Partition algorithm name
        hint: # Hint fragmentation strategy
          shardingAlgorithmName: # Partition algorithm name
        none: # Undivided
      tableStrategy: # Sub table strategy is the same as sub database strategy
      keyGenerateStrategy: # Distributed sequence strategy
        column: # Auto increment column name. By default, auto increment primary key generator is not used
        keyGeneratorName: # Name of distributed sequence algorithm
  autoTables: # Automatic partition table rule configuration
    t_order_auto: # Logical table name
      actualDataSources (?): # Data source name
      shardingStrategy: # Segmentation strategy
        standard: # Standard slicing scenario for single slicing key
          shardingColumn: # Partition column name
          shardingAlgorithmName: # Name of automatic slicing algorithm
  bindingTables (+): # Binding table rule list
    - <logic_table_name_1, logic_table_name_2, ...> 
    - <logic_table_name_1, logic_table_name_2, ...> 
  broadcastTables (+): # Broadcast table rule list
    - <table-name>
    - <table-name>
  defaultDatabaseStrategy: # Default database fragmentation policy
  defaultTableStrategy: # Default table fragmentation policy
  defaultKeyGenerateStrategy: # Default distributed sequence policy
  defaultShardingColumn: # Default tile column name
  
  # Partition algorithm configuration
  shardingAlgorithms:
    <sharding-algorithm-name> (+): # Partition algorithm name
      type: # Partition algorithm type
      props: # Partition algorithm attribute configuration
      # ...
  
  # Distributed sequence algorithm configuration
  keyGenerators:
    <key-generate-algorithm-name> (+): # Name of distributed sequence algorithm
      type: # Distributed sequence algorithm type
      props: # Attribute configuration of distributed sequence algorithm
      # ...

props:
  # ...

Keywords: Database Distribution distributed system

Added by richardandrewle on Tue, 26 Oct 2021 15:26:47 +0300