Sharding-jdbc
3428 ワード
jdbcは本当に大きな穴で、分庫分表が必要でなければsharding-jdbcは使用しないでください.多くの制限と不便がありますから.
バージョン:2.0.0.M 3
注意:本編は主にspring-mybatisに対してライブラリを分けないで表だけを分けて現在Sharding-JDBCはまだ絶えず更新している中で、ネット上の多くの資料と質疑応答はすべて以前現れたがすでに修復したので、本編を含めて、そのため学習資料と問題の解答は公式をめぐって歩くのが一番いいです.公式グループに参加することをお勧めします(公式サイトで探して、質問する人が多くて、回答する人が少ない)、githubの上のissuesでプロジェクトの質問の動態を見ることができます.
公式サイトにアクセス:http://shardingjdbc.io/githubソース:https://github.com/shardingjdbc/sharding-jdbc 公式demo:https://github.com/shardingjdbc/sharding-jdbc-example demoがダウンロードすると、sharding-jdbc-spring-namespace-exampleはspring-mybatisの例で、ライブラリの分表、分表のみ...などの異なる例があります.sharding-jdbcはどのようにして複数のsqlクエリを1つの結果にまとめたのか、ソースコード解析-結果を参照してまとめます.http://www.iocoder.cn/Sharding-JDBC/result-merger/#3-1-スライス構成と読み書き分離ソース解析:http://lalahei.iteye.com/category/363701
統合には、pom.xml、アプリケーション.xml、ポリシークラスの3つの場所を追加するだけです.以下は、ライブラリなしでテーブルのみを分割する部分構成です.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Sharding-JDBC 2.0.0.M 3バージョンは表だけを分けてライブラリを分けない使用記録:
データベース原生idで自増、スライス失効
Insertのsqlで、パケットにプライマリ・キー・フィールドが含まれている場合、sharding-jdbcのプライマリ・キーの自己増加は失効します.
sharding-jdbcの自己増加ポリシーを使用すると、偶数を生成する確率が高いため、t_order_0,t_order_1,t_order_2
分表した後に各表の主なキーが重複しないことを保証する必要があって、プログラム内で主なキーの挿入を生成することができます
スライスキーの選択(テーブル構造と業務の考慮を結びつける必要がある):プライマリ・キーはユーザーIDに基づいて割り当てられ、ある外部キーの値に基づいて割り当てられ、時間に基づいて割り当てられる
履歴データの処理が表分割された後、表分割ルールに従って元のデータを移行する必要があります.移行していないか、誤ったデータ表に移行した場合、これらのデータを調べることができません.
SQL文制限(既存のアイテムをshardingに追加して表分けするのが最も難しいのは、以前のSQL文を変更することです)
有限サポートサブクエリ
冗長カッコを含むSQLはサポートされていません
HAVINGはサポートされていません
OR,UNION,UNIOALLはサポートされていません
特殊INSERTはサポートされていません
INSERT文ごとに1つのデータしか挿入できません.VALES後に複数行のデータがある文はサポートされていません.
DISTINCT重合はサポートされていません
dual仮想テーブルはサポートされていません
SELECT LAST_はサポートされていませんINSERT_ID()
CASE WHENはサポートされていません
例:(1)sqlに'where order_が現れるid=1 OR order_id=2’,実行時にshardingの異常No support‘OR’(2)冗長括弧について,’...join...on a.id=b.id AND(1=1)where...’,このAND(1=1)whereの後ろに置くと異常ではないがjoin onの後ろに置くと以下の異常が現れる:io.shardingjdbc.core.parsing.parser.exception.SQLParsingException:SQL syntax error, expected token is ‘EQ’, actual token is ‘INT’, literals is ‘1’.
sqlに対する部分制限はグローバル(OR、CASE WHEN、冗長sql、部分子クエリなど)であり、表を区別しない場合は別のデータソースを追加する.公式FAQ第8条を参照:http://shardingjdbc.io/docs_cn/01-start/faq/.私はここの方法で成功しなかった.
サブテーブルの論理テーブル名の大文字と小文字の区別(後続バージョンで訂正)sql文のfromに続く最初のテーブルで大文字と小文字の区別が測定され、論理テーブルと異なる場合、クエリー時に全ルートを歩くのではなく、直接テーブルを実際のテーブルとして調べます.
バージョン:2.0.0.M 3
注意:本編は主にspring-mybatisに対してライブラリを分けないで表だけを分けて現在Sharding-JDBCはまだ絶えず更新している中で、ネット上の多くの資料と質疑応答はすべて以前現れたがすでに修復したので、本編を含めて、そのため学習資料と問題の解答は公式をめぐって歩くのが一番いいです.公式グループに参加することをお勧めします(公式サイトで探して、質問する人が多くて、回答する人が少ない)、githubの上のissuesでプロジェクトの質問の動態を見ることができます.
公式サイトにアクセス:http://shardingjdbc.io/githubソース:https://github.com/shardingjdbc/sharding-jdbc 公式demo:https://github.com/shardingjdbc/sharding-jdbc-example demoがダウンロードすると、sharding-jdbc-spring-namespace-exampleはspring-mybatisの例で、ライブラリの分表、分表のみ...などの異なる例があります.sharding-jdbcはどのようにして複数のsqlクエリを1つの結果にまとめたのか、ソースコード解析-結果を参照してまとめます.http://www.iocoder.cn/Sharding-JDBC/result-merger/#3-1-スライス構成と読み書き分離ソース解析:http://lalahei.iteye.com/category/363701
統合には、pom.xml、アプリケーション.xml、ポリシークラスの3つの場所を追加するだけです.以下は、ライブラリなしでテーブルのみを分割する部分構成です.
true
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Sharding-JDBC 2.0.0.M 3バージョンは表だけを分けてライブラリを分けない使用記録:
データベース原生idで自増、スライス失効
Insertのsqlで、パケットにプライマリ・キー・フィールドが含まれている場合、sharding-jdbcのプライマリ・キーの自己増加は失効します.
sharding-jdbcの自己増加ポリシーを使用すると、偶数を生成する確率が高いため、t_order_0,t_order_1,t_order_2
分表した後に各表の主なキーが重複しないことを保証する必要があって、プログラム内で主なキーの挿入を生成することができます
スライスキーの選択(テーブル構造と業務の考慮を結びつける必要がある):プライマリ・キーはユーザーIDに基づいて割り当てられ、ある外部キーの値に基づいて割り当てられ、時間に基づいて割り当てられる
履歴データの処理が表分割された後、表分割ルールに従って元のデータを移行する必要があります.移行していないか、誤ったデータ表に移行した場合、これらのデータを調べることができません.
SQL文制限(既存のアイテムをshardingに追加して表分けするのが最も難しいのは、以前のSQL文を変更することです)
有限サポートサブクエリ
冗長カッコを含むSQLはサポートされていません
HAVINGはサポートされていません
OR,UNION,UNIOALLはサポートされていません
特殊INSERTはサポートされていません
INSERT文ごとに1つのデータしか挿入できません.VALES後に複数行のデータがある文はサポートされていません.
DISTINCT重合はサポートされていません
dual仮想テーブルはサポートされていません
SELECT LAST_はサポートされていませんINSERT_ID()
CASE WHENはサポートされていません
例:(1)sqlに'where order_が現れるid=1 OR order_id=2’,実行時にshardingの異常No support‘OR’(2)冗長括弧について,’...join...on a.id=b.id AND(1=1)where...’,このAND(1=1)whereの後ろに置くと異常ではないがjoin onの後ろに置くと以下の異常が現れる:io.shardingjdbc.core.parsing.parser.exception.SQLParsingException:SQL syntax error, expected token is ‘EQ’, actual token is ‘INT’, literals is ‘1’.
sqlに対する部分制限はグローバル(OR、CASE WHEN、冗長sql、部分子クエリなど)であり、表を区別しない場合は別のデータソースを追加する.公式FAQ第8条を参照:http://shardingjdbc.io/docs_cn/01-start/faq/.私はここの方法で成功しなかった.
サブテーブルの論理テーブル名の大文字と小文字の区別(後続バージョンで訂正)sql文のfromに続く最初のテーブルで大文字と小文字の区別が測定され、論理テーブルと異なる場合、クエリー時に全ルートを歩くのではなく、直接テーブルを実際のテーブルとして調べます.