分散データベースの構築方法

リレーショナル データベースは、過去数十年にわたってデータベース分野において常に絶対的な支配的地位を占めてきました。これらがもたらす安定性、セキュリティ、使いやすさは、現代のシステムを構築するための基礎となっています。インターネットの急速な発展により、単一マシン システム上に構築されたデータベースでは、増加する同時要求とデータ ストレージのニーズを満たすことができなくなりました。そのため、分散データベースはますます広く使用されるようになっています。

データベース分野は常に西洋のテクノロジー企業とコミュニティによって支配されてきました。現在、国内のデータベースソリューションは分散ベースがますます増えており、この分野で徐々に成果を上げています。 Apache ShardingSphere は分散データベース ソリューションの 1 つであり、現在 Apache Software Foundation の唯一のデータベース ミドルウェアです。

分散データベース ソリューションの設計目標は、従来のリレーショナル データベースの SQL およびトランザクションと完全に互換性があり、分散システムに自然に適応することです。その中核機能は主に以下の点に集中しています。

• 分散ストレージ: データストレージは単一のマシンのディスク容量によって制限されず、データサーバーの数を増やすことでストレージ容量を増やすことができます。

• コンピューティングとストレージの分離: コンピューティング ノードはステートレスであり、水平方向の拡張によってコンピューティング能力を増強できます。ストレージ ノードとコンピューティング ノードはレイヤーごとに最適化できます。

• 分散トランザクション: ローカル トランザクションの ACID プリミティブを完全にサポートする高性能分散トランザクション処理エンジン。

• 弾力的なスケーリング: データ ストレージ ノードは、既存のアプリケーションに影響を与えることなく、いつでもどこでも動的に拡張または縮小できます。

• 複数のデータ コピー: 絶対的なデータ セキュリティを確保するために、一貫性とパフォーマンスに優れた方法で、データ センター間で複数のコピーにデータを自動的に複製します。

• HTAP: OLTP トランザクション操作と OLAP 分析操作の両方を処理するために同じ製品セットが使用されます。

分散データベースの実装は、アグレッシブ タイプと安定タイプに分けられます。積極的な実装ソリューションは、完全に新しいアーキテクチャで NewSQL を開発することです。このタイプの製品は、安定性と不十分な操作および保守経験を犠牲にして、より高いパフォーマンスを追求します。安定した実装ソリューションとは、既存のデータベースに基づいて増分機能を提供するミドルウェアを指します。このタイプの製品では、データベースの安定性と操作および保守エクスペリエンスの再利用を確保するために、ある程度のパフォーマンスが犠牲になります。

Apache ShardingSphere は、Sharding-JDBC、Sharding-Proxy、Sharding-Sidecar (計画中) という 3 つの独立した製品で構成されるオープンソースの分散データベース ミドルウェア ソリューション エコシステムです。これらはすべて、標準化されたデータ シャーディング、分散トランザクション、分散ガバナンス機能を提供し、Java 同型、異種言語、クラウド ネイティブなどのさまざまなアプリケーション シナリオに適用できます。 Apache ShardingSphere は、クエリ オプティマイザーと分散トランザクション エンジンの継続的な調査により、実装ソリューションの製品境界を徐々に打ち破り、積極性と安定性を兼ね備えたプラットフォーム レベルのソリューションへと進化しました。

軽量 Java フレームワークとして位置付けられ、Java JDBC レイヤーで追加のサービスを提供します。クライアントを使用してデータベースに直接接続し、jar パッケージの形式でサービスを提供します。追加のデプロイメントや依存関係は必要ありません。これは JDBC ドライバーの拡張バージョンとして理解でき、JDBC およびさまざまな ORM フレームワークと完全に互換性があります。

透過的なデータベース プロキシとして位置付けられ、異種言語をサポートするためにデータベース バイナリ プロトコルをカプセル化するサーバー バージョンを提供します。現在、MySQL および PostgreSQL バージョンが利用可能です。 MySQL および PostgreSQL プロトコルと互換性のある任意のアクセス クライアント (MySQL Command Client、MySQL Workbench、Navicat など) を使用してデータを操作できるため、DBA にとってより使いやすくなります。

これは、Kubernetes のクラウドネイティブ データベース プロキシとして位置付けられており、サイドカーの形式でデータベースへのすべてのアクセスをプロキシします。データベースと対話するためのメッシュ レイヤーは、分散型のゼロ侵入型ソリューションであるデータベース メッシュ (データベース グリッドとも呼ばれます) を通じて提供されます。

Sharding-JDBC は分散型アーキテクチャを採用しており、Java で開発された高性能な軽量 OLTP アプリケーションに適しています。 Sharding-Proxy は、静的エントリと異種言語のサポートを提供し、OLAP アプリケーションや、シャード データベースの管理と操作のシナリオに適しています。

各アーキテクチャ ソリューションには、それぞれ長所と短所があります。次の表は、さまざまなシナリオにおけるさまざまなアーキテクチャ モデルの長所と短所を比較したものです。

Apache ShardingSphere は、複数のアクセス ポイントで構成されたエコシステムです。 Sharding-JDBC と Sharding-Proxy を混在させ、同じ構成センターを使用してシャーディング戦略を統一的に構成することで、さまざまなシナリオに適したアプリケーション システムを柔軟に構築でき、アーキテクトは現在のビジネスに適した最適なシステム アーキテクチャをより自由に調整できるようになります。

Apache ShardingSphere は Share Nothing アーキテクチャを採用しており、JDBC と Proxy アクセス エンドは両方ともステートレス設計を採用しています。コンピューティング ノードとして、Apache ShardingSphere は取得したデータの最終的な計算と集約を担当します。 Apache ShardingSphere はデータ自体を保存しないため、計算をデータ ノードにプッシュダウンして、データベース自体の計算能力を最大限に活用できます。 Apache ShardingSphere は、デプロイされたノードの数を増やすことで計算能力を高めることができます。データベース ノードの数を増やすことで、ストレージ容量を増やすことができます。

現時点では、データ シャーディング、分散トランザクション、弾性スケーリング、分散ガバナンスが Apache ShardingSphere の 4 つのコア機能です。

分割統治法は、Apache ShardingSphere が大量のデータを処理するために使用するソリューションです。 Apache ShardingSphere は、データ シャーディング ソリューションを使用して、データベースに分散ストレージ機能を持たせます。

ユーザーが事前に設定したシャーディング アルゴリズムに従って、SQL を対応するデータ ノードに自動的にルーティングし、複数のデータベースを操作するという目的を達成できます。ユーザーは、単一のデータベースを使用する場合と同じように、Apache ShardingSphere によって管理される複数のデータベースを使用できます。現在、MySQL、PostgreSQL、Oracle、SQLServer、およびSQL92標準およびJDBC標準プロトコルをサポートするすべてのデータベースをサポートしています。データ シャーディングのカーネル プロセスを次の図に示します。

主なプロセスは次のとおりです。

1. データベース プロトコル パッケージまたは JDBC ドライバーを解析して、ユーザーが入力した SQL とパラメーターを取得します。

2. 字句解析器と構文解析器に従って SQL を AST (抽象構文木) に解析し、セグメンテーションに必要な情報を抽出します。

3. ユーザーが事前に設定したアルゴリズムに従ってシャード キーを照合し、ルーティング パスを計算します。

4. SQL を分散実行可能 SQL に書き換えます。

5. SQL は各データ ノードに並列に送信され、実行エンジンは接続プールとメモリ リソースのバランスをとる役割を担います。

6. AST に基づいてストリームまたはフルメモリ結果セットのマージ計算を実行します。

7. データベース プロトコル パケットまたは JDBC 結果セットをカプセル化し、クライアントに返します。

トランザクションはデータベースシステムの中核機能です。分散の不確実性とトランザクションの複雑さにより、分散トランザクションの分野では万能のソリューションは存在しません。

開発が盛んな現在の状況に直面して、Apache ShardingSphere は、標準インターフェースを使用して、開発者が選択したサードパーティの分散トランザクション フレームワークを統一的に統合し、さまざまなシナリオのアプリケーション ニーズを満たす、高度にオープンなソリューションを提供します。さらに、Apache ShardingSphere は、既存のソリューションの欠点を補うために、新しい分散トランザクション ソリューション JDTX も提供します。

Apache ShardingSphere は、ローカル トランザクション、2 フェーズ トランザクション、柔軟なトランザクション用の統合適応インターフェイスを提供し、多数の既存のサードパーティの成熟したソリューションに接続します。標準インターフェースを通じて、開発者は他の統合ソリューションを Apache ShardingSphere プラットフォームに簡単に統合できます。

ただし、多数のサードパーティ ソリューションを統合しても、分散トランザクション要件のすべての分野をカバーすることはできません。各ソリューションには、適切なシナリオと不適切なシナリオがあります。これらのソリューションは相互に排他的であり、それぞれの利点を組み合わせることはできません。最も一般的な 2PC (2 フェーズ コミット) および柔軟なトランザクションには、次の利点と欠点があります。

• 2 フェーズ コミット: XA プロトコルに基づいて実装された 2 フェーズ分散トランザクションは、ビジネスへの影響がほとんどありません。その最大の利点は、ユーザーに対して透過的であり、開発者はローカル トランザクションのように XA プロトコルに基づく分散トランザクションを使用できることです。 XA プロトコルはトランザクションの ACID 特性を厳密に保証できますが、諸刃の剣でもあります。トランザクション実行プロセス中は、必要なすべてのリソースをロックする必要があります。これは、実行時間が一定の短いトランザクションに適しています。長いトランザクションの場合、トランザクション全体にわたってリソースが独占されると、ホット データに依存するビジネス システムの同時パフォーマンスが大幅に低下します。したがって、同時実行性が高くパフォーマンスを優先するシナリオでは、XA プロトコルの 2 フェーズ コミット タイプに基づく分散トランザクションは最適な選択ではありません。

• 柔軟なトランザクション: ACID トランザクション要素を実装するトランザクションを固定トランザクションと呼ぶのに対し、BASE トランザクション要素に基づくトランザクションは柔軟なトランザクションと呼ばれます。 BASE は、基本的な可用性、柔軟な状態、最終的な一貫性の略語です。 ACID トランザクションでは、一貫性と分離性の要件が非常に高く、トランザクションの実行中はすべてのリソースを占有する必要があります。柔軟なトランザクションの考え方は、ビジネス ロジックを通じて、ミューテックス操作をリソース レベルからビジネス レベルに移動するということです。強力な一貫性と分離の要件を緩和することで、トランザクション全体が最終的に完了したときにデータの一貫性が保たれていることのみが要求されます。トランザクションの実行中に、読み取り操作によって取得されたデータは変更される可能性があります。この弱い一貫性の設計は、システムのスループットを向上させるために使用できます。

ACID ベースの 2 フェーズ トランザクションも BASE ベースの結果整合性トランザクションも、万能薬ではありません。次の表では、それらの違いを詳しく比較します。

同時実行の保証がない 2 フェーズ トランザクションは、完全な分散トランザクション ソリューションとは言えません。 ACID の本来の意味をサポートしていない柔軟なトランザクションは、データベース トランザクションと呼ぶことすらできません。これらは、サービス層でのトランザクション処理に適しています。

現時点では、トレードオフなしで普遍的に適用できる分散トランザクション ソリューションを見つけることは困難です。

JDTX は、JD Digits によって開発された分散トランザクション ミドルウェアであり、まだオープン ソース化されていません。その設計目標は、強力な一貫性 (ACID トランザクション セマンティクスをサポート)、高いパフォーマンス (ローカル トランザクション パフォーマンスよりも低くない)、および 1PC (2 フェーズ コミットと 2 フェーズ ロックを完全に放棄) を備えた、完全に分散されたトランザクション ミドルウェアになることです。現在、リレーショナル データベースに使用できます。完全にオープンな SPI 設計アプローチを採用し、NoSQL とのドッキングが可能で、将来的には同じトランザクションで複数の異種データを維持できるようになります。

JDTX は、完全に自社開発したトランザクション処理エンジンを使用して、SQL 操作トランザクション内のデータを KV (キーと値のペア) に変換し、それに基づいて、データベース設計コンセプトに類似した MVCC (マルチバージョン スナップショット) トランザクション可視性エンジンと WAL (先行書き込みログ システム) ストレージ エンジンを実装します。次のアーキテクチャ図から、JDTX の構成を理解できます。

その設計上の特徴は、トランザクション内のデータ (アクティブ データと呼ばれる) とトランザクション内にないデータ (ディスク データと呼ばれる) を分離することです。アクティブ データが WAL に書き込まれた後、KV の形式で MVCC メモリ エンジンに保存されます。ディスクにドロップされたデータは、WAL 内の REDO ログを非同期にフラッシュすることにより、フロー制御可能な方法で最終的なストレージ メディア (リレーショナル データベースなど) に同期されます。トランザクション メモリ クエリ エンジンは、SQL を使用して KV 形式のアクティブ データから関連データを取得し、それをディスク データとマージし、トランザクション分離レベルに基づいて現在のトランザクションに表示されるデータ バージョンを取得する役割を担います。

JDTX は、新しいアーキテクチャを使用してデータベース トランザクション モデルを再解釈します。主なハイライトは次のとおりです。

1. 分散トランザクションをローカルトランザクションに内部化する

JDTX の MVCC エンジンは集中型キャッシュです。 2 フェーズ コミットを 1 フェーズ コミットに内部化することで、単一ノード内のデータの原子性と一貫性を維持し、分散トランザクションの範囲をローカル トランザクションの範囲に縮小できます。 JDTX は、トランザクション データへのすべてのアクセスが MVCC エンジンのアクティブ データと最終データの最後にディスクにドロップされたデータのマージを通じて行われるようにすることで、トランザクション データの原子性と一貫性を保証します。

2. ロスレストランザクション分離メカニズム

トランザクションの分離は MVCC 方式で実現されます。現在、4 つの標準分離レベルのうち、コミット読み取りと繰り返し読み取りを完全にサポートしており、ほとんどのニーズを満たすことができます。

3. 高いパフォーマンス

アクティブ データをストレージ メディアに非同期的にフラッシュする方法により、データ書き込みのパフォーマンス上限が大幅に向上します。パフォーマンスのボトルネックは、データベースへの書き込みにかかる時間から、WAL および MVCC エンジンへの書き込みにかかる時間に移行しました。

データベースの WAL システムと同様に、JDTX の WAL も順次ログ追加方式を使用しているため、単純に JDTX の WAL 時間消費 = データベース システムの WAL 時間消費と理解できます。 MVCC エンジンは KV データ構造を使用するため、BTree インデックスを維持するデータベースよりも書き込み時間が短くなります。したがって、JDTX のデータ更新パフォーマンスの上限は、トランザクションを有効にしない場合よりもさらに高くなる可能性があります。

4. 高可用性

WAL エンジンと MVCC エンジンはどちらも、マスター/スレーブ + シャーディング アプローチを通じて、高可用性と水平スケーラビリティを維持できます。 MVCC エンジンが完全に使用できなくなった場合、WAL 内のデータはリカバリ モードを通じてデータベースに同期され、データの整合性が確保されます。

5. 複数のデータベースにまたがるトランザクション

トランザクションのアクティブ データをディスク データから分離する設計により、ディスク データ ストレージ側での制限がなくなります。トランザクションのアクティブ データは非同期ディスク エグゼキュータを介してバックエンド ストレージ メディアに保存されるため、バックエンドが同種のデータベースであるかどうかは問題ではありません。 JDTX を使用すると、複数のストレージ ターミナル (MySQL、PostgreSQL、さらには MongoDB や Redis などの NoSQL など) にわたる分散トランザクションが同じトランザクション セマンティクスを維持することが保証されます。

Apache ShardingSphere が提供する統合分散トランザクション アダプタ インターフェイスを通じて、JDTX は他のサードパーティの分散トランザクション ソリューションと同様に Apache ShardingSphere エコシステムに簡単に統合でき、データ シャーディングと分散トランザクションをシームレスに組み合わせて、分散データベース インフラストラクチャを形成できます。製品のフロントエンドにインストールされる Apache ShardingSphere は、SQL 解析、データベース プロトコル、およびデータ シャーディングに使用されます。中間層の JDTX は、KV および MVCC を介してトランザクションのアクティブ データを処理するために使用されます。最下層のデータベースは、最終的なデータ保存の端としてのみ機能します。下の図はShardingSphere + JDTXのアーキテクチャ図です。

JDTXの存在により、Apache ShardingSphereは安定的なデータベースミドルウェアという位置づけを打破し、安定性を保ちつつも、徐々に攻めのNewSQLへと進化していったと言えます。

ステートレスなサービス指向アプリケーションとは異なり、データ ノードには失われることのない重要なユーザー データが格納されます。急速に成長するビジネスをサポートするにはデータ ノードの容量が不十分な場合、データ ノードの拡張は避けられません。容量拡張戦略は、ユーザーが事前に設定したシャーディング戦略によって異なります。

エラスティック スケーリングにより、外部サービスを停止することなく、Apache ShardingSphere によって管理されるデータベースを拡張または縮小できます。エラスティック スケーリングは、エラスティック マイグレーションとスコープ拡張の 2 つのコンポーネントに分かれており、どちらも現在インキュベーション段階にあります。

データ移行は、ユーザーがカスタマイズしたシャーディング戦略のための標準的なスケーリング ソリューションです。移行プロセス中に、2 セットのデータ ノードを準備する必要があります。元のデータ ノードは引き続きサービスを提供しながら、ストック形式と増分形式の両方で新しいデータ ノードにデータを書き込みます。移行プロセス全体では外部サービスを停止する必要がなく、新旧のデータノードをスムーズに移行できます。 Apache ShardingSphere は、移行プロセスを完全に自律的かつ制御可能にするワークフロー インターフェイスも提供します。エラスティック移行のアーキテクチャ図は次のとおりです。

具体的なプロセスは以下のとおりです。

1. 構成センターを通じてデータ シャーディング構成を変更し、移行プロセスをトリガーします。

2. 現在の移行データが開始される前に場所を記録した後、履歴移行ジョブを開始し、完全なデータをバッチで移行します。

3. サイトの後の増分データを移行するには、Binlog サブスクリプション ジョブを開始します。

4. サンプリングレートに応じて比較データを設定します。

5. リアルタイムのデータ移行が完了するように、元のデータ ソースを読み取り専用に設定します。

6. アプリケーション接続を新しいデータ ソースに切り替えます。

7. 古いデータ ソースはオフラインです。

移行時間は、データの量に応じて数分から数週間までさまざまです。移行プロセス中はいつでもロールバックしたり再度移行したりできます。移行プロセス全体は完全に自律的かつ制御可能であり、移行プロセスにおけるリスクが軽減されます。自動化ツールにより手動操作は完全に保護され、面倒な操作によって生じる膨大な作業負荷を回避できます。

弾力的な移行をハード スケーリングと呼ぶのに対し、範囲の拡張はソフト スケーリングと呼びます。 Apache ShardingSphere のスコープ拡張には、カーネルの変更やデータの移行は含まれません。スコープシャーディング戦略を最適化するだけで、自動拡張（縮小）の目標を達成できます。拡張範囲を使用すると、ユーザーはシャーディング戦略やシャーディング キーなどのシャーディング スキームの必要な概念を意識する必要がなくなり、Apache ShardingSphere は統合分散データベースに近づきます。

使用範囲を拡大したいユーザーは、Apache ShardingSphere にデータベース リソース プールを提供するだけで済みます。テーブル容量がしきい値に達すると、容量インスペクターはリソース プールから次のデータ ノードを順番に検索し、新しいデータ ノードが新しいテーブルを作成した後、シャーディング戦略の範囲メタデータを変更します。リソース プールに新しいデータ ノードがない場合、Apache ShardingSphere は、テーブルが同じ順序で作成されたデータベースに新しいテーブルを追加します。大量のテーブル データが削除されると、以前のデータ ノードのデータはコンパクトではなくなり、ガベージ コレクターは定期的にテーブル範囲を圧縮して、断片化された領域をさらに解放します。スコープ拡張の構造は次のとおりです。

Apache ShardingSphere は、さまざまなアプリケーション シナリオに対して、より柔軟で弾力的なスケーリング戦略を提供します。現在もインキュベーション段階にある 2 つの Elastic Sc​​aling 関連プロジェクトも、できるだけ早く試用版を提供できるよう努めています。

ガバナンス モジュールは、分散データベースをより適切に管理および使用できるように設計されています。

すべての分散システムの設計哲学に沿って、分割統治は分散データベースの基本原則でもあります。データベース ガバナンス機能があれば、データベース インスタンスの数が増えても管理コストが増加するのを防ぐことができます。

Apache ShardingSphere は構成センターを使用して構成を管理します。構成は、変更後すぐにすべてのアクセスエンドインスタンスに伝播されます。構成センターはオープン SPI 方式を採用しており、複数のバージョンの変更を構成するなど、構成センター自体の機能を最大限に活用できます。

Apache ShardingSphere は、登録センターを使用して、アクセス インスタンスとデータベース インスタンスの動作状況を管理します。登録センターも構成センターのオープンSPI方式を採用しています。一部の登録センターの実装では構成センターの機能をカバーできるため、ユーザーは登録センターと構成センターの機能を重ね合わせて使用​​できます。

Apache ShardingSphere は、データベース インスタンスを無効にしてアクセス ポイントを融合する機能を提供します。これは、データベース インスタンスが使用できず、アクセス ポイントが大量のトラフィックの影響を受けるシナリオを処理するために使用されます。

Apache ShardingSphere は現在、高可用性 SPI を開発中であり、ユーザーはデータベース自体が提供する高可用性ソリューションを再利用できます。現在、MySQL の MGR 高可用性ソリューションに接続しています。 Apache ShardingSphere は、MGR 選択の変更を自動的に検出し、それをすべてのアプリケーション インスタンスにすばやく伝播できます。

データベースとアクセス ポイント インスタンスの数が多いと、DBA や運用保守担当者が現在のシステムの状態を迅速に把握することが困難になります。 Apache ShardingSphere は OpenTracing プロトコルを実装し、プロトコルを実装するサードパーティの APM システムに監視データを送信します。さらに、Apache ShardingSphere は Apache SkyWalking の自動プローブも提供しており、これにより、可観測性製品として使用するユーザーは、Apache ShardingSphere のパフォーマンス、呼び出しチェーンの関係、およびシステムの全体的なトポロジを直接観察できます。

Apache ShardingSphere の柔軟な SQL 処理機能とデータベース プロトコルとの高い互換性により、データ関連のガバナンス機能も製品エコシステムに便利に追加されます。

Apache ShardingSphere を使用すると、ユーザーはコードを変更せずに指定されたデータ列を自動的に暗号化してデータベースに保存し、アプリケーションがデータを取得するときに復号化してデータのセキュリティを確保できます。データベースのデータが誤って漏洩した場合でも、機密データ情報は完全に暗号化されているため、セキュリティ上の大きなリスクは発生しません。

Apache ShardingSphere は、システムがフルリンク ストレス テストを実行するときに、ユーザーがマークしたデータをシャドウ ライブラリ (テーブル) に自動的にルーティングできます。シャドウ ライブラリ (テーブル) ストレス テスト機能を使用すると、オンライン ストレス テストを通常の実行にすることができ、ユーザーはストレス テスト データのクリーンアップについて心配する必要がなくなります。この機能も高速でインキュベーション中です。

ご覧のとおり、Apache ShardingSphere は急速に開発が進んでおり、以前の「シャーディング」のメインラインとはあまり関係のない機能がどんどん追加されています。ただし、これらの製品機能は邪魔になるものではありません。代わりに、Apache ShardingSphere がより多様な分散データベース ソリューションになるよう支援できます。 Apache ShardingSphere の今後の方向性は、主に以下の点に重点が置かれます。

ますます分散した機能をさらに整理する必要があります。 Apache ShardingSphere の既存のアーキテクチャでは、このような幅広い製品機能を完全に吸収するには不十分です。柔軟で機能的なプラグ可能なプラットフォームは、Apache ShardingSphere の将来のアーキテクチャ調整の方向性です。

プラグ可能なプラットフォームは、技術的側面と機能的側面の両方から Apache ShardingSphere を完全に分解します。 Apache ShardingSphere の全体像は次のとおりです。

Apache ShardingSphere は、技術アーキテクチャに応じて、アクセス層、SQL 解析層、カーネル処理層、ストレージ アクセス層の 4 つの層に水平に分割されます。機能は、プラグ可能な形式で 4 層アーキテクチャに統合されます。

Apache ShardingSphere は、データベース タイプのサポートを完全にオープンにします。リレーショナル データベースに加えて、NoSQL も完全にサポートされます。データベース方言は互いに影響を及ぼさず、完全に分離されています。機能面では、Apache ShardingSphere は重ね合わせアーキテクチャ モデルを採用しており、さまざまな機能を柔軟に組み合わせて使用​​できます。各機能モジュールは、自身のコア機能にのみ集中する必要があり、Apache ShardingSphere アーキテクチャが機能の重ね合わせと組み合わせを担当します。機能がなくても、Apache ShardingSphere を空のアクセス ポイントとして直接起動して、開発者のカスタマイズされた開発のためのスキャフォールディングや SQL 解析などのインフラストラクチャを提供できます。 Apache ShardingSphere エコシステムに統合されたデータベースは、プラットフォームによって提供されるすべての基本機能を直接取得します。 Apache ShardingSphere プラットフォームで開発された関数は、プラットフォームに接続されたデータベース タイプに対しても直接完全なサポートを取得します。データベース型と機能型は乗法的に配置され、組み合わせられます。インフラストラクチャ + レゴの組み合わせにより、Apache ShardingSphere にさまざまな想像力と改善の余地が生まれます。

現在、Apache ShardingSphere は、正しいルーティングと書き換えを通じてデータを操作するために、対応するデータベースに SQL を配布するだけです。計算と配信ではデータベースのクエリ エンジンを最大限に活用できますが、複雑な関連クエリとサブクエリを効果的にサポートすることはできません。リレーショナル代数に基づく KV クエリ エンジン上の SQL は、JDTX の開発によりさらに成熟しました。蓄積された経験は SQL クエリ エンジンにフィードバックされ、Apache ShardingSphere はサブクエリやデータベース間の関連クエリなどの複雑なクエリをより適切にサポートできるようになります。

Apache ShardingSphere には現在、分散データベースに必要な複数のデータ コピー機能がありません。将来、Apache ShardingSphere は Raft に基づくマルチコピー書き込み機能を提供する予定です。

前述の Sharding-Sidecar アクセス ポイントは、Kubernetes との連携を強化してクラウド ネイティブ データベースを構築することを目指した、Apache ShardingSphere の将来の第 3 のアクセス ポイント形式です。

データベース メッシュは、分散データ アクセス アプリケーションをデータベースに有機的に接続する方法に重点を置いています。相互作用にさらに注意を払い、整理されていないアプリケーションとデータベース間の相互作用を効果的に整理します。データベース メッシュを使用すると、データベースにアクセスするアプリケーションとデータベースが最終的に巨大なグリッド システムを形成します。アプリケーションとデータベースはグリッド システムに配置するだけでよく、それらはすべてメッシュ レイヤーによって管理されるオブジェクトです。

Apache ShardingSphere は、さらに多くのデータベース タイプをサポートした後、複数の異種データベース タイプ用の統合クエリ エンジンの開発に注力します。さらに、Apache ShardingSphere は JDTX と連携して、より多様なデータ ストレージ メディアを同じトランザクションに組み込む予定です。

Apache ShardingSphere は、2016 年 1 月 17 日に GitHub で初めてオープンソース化されました。このオープンソース プロジェクトの最初の名前は Sharding-JDBC でした。 2018 年 11 月 10 日、ShardingSphere は名前を変更し、Apache Software Foundation のインキュベーターに正式に参加しました。

Apache ShardingSphere がオープンソース化されてから 4 年間、Apache ShardingSphere のアーキテクチャ モデルは絶えず進化しており、製品全体の機能範囲も急速に拡大しています。オープンソースの初期にはデータベースとテーブルをシャーディングするための Java 開発フレームワークでしたが、徐々に分散データベース ソリューションへと進化してきました。

Apache ShardingSphere エコシステムの拡大により、少数の開発者によってプロジェクトが管理される現状は長い間打破されてきました。現在、Apache ShardingSphere には約 100 人の貢献者と約 20 人のコア コミッターがおり、Apache Way に従うこのコミュニティの構築に協力しています。 Apache ShardingSphere は、Apache Software Foundation の標準オープンソース プロジェクトであり、営利企業や少数のコア開発者によって管理されていません。

現在、100 社を超える企業が Apache ShardingSphere を使用していることを明示的に表明しています。公式サイトから、導入企業のユーザーウォールをご覧いただけます。

コミュニティが成熟するにつれて、Apache ShardingSphere はますます急速に成長しています。興味のある開発者の皆様には、Apache ShardingSphere コミュニティに参加していただき、拡大し続けるエコシステムの改善にご協力いただければ幸いです。

プロジェクトアドレス:

https://github.com/apache/incubator-shardingsphere