ライブラリ分割テーブルを軽量化する方法--Sharding Sphere

前回の記事では、マルチデータ・ソースと動的データ・ソースの使用上の注意点を簡単に紹介しました.本稿では、実際のビジネス・オペレーションでよく遭遇するシーンであるライブラリ・テーブルについて説明します.現在、ソフトウェアシステムの機能が豊富になるにつれて、膨大なユーザーグループとユーザーがもたらす様々な大量のデータはデータベースに大きな圧力を加えています.簡単な例を挙げると、多くのCエンド製品のユーザー受注数は、システムの稼働時間が経つにつれて幾何学的に増加します.これにより、特定の条件に従って受注を検索する場合、クエリーの効率は低下するに違いありません.高周波検索フィールドにインデックスを作成すると、この現象をある程度緩和することができるかもしれません.しかし、この問題を本質的に解決することはできず、インデックスの作成に伴う時間コストとストレージコストも「安価」ではありません.このような問題を解決するための技術案である分庫分表が誕生しなければならないが、実際には市場には多様なミドルウェアが選択できるようになっている.有名なミドルウェアには、MyCat、Cobar、MySQL Routerなどがあります.これらのミドルウェアは、対応する公式サイトやコミュニティで詳細を見ることができます.今日特に紹介するのは、他のいくつかのアイテムに比べてプロジェクトの侵入性が低く、導入が簡単であるという明らかな利点を持つ軽量レベルのテーブル・ライブラリ・ツールです.著者らは,すでに成熟したシステム上でライブラリ分割テーブルの改造を行うため,プロジェクトの侵入性が低いことが私が選択した重要な要素である.結局、1つのツールを使用するために従来の大量のコードを再構築することは、簡単ではなく、損をしないことです.Sharding‐JDBCのフレームワーク体系を上図のように簡単明瞭に示したが,実際には増強JDBC駆動として簡単に理解できる.これは、さまざまな既存のORMフレームワーク(例えば、Mybatis、Hibernateなど)と完全に互換性があり、任意のサードパーティのデータベース接続プール(例えばDBPP、C 3 P 0、BoneCP、Druid、HikariCPなど)をサポートし、JDBC仕様を実装する任意のデータベース(例えば、MySQL、Oracle、SQLServer、PostgreSQLなど)をサポートします.だから、既存のプロジェクトを改造しても、新しいプロジェクトを構築してもいい選択です.使い方を簡単にご紹介しましょう.
データソースの構成

    @Bean(name = "crmDataSource")
    @Primary
    public DataSource datasource() throws SQLException {
        //        
        ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();
        shardingRuleConfig.getTableRuleConfigs().add(orderTableRuleConfiguration());
        shardingRuleConfig.getTableRuleConfigs().add(orderItemTableRuleConfiguration());
        shardingRuleConfig.getBindingTableGroups().add("t_order, t_order_item");
        //                         
        shardingRuleConfig.setDefaultDatabaseShardingStrategyConfig(new InlineShardingStrategyConfiguration("user_id", "ds${user_id % 2}"));
        //                  
        shardingRuleConfig.setDefaultTableShardingStrategyConfig(new StandardShardingStrategyConfiguration("order_id", new TableShardingAlgorithm());
        return ShardingDataSourceFactory.createDataSource(createDataSourceMap(), shardingRuleConfig);
    }
    //     
    TableRuleConfiguration orderRuleConfiguration() {
         TableRuleConfiguration result = new TableRuleConfiguration();
         result.setLogicTable("t_order");
         result.setActualDataNodes("ds${0..1}.t_order${0..4}");
         result.setKeyGeneratorColumnName("order_id");
         return result;
     }
     
     //      
     TableRuleConfiguration orderItemRuleConfiguration() {
         TableRuleConfiguration result = new TableRuleConfiguration();
         result.setLogicTable("t_order_item");
         result.setActualDataNodes("ds${0..1}.t_order_item${0..4}");
         return result;
     }
     //       
     Map createDataSourceMap() {
        //  atomikos         
        //      
        MysqlXADataSource mysqlXADataSource=new MysqlXADataSource();
        mysqlXADataSource.setUrl(db0Url);
        mysqlXADataSource.setPassword(password);
        mysqlXADataSource.setUser(userName);
        mysqlXADataSource.setPinGlobalTxToPhysicalConnection(true);
        AtomikosDataSourceBean dataSource=new AtomikosDataSourceBean();
        dataSource.setXaDataSource(mysqlXADataSource);
        dataSource.setUniqueResourceName("ds0");
        dataSource.setMaxPoolSize(30);
        dataSource.setMinPoolSize(5);
        ...
        // n    ,       
        //            
        Map dataSourceMap = new HashMap<>();
        dataSourceMap.put("ds0",dataSource1);
        dataSourceMap.put("ds1",dataSource2);
        ...
        return datasourceMap;
     }
    

前の記事で紹介した分散トランザクションを覚えていますか.ここでは、データテーブルのライブラリ操作を行っています.したがって、効率的なトランザクション管理を行うには、XADataSourceを使用してデータ・ソースの初期化が必要です.ライブラリ分割操作ではデータベースのルーティングとデータテーブルのルーティングに分けられ,それぞれ明確な指定が必要である(ここで専門用語はデータ分割ルールの制定と呼ぶ).上の図に示すように、JDBCは、データベース接続を開いて操作するときに、どのデータベースのどのテーブルを操作するかを決定します.私たちがしなければならないのはこのルールを制定して、それから残りのことは安心してSharding-JDBCに任せて完成することができます.例えば、注文書t_orderは10個のサブテーブルに分割され、その後、この10個のサブテーブルをds 0とds 1の2つのデータベースに均一に分散する.注文書にはすべて所属するユーザーがいます.もし私たちが所属するユーザー番号をモデル化し、残数に基づいて対応するデータベースにマッピングし、注文書番号に基づいてモデル化した後、データを対応するデータテーブルにマッピングします.このような2つのフィルタリングを経て、最も簡単で効率的なデータスライス規則です.上記のコードは、このルールに従って処理されています.本来、百万級の受注処理を十万級の受注処理に格下げすることができ、最終的なデータベース操作で効率を大幅に向上させることができます.
表分割ポリシーの構成

public class TableShardingAlgorithm implements PreciseShardingAlgorithm {

	@Override
	public String doSharding(Collection tableNames, PreciseShardingValue shardingValue) {
		//               
		for (String each : tableNames) {
			if (each.endsWith(shardingValue.getValue() % 5 + "")) {
				return each;
			}
		}
		//        
		return shardingValue.getLogicTableName();
	}

}

データベースには存在しませんt_orderという論理テーブルは、私たちが本当に作成したのはds 0です.t_order0-4,ds1.t_order 0-4この10枚の表は、

//                 0，       1
new InlineShardingStrategyConfiguration("user_id", "ds${user_id % 2}")
//                          
setActualDataNodes("ds${0..1}.t_order${0..4}");

これにより、データベースが操作を実行するときに、JDBCの論理テーブルが実際のテーブルのオプション範囲に置き換えられたことを通知し、エラーが発生しない合理的な限界内で操作が保証されます.置換可能なテーブルが見つからない場合は、テーブル名を直接返します.これにより、1つのデータベースにテーブルを分割する必要がある部分と、テーブルを分割する必要がない部分があれば、互換性が得られます.構成は簡単ではありませんが、これは本当にタイトルの軽量化の要求に合っています.Mycatなどの重量級のデータベースミドルウェアを必要としません.また、専門的なミドルウェアサーバを必要としません.対応する依存性をMavenでjarパッケージで導入するだけで簡単にライブラリ分割テーブルを開くことができ、SpringBootプロジェクトにもサポートされています.実際、Sharding Sphereは、ライブラリ・テーブルの機能だけでなく、読み書き分離、データ・ガバナンス、フレキシブル・トランザクションなど、多様なデータ・サービスも提供しています(詳細は非同期公式サイトで確認できます:shardingsphere.io).本文はただ入門の性質の紹介のその一部の機能だけで、残りのもっと豊富な特性は読者が自分で勉強することを待って、あなたの読書に感謝します!
転載先:https://juejin.im/post/5b8140cde51d4538b57a8d5d