序文
「私は以前、マイクロサービスについていつも話していました。マイクロサービス自体も分散システムです。実際、マイクロサービスの中心的な考え方は、分割して征服することです。複雑な単一システムを、ビジネスのデリバリに応じて異なるセルフサービスに分割して、コストを削減します」複雑性が高まると同時に、システムのスケーラビリティも向上します。
今日はサブデータベースとサブテーブルについてお話したいと思います。これは急成長するビジネスにとって避けられない関係だからです。以前、モールに関連する SAAS システムに取り組んでいました。コモディティ プールがストレージのボトルネックになっています。コモディティ プールの数は、テナントと運営の成長に基づいて指数関数的に増加します。わずか 1 回で数千万のデータに増加する可能性があります。数か月後には1億を超えるかもしれません。受注データも、ビジネスの成長に伴ってどんどん大きくなっていきます。
ストレージ層に関する限り、大量のデータの下でのストレージとクエリのパフォーマンスを向上させるには、別のレベルの問題が伴いますが、考え方は同じであり、分割して征服します。
私たちはどのような問題に直面しているのか
リレーショナルデータベースは、データ量が一定量を超えると検索性能が急激に低下します。大量のデータに直面すると、すべてのデータが 1 つのテーブルに保存され、明らかにデータベース テーブルの容量を簡単に超えてしまいます。
また、単純なサブテーブルでは、データ量過多による検索の遅さの問題は解決できますが、同じデータベースにアクセスする同時リクエストが多すぎることによるデータベースの応答の遅さの問題は解決できません。したがって、単一データベース インスタンスのパフォーマンスのボトルネック問題を解決するには、サブデータベースが必要です。
データベースアーキテクチャスキーム
具体的なソリューションについて説明する前に、データベースの 3 つのアーキテクチャと関連するソリューションを理解する必要があります。
1. すべてを共有する
一般に、単一ホストの環境を指し、完全に透過的に共有された CPU/メモリ/ハードディスク、並列処理能力は最悪、一般に大規模な同時要件は考慮されていない、アーキテクチャは比較的単純で、一般的なアプリケーション要件は基本的に適用可能です。満たした。
2. 共有ディスク
各処理ユニットは独自の CPU とメモリを使用し、ディスク システムを共有します。代表的なものは Oracle RAC と DB2 PureScale です。たとえば、Oracle RACは共有ストレージを使用してデータ共有を実現し、ノードを追加することで並列処理能力を向上でき、優れた拡張性を備え、ストレージ・エリア・ネットワーク(SAN)を使用してファイバ・チャネルを介して複数のサーバーのディスク・アレイに接続します。ネットワーク消費量を削減し、データ読み取りの効率を向上させ、同時実行性の高い OLTP アプリケーションでよく使用されます。これは SMP (Symmetric Multi-Processing) モードに似ていますが、メモリ インターフェイスが飽和状態に達すると、ノードを追加してもより高いパフォーマンスを達成できなくなり、ノードが増えると運用と保守のコストが増加します。
3. 何も共有しない
各処理ユニットには独自の CPU/メモリ/ハードディスクなどがあります。名前が示すように、MPP (超並列処理) モードと同様に共有リソースを持たないものはなく、各処理ユニットはプロトコルを通じて通信し、並列処理します。拡張機能も優れています。代表的なのはDB2 DPF、サブデータベースとサブテーブルを備えたMySQL Clusterであり、各ノードは互いに独立して独自のデータを処理し、処理結果は上位層に集約されたり、ノード間を循環したりすることができます。
シャーディングについてよく言われることは、実際にはシェアードナッシングです。テーブルを物理ストレージから水平に分割し、複数のサーバー (または複数のインスタンス) に分散します。各サーバーは独立して動作し、MySQL プロキシや Google のさまざまなアーキテクチャなどの共通のスキーマを持ちます。サーバーの数を増やすことによってのみ、処理能力と容量を向上させることができます。
MPP に関しては、分析大規模並列処理 (MPP) データベースを指します。これは、通常、大規模なデータ セットの集約と処理が必要な分析ワークロード用に最適化されたデータベースです。MPP データベースは列形式になる傾向があるため、通常、テーブル内の各行をオブジェクトとして保存するのではなく、各列をオブジェクトとして保存します。このアーキテクチャにより、複雑な分析クエリをより高速かつ効率的に処理できるようになります。たとえば、TeraData、Greenplum、GaussDB100、TBase。
上記のアーキテクチャ ソリューションに基づいて、大容量データ ストレージ向けのソリューションを提供できます。
上記のソリューションにはそれぞれ長所と短所があります。パーティション モードの最大の問題は、CPU とメモリを水平方向に拡張できない準共有すべてアーキテクチャであるため、基本的に除外できます。nosql 自体は実際には非常に優れた代替手段です。 , しかし、nosql (ほとんどのオープンソース newsql を含む) は大量のハードウェアを消費し、運用コストとメンテナンスコストが高くなります。一般的に使用されるスキームの 1 つは、Mysql ベースのサブデータベースおよびサブテーブル スキームです。
サブデータベースとサブテーブルのアーキテクチャスキーム
サブデータベースとサブテーブルについては、まずどのような製品が市販されているかを確認します。
| 産業用コンポーネント | オリジナル工場 | 特徴 | 述べる |
|---|---|---|---|
| DBLE | Ecoson オープンソース コミュニティ | mysqlを中心とした拡張性の高い分散ミドルウェア | MyCAT をベースにした拡張バージョン。 |
| 美団アトラス | 美団 | 読み取りと書き込みの分離、単一データベースのサブテーブル | 現在、元の工場から徐々に撤去されています。 |
| コバー | アリ (B2B) | Cobar ミドルウェアは、フォアグラウンド アプリケーションと実際のデータベースの間にプロキシの形式で配置され、フォアグラウンドへのオープン インターフェイスは MySQL 通信プロトコルです | オープンソースバージョンのデータベースは MySQL のみをサポートしており、読み取りと書き込みの分離はサポートしていません。 |
| 私の猫 | アリ | MySQL プロトコルを実装したサーバーです。フロントエンド ユーザーはこれをデータベース プロキシとみなして、MySQL クライアント ツールとコマンド ラインを使用してアクセスでき、バックエンドは MySQL ネイティブ プロトコルを使用して複数の MySQL サーバーと通信できます。 | MyCAT は Ali のオープンソース Cobar 製品に基づいて開発されています |
| アトラス | 360 | 読み書き分離、静的テーブルパーティショニング | 2015年以降はメンテナンス無し |
| キングシャード | オープンソースプロジェクト | Go 社が開発した高性能 MySQL Proxy プロジェクトであり、基本的な読み書き分離機能を満たす点で、Kingshard のパフォーマンスは直結型 MySQL の 80% 以上です。 | |
| TDDL | アリタオバオ | 動的データソース、読み取り/書き込み分離、サブデータベースおよびサブテーブル | TDDL は 2 つのバージョンに分かれており、1 つはミドルウェアを含むバージョン、もう 1 つは直接 Java バージョンです。 |
| シマウマ | 美団点評 | 動的データソース、読み書き分離、サブデータベースサブテーブル、CAT監視を実現 | 完全な機能と監視、複雑なアクセス、および多くの制限。 |
| MTDDL | 美団点評 | 動的データ ソース、読み取りと書き込みの分離、分散一意の主キー ジェネレーター、サブデータベースのサブテーブル、接続プール、SQL モニタリング | |
| スピード | グーグル、ユーチューブ | クラスターは ZooKeeper をベースに管理され、データ処理は RPC によって実行され、サーバー、コマンドライン、GUI 監視の 3 つの部分に大別されます。 | Youtube一括申請 |
| DRDS | アリ | DRDS (分散リレーショナル データベース サービス) は、スタンドアロン リレーショナル データベースのスケーラビリティ問題の解決に焦点を当てており、軽量 (ステートレス)、柔軟性、安定性、効率性に優れており、アリババ グループによって独自に開発されました。 | |
| シャーディングプロキシ | Apache オープンソース プロジェクト | MySQL プロトコルと互換性のあるアクセス クライアント (MySQL Command Client、MySQL Workbench など) を使用してデータを操作できる、DBA にとってより使いやすい MySQL バージョンを提供します。アプリケーションに対して完全に透過的であり、MySQL として直接使用できます。MySQL プロトコルと互換性のあるあらゆるクライアントと互換性があります。 | Apache プロジェクトは、透過的なデータベース エージェントとして位置付けられ、異種言語をサポートするためにデータベース バイナリ プロトコルをカプセル化するサーバー バージョンを提供します。 |
| jdbcのシャーディング | Apache オープンソース プロジェクト | JDBC およびさまざまな ORM フレームワークと完全な互換性があります。JPA、Hibernate、Mybatis、Spring JDBC Template などの Java ベースの ORM フレームワークに適用するか、JDBC を直接使用します。DBCP、C3P0、BoneCP、Druid、HikariCP などのサードパーティのデータベース接続プールに基づきます。JDBC 仕様を実装するデータベースはすべてサポートされます。現在、MySQL、Oracle、SQLServer、PostgreSQL をサポートしています | Apache プロジェクトは、軽量の Java フレームワークとして位置付けられ、Java の JDBC レイヤーで追加のサービスを提供します。クライアントを使用してデータベースに直接接続し、追加の展開や依存関係を必要とせずに、jar パッケージの形式でサービスを提供します。JDBC ドライバーの拡張バージョンとして理解できます。 |
サブデータベース、サブテーブルの製品モードは、ミドルウェアモードとクライアントモードの2種類に分かれます。
1. ミドルウェアモデルのメリットとデメリット
ミドルウェア モードは独立したプロセスであるため、異種言語をサポートでき、現在のプログラムに侵入せず、ビジネス側にとって透過的な mysql サービスですが、ハードウェアの消費量が多く、操作量が多いなどの欠点も非常に明らかです。メンテナンスコスト（特にローカル実装の場合）がかかると同時に、リレーショナルデータベースにプロキシが追加されるため、デバッグが困難な問題が発生します。
2. クライアントモードのメリットとデメリット
クライアント モードの主な欠点は、コードに侵入するため、基本的に 1 つの言語しかサポートできないことですが、同時に、各クライアントはスキーマへの接続を確立する必要があるため、データベース インスタンスがあまりない場合、接続数は慎重に制御する必要がありますが、クライアント モードの利点も非常に明白です。まず第一に、アーキテクチャの点で分散化されているため、ミドルウェア モードでのプロキシ障害の問題が回避されます。中間層がないため高性能、柔軟性、制御性が高く、プロキシ層がないためプロキシが不要で、高可用性とプロキシのクラスタリングを考慮すると、運用保守コストが比較的低くなります。
sharding-jdbc アクセスの練習
Sharding-jdbc は、軽量の Java フレームワークとして位置付けられ、Java の JDBC 層で追加のサービスを提供するため、実際にはこれらの製品の中で最もよく知られています。クライアントを使用してデータベースに直接接続し、追加の展開や依存関係を必要とせずに、jar パッケージの形式でサービスを提供します。JDBC ドライバーの拡張バージョンとして理解でき、JDBC およびさまざまな ORM フレームワークと完全な互換性があります。JPA、Hibernate、Mybatis、Spring JDBC Template などの JDBC ベースの ORM フレームワークに適用するか、JDBC を直接使用します。また、コミュニティ活動とコードの品質の点でも非常に優れています。次に、アクセスの詳細について詳しく説明していきます。
1. コンポーネントの統合
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId> <version> 5.0.0</version>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>dynamic-datasource-spring-boot-starter</artifactId>
<version>3.4.0</version>
</dependency>
2.Beanの構成
シャーディング jdbc データ ソースを構成し、それをデータ ソース ルーティングの動的データ ソースに追加します。
元の構成センターで該当サービスのmysqlデータソース構成を変更し、データベースやテーブルを分割しないデータソースに対して動的データソースのデフォルトルートを構成します。
3. JDBC 設定の共有
spring.shardingsphere.enabled=true #shardingsphere开关
spring.shardingsphere.props.sql.show=true
spring.shardingsphere.mode.type=Standalone #在使用配置中心的情况下，使用standalone模式即可（memery、standalone、cluster三种模式）
spring.shardingsphere.mode.repository.type=File #standalone模式下使用File，即当前配置文件
spring.shardingsphere.mode.overwrite=true # 本地配置是否覆盖配置中心配置。如果可覆盖，每次启动都以本地配置为准。
spring.shardingsphere.datasource.names=ds-0,ds-1 #配置数据源名字，真实数据源
#配置ds-0数据源
spring.shardingsphere.datasource.ds-0.jdbc-url=jdbc:mysql://****
spring.shardingsphere.datasource.ds-0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds-0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds-0.username=
spring.shardingsphere.datasource.ds-0.password=
#配置ds-1数据源
spring.shardingsphere.datasource.ds-1.jdbc-url=jdbc:mysql://****
spring.shardingsphere.datasource.ds-1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds-1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds-1.username=
spring.shardingsphere.datasource.ds-1.password=
#配置模式数据库分片键和相关的表
spring.shardingsphere.rules.sharding.default-database-strategy.standard.sharding-column=user_id
spring.shardingsphere.rules.sharding.default-database-strategy.standard.sharding-algorithm-name=database-inline
spring.shardingsphere.rules.sharding.binding-tables[0]=t_order,t_order_item
spring.shardingsphere.rules.sharding.broadcast-tables=t_address #配置广播表，即所有库中都会同步增删的表
上記は、いくつかの基本的な構成といくつかのビジネス シナリオの構成です。オープン ソース コミュニティのドキュメントを参照できます: https://shardingsphere.apache.org/document/4.1.0/cn/overview/
要約する
具体的なビジネスシナリオに対しては、まずDDDの考え方に基づいて事業単位を分割し、まずデータベースの垂直部門をしっかりと行います。次に、ビジネスが大幅に成長するいくつかの特定のテーブルに対して、商品サブドメインの商品プール テーブル、注文サブドメインの注文テーブルなどの水平サブライブラリ処理を実行します。
サブテーブルの寸法については、ビジネスの初期段階では垂直テーブルの設計が必要となります。たとえば、製品プールの設計では、リレーショナル情報のみを保存する必要があり、製品の詳細情報は下部のテーブルに個別に保存されます。
著者: JD Logistics 趙永平
出典: JD Cloud 開発者コミュニティ