このプロジェクトは何をしますか
ShardingSphere-Proxy により、ユーザーは Apache ShardingSphere をネイティブ データベースのように使用できます。
テクノロジーの理解は、一般的に公式 Web サイトから始まります。ShardingSphere-Proxy の公式 Web サイトの定義を見てみましょう。
透過的なデータベース エージェントとして位置付けられ、異種言語をサポートするためにデータベース バイナリ プロトコルをカプセル化するサーバー バージョンを提供します。現在、MySQL と PostgreSQL のバージョンを提供しています (openGauss およびその他の PostgreSQL ベースのデータベースと互換性があります)。MySQL/PostgreSQL プロトコルと互換性のあるアクセス クライアント (MySQL コマンド クライアント、MySQL ワークベンチ、Navicat など) を使用してこれにより、DBA にとってより使いやすくなります。
まず概念を明確にすると、ShardingSphere-Proxy はサービスプロセスです。クライアント プログラム接続の観点からは、MySQL データベースと同じです。
プロキシを使用する理由
サブデータベースのサブテーブルやその他のルールの場合、データは複数のデータベース インスタンスに分散されるため、必然的に管理に不便が生じるか、非 Java 言語を使用する開発者は ShardingSphere が提供する機能を必要とします。 .. 上記の状況は、まさに ShardingSphere-Proxy ができることです。
1. プロキシ アプリケーションのシナリオ
日常業務では、ShardingSphere-JDBC を使用してデータベースとテーブルを分割するシナリオが数多くあります。ハッシュ形式のユーザー ID によってデータベースに水平に分割されたユーザー テーブルがあると仮定すると、クライアントがデータベースに接続する方法は次のようになります。
私たちの仕事に実際に存在するいくつかのシナリオの例を挙げましょう。
- テストの学生は、データベース テーブルでユーザー ID 123456 の情報を確認したいと考えており、ユーザーがどのサブテーブルにいるかを指定する必要があります。
- 企業のリーダーは、2022 年にユーザーの成長とユーザー情報を総合的に提供するテクノロジーを必要としています。
- 同社は 8 周年記念イベントを開催しており、登録日が 8 周年を超えるアクティブ オールド ユーザーのリストを提供する技術が必要です。
データがデータベースとテーブルに分割された後、データはさまざまなデータベース テーブルに分散され、上記のシナリオを実現するのは容易ではないため、同様の一時的な要件を達成するために、毎回コードを開発する必要がある場合、少し面倒そうです。このとき、記事の主人公である ShardingSphere-Proxy が登場する必要があります。
ShardingSphere-Proxy は実際のバックエンド データベースを隠します. クライアントの場合, それはデータベースを使用しており, ShardingSphere がその背後にあるデータベースをどのように調整するかを気にする必要はありません. Java 以外の言語を使用する開発者や DBA にとってより使いやすいです.
たとえば、t_user はデータベース レベルでいくつかの実テーブルに分割されます。ShardingSphere -Proxy を操作するプロセスでは、クライアントは t_user 論理テーブルがあることだけを認識し、実テーブルへのルーティング プロセスは ShardingSphere 内で実行されますt_user_0
。t_user_9
-プロキシー。
- 論理テーブル: 同じ構造を持つ水平分割データベース (テーブル) の論理名であり、SQL でのテーブルの論理識別子です。例: ユーザー データは、主キーの末尾 ( to ) とその論理テーブル名
t_user_0
に従って10 個のテーブルに分割されます。t_user_9
t_user
- 実表: 水平分割データベースに実際に存在する物理表。つまり、前の例で
t_user_0
はt_user_9
.
2. JDBC とプロキシの違い
上記の説明を読んだ後、ShardingSphere-Proxy と ShardingSphere-JDBC が非常に似ているとどのように感じますか?それらの違いは何ですか?
ShardingSphere-JDBC | ShardingSphere-プロキシ | |
---|---|---|
データベース | 恣意的に | MySQL / PostgreSQL プロトコルに基づくデータベース |
接続消費 | 高い | 低い |
異種言語 | Java およびその他の JVM ベースの言語をサポート | 恣意的に |
パフォーマンス | 低損失 | わずかに高い損失 |
分散型 | はい | いいえ |
静的エントリ | なし | もつ |
両者の違いを簡単にまとめると次のようになります。
- ShardingSphere-JDBC は Jar パッケージです. 最下層は、JDBC コンポーネントを書き換えることによって、SQL の解析、ルーティング、書き換え、実行、およびその他のプロセスを完了します. 対応する機能の構成ファイルをプロジェクトに追加する必要があり、アプリケーションに侵入します.
- ShardingSphere-Proxy はプロセスサービスであり、ほとんどの場合、開発と運用を支援する効率化ツールとして位置付けられます。それ自体をデータベースに偽装し、アプリケーションがドッキングされた後、コードは非侵襲的です; SQL の実行ロジックは ShardingSphere-JDBC と一致しており、2 つは同じカーネルを再利用します。
ShardingSphere-Proxy にはアプリケーションへの侵入がなく、2 つが同じカーネルを再利用しているのに、なぜ ShardingSphere-JDBC をまだ使用しているのですか?
- アプリケーションは ShardingSphere-JDBC を介してデータベースを直接操作しますが、これは 1 つのネットワーク IO に相当しますが、アプリケーションが ShardingSphere-Proxy に接続している間は 1 つのネットワーク IO であり、ShardingSphere-Proxy が再びデータベースを操作すると、別のネットワーク IO が発生します。
- アプリケーション呼び出しリンクには余分なレイヤーがあり、トラフィックのボトルネックを形成しやすく、アプリケーションへの潜在的なリスクを増大させます; 一般的に言えば、アプリケーション プログラムは ShardingSphere-JDBC で使用されます。
もちろん、ShardingSphere-JDBC と ShardingSphere-Proxy を混在してデプロイすることもできます. ShardingSphere-JDBC は、Java で開発された高性能で軽量な OLTP アプリケーションに適しています. ShardingSphere-Proxy は、OLAP アプリケーションと、シャードされたデータベースを管理および維持するためのシナリオに適しています. . .
開始方法
ShardingSphere-Proxy を起動するには、バイナリパッケージ、Docker、Helm の 3 つの方法があり、スタンドアロン展開とクラスター展開に分けられます。この記事は、スタンドアロンのバイナリ パッケージとして開始されます。
- ダウンロードページからShardingSphere-Proxy バイナリ インストール パッケージを取得します。
- 解凍後、プレフィックスで始まるファイルを
conf/server.yaml
変更し、断片化や読み取りと書き込みの分離などのルールを構成します。config-
- Linux オペレーティング システムを実行してください
bin/start.sh
。Windows オペレーティング システムを実行してください ShardingSphere-Proxybin/start.bat
を開始します。
ダウンロードしたファイルのディレクトリは次のとおりです。
├── LICENSE
├── NOTICE
├── README.txt
├── bin # 启动停止脚本
├── conf # 服务配置,分库分表、读写分离、数据加密等功能的配置文件
├── lib # Jar 包
└── licenses
复制代码
1. MySQL JDBC ドライバーを ext-lib パッケージにコピーします。
ドライバmysql-connector-java-5.1.47.jarまたはmysql-connector-java-8.0.11.jarを ext-lib パッケージにダウンロードします。初期ディレクトリには ext-lib がないため、自分で作成する必要があります。
2. conf/server.yaml 構成ファイルを変更します
server.yaml 構成のデフォルトのクラスター操作モード。これはスタンドアロン操作構成です。
mode:
type: Standalone # 单机模式
repository:
type: File
props:
path: /Users/xxx/software/apache-shardingsphere-5.1.0-shardingsphere-proxy/file # 元数据配置等持久化文件路径
overwrite: false # 是否覆盖已存在的元数据
rules: # 认证信息
- !AUTHORITY
users: # 初始化用户
- root@%:root
- sharding@:sharding
provider:
type: ALL_PRIVILEGES_PERMITTED
- !TRANSACTION
defaultType: XA
providerType: Atomikos
- !SQL_PARSER
sqlCommentParseEnabled: true
sqlStatementCache:
initialCapacity: 2000
maximumSize: 65535
concurrencyLevel: 4
parseTreeCache:
initialCapacity: 128
maximumSize: 1024
concurrencyLevel: 4
props: # 公用配置
max-connections-size-per-query: 1
kernel-executor-size: 16 # Infinite by default.
proxy-frontend-flush-threshold: 128 # The default value is 128.
proxy-opentracing-enabled: false
proxy-hint-enabled: false
sql-show: false
check-table-metadata-enabled: false
show-process-list-enabled: false
# Proxy backend query fetch size. A larger value may increase the memory usage of ShardingSphere Proxy.
# The default value is -1, which means set the minimum value for different JDBC drivers.
proxy-backend-query-fetch-size: -1
check-duplicate-table-enabled: false
proxy-frontend-executor-size: 0 # Proxy frontend executor size. The default value is 0, which means let Netty decide.
# Available options of proxy backend executor suitable: OLAP(default), OLTP. The OLTP option may reduce time cost of writing packets to client, but it may increase the latency of SQL execution
# and block other clients if client connections are more than `proxy-frontend-executor-size`, especially executing slow SQL.
proxy-backend-executor-suitable: OLAP
proxy-frontend-max-connections: 0 # Less than or equal to 0 means no limitation.
sql-federation-enabled: false
# Available proxy backend driver type: JDBC (default), ExperimentalVertx
proxy-backend-driver-type: JDBC
复制代码
スタンドアロンの ShardingSphere-Proxy を起動する場合は、後で Proxy 構成を変更する必要があることに注意してください.ShardingSphere-Proxy が起動時にメタデータをリロードするように、mode.overwrite を true に設定することをお勧めします.
3.ShardingSphere-Proxyを起動
開始コマンドを実行します: sh bin/start.sh
. デフォルトの起動ポートは、3307
起動スクリプト コマンドにパラメータを追加することで置き換えることができます: sh bin/start.sh 3308
.
ShardingSphere-Proxy が正常に起動したかどうかを確認するには、次のコマンドを実行してログを確認しますtail -100f logs/stdout.log
。最後の行に次の情報が表示されれば、起動は成功です。
[INFO ] xxx-xx-xx xx:xx:xx.xxx [main] o.a.s.p.frontend.ShardingSphereProxy - ShardingSphere-Proxy Standalone mode started successfully
复制代码
シーン練習
この章は実際の戦闘シナリオの前提から始まり、ShardingSphere-Proxy を通じて上記の要件を満たします。
1. データベース テーブルの初期化
# CREATE DATABASE
CREATE DATABASE user_sharding_0;
CREATE DATABASE user_sharding_1;
# CREATE TABLE
use user_sharding_0;
CREATE TABLE `t_user_0` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
CREATE TABLE `t_user_1` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
use user_sharding_1;
CREATE TABLE `t_user_0` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
CREATE TABLE `t_user_1` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
复制代码
2. プロキシ シャード構成の初期化
schemaName: sharding_db
dataSources:
ds_0:
url: jdbc:mysql://127.0.0.1:3306/user_sharding_0?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
ds_1:
url: jdbc:mysql://127.0.0.1:3306/user_sharding_1?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
rules:
- !SHARDING
tables:
t_user:
actualDataNodes: ds_${0..1}.t_user_${0..1}
tableStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: t_user_inline
keyGenerateStrategy:
column: user_id
keyGeneratorName: snowflake
bindingTables:
- t_user
defaultDatabaseStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: database_inline
defaultTableStrategy:
none:
shardingAlgorithms:
database_inline:
type: INLINE
props:
algorithm-expression: ds_${user_id % 2}
t_user_inline:
type: INLINE
props:
algorithm-expression: t_user_${user_id % 2}
keyGenerators:
snowflake:
type: SNOWFLAKE
复制代码
3. 断片化試験
MySQL ターミナル コマンドを使用して、ShardingSphere-Proxy サーバーに接続します。データベースが Docker によってデプロイされている場合は、-h local ip を追加する必要があります。コンテナー内の 127.0.0.1 へのアクセスが使用できないためです。
# 将 {xx} 替换为实际参数
mysql -h {ip} -u {username} -p{password} -P 3307
# 示例命令
mysql -h 127.0.0.1 -u root -proot -P 3307
复制代码
ShardingSphere-Proxy は、Navicat MySQL、DataGrip、WorkBench、TablePlus およびその他のデータベース管理ツールの接続をサポートします。
接続が成功したら、構成ファイルと一致するプロキシ データベースにクエリを実行します。
mysql> show databases;
+-------------+
| schema_name |
+-------------+
| sharding_db |
+-------------+
1 row in set (0.02 sec)
复制代码
新しい t_user ステートメントを実行して、2021 年に作成された 3 個と 2022 年に作成された 3 個の 6 個のユーザー データを挿入します。
mysql> use sharding_db;
mysql> INSERT INTO t_user (id, user_id, create_date) values(1, 1, '2021-01-01 00:00:00'), (2, 2, '2021-01-01 00:00:00'), (3, 3, '2021-01-01 00:00:00'), (4, 4, '2022-01-01 00:00:00'), (5, 5, '2022-02-01 00:00:00'), (6, 6, '2022-03-01 00:00:00');
Query OK, 6 rows affected (0.16 sec)
mysql> select * from t_user;
+----+---------+---------------------+
| id | user_id | create_date |
+----+---------+---------------------+
| 2 | 2 | 2021-01-01 00:00:00 |
| 4 | 4 | 2022-01-01 00:00:00 |
| 6 | 6 | 2022-03-01 00:00:00 |
| 1 | 1 | 2021-01-01 00:00:00 |
| 3 | 3 | 2021-01-01 00:00:00 |
| 5 | 5 | 2022-02-01 00:00:00 |
+----+---------+---------------------+
复制代码
この時点で、データはuser_sharding_0
およびuser_sharding_1
ライブラリにそれぞれ散らばっています。
元の質問に戻ります。データ情報を見つける方法です。ShardingSphere-Proxy はテーブルを論理的に集約しているため、直接クエリを実行しても問題ありません。
mysql> select * from t_user where user_id = 1;
+----+---------+---------------------+
| id | user_id | create_date |
+----+---------+---------------------+
| 1 | 1 | 2021-01-01 00:00:00 |
+----+---------+---------------------+
1 row in set (0.01 sec)
复制代码
2 番目の質問は、2022 年のユーザー数の増加とユーザー ステータスのクエリです。
mysql> select count(*) from t_user where create_date > '2022-00-00 00:00:00';
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.10 sec)
mysql> select * from t_user where create_date > '2022-00-00 00:00:00';
+----+---------+---------------------+
| id | user_id | create_date |
+----+---------+---------------------+
| 4 | 4 | 2022-01-01 00:00:00 |
| 6 | 6 | 2022-01-01 00:00:00 |
| 5 | 5 | 2022-01-01 00:00:00 |
+----+---------+---------------------+
3 rows in set (0.02 sec)
复制代码
3番目の質問は上記と同じです。
最終まとめ
この記事では、ShardingSphere-Proxy の基本的な概念を図とテキストで説明し、サブデータベースとテーブルの分割後に生成される実際の運用と保守のシナリオを紹介し、ShardingSphere-Proxy を使用して関連する問題を解決する方法を示します。
これを読めば、ShardingSphere-Proxy の理解が深まると思います。まず、ShardingSphere-Proxy の位置付けが製品の開発と保守を支援することであることを理解し、ShardingSphere-JDBC と ShardingSphere-Proxy の違いを理解し、両者の長所と短所とその方法を理解する必要があります。実装されました。これに基づいて、2 つのソース コードを理解しやすくなります。