ShardingSphere サブデータベースとテーブル (1): 高性能アーキテクチャ モデル

インターネット ビジネスの台頭以降、膨大なユーザーと膨大なデータの特性により、単一のデータベース サーバーではビジネス ニーズを満たすことができなくなり、パフォーマンスを向上させるためにデータベース クラスターを検討する必要がありました。高性能データベース クラスター第一种方式是“读写分离”第二种方式是“数据库分片”

1. 読み書き分離アーキテクチャ

**読み取りと書き込みの分離の原則:** 読み取りと書き込みの分離の基本原理は、データベースの読み取りおよび書き込み操作を異なるノードに分散することです。以下はその基本アーキテクチャ図です:

ここに画像の説明を挿入します

読み取りと書き込みの分離の基本的な実装:

  • 主库负责处理事务性的增删改操作,从库负责处理查询操作、データ更新によって引き起こされる行ロックを効果的に回避でき、システム全体のクエリ パフォーマンスが大幅に向上します。
  • 読み取りと書き込みの分離は根据 SQL 语义的分析、です将读操作和写操作分别路由至主库与从库
  • この構成方法により一主多从、クエリ要求を複数のデータ コピーに均等に分散でき、システムの処理能力をさらに向上させることができます。
  • この方法では多主多从、システムのスループットが向上するだけでなく、システムの可用性も向上します。そのため、データベースが停止したり、ディスクが物理的に損傷したりしても、システムの通常の動作には影響がありません。

次の図は、ビジネス ニーズに基づいて、ユーザー テーブルの書き込み操作と読み取り操作を異なるデータベースにルーティングするソリューションを示しています。
ここに画像の説明を挿入します

CAP理論:

ブリューワーの定理としても知られる CAP 定理は、2000 年にカリフォルニア大学バークレー校のコンピューター科学者エリック ブリューワーによって ACM PODC で提案された予想です。对于设计分布式系统的架构师来说,CAP 是必须掌握的理论。

1 つの では分布式系统中、読み取りおよび書き込み操作に関して、3 つ (一貫性)、可用性 (可用性)、およびパーティション トレランス (パーティション トレランス) のうち 2 つだけを保証でき、もう 1 つは犠牲にする必要があります。

  • C 一貫性: 指定されたクライアントの場合、読み取り操作は最新の書き込み操作の結果を返すことが保証されます。
  • 可用性: 障害のないノードは適切な時間内に適切な応答を返します。(不是错误和超时的响应)
  • P 分割耐性: ネットワーク分割が発生した場合でも(可能是丢包,也可能是连接中断,还可能是拥塞)、システムは「その任務を実行」し続けることができます。

CAPの特徴:

  • 実際の設計プロセスでは、各システムは 1 種類のデータのみを処理することはできず、複数の種類のデータが含まれます。有的数据必须选择 CP,有的数据必须选择 AP,分布式系统理论上不可能选择 CA 架构。

    • CP: 以下の図に示すように、为了保证一致性パーティションが発生すると、N1 ノード上のデータは y に更新されますが、N1 と N2 の間のレプリケーション チャネルが中断されたため、データ y を N2 に同期できなくなります。 N2 ノード上のデータはまだ x です。这时客户端 C 访问 N2 时,N2 需要返回 Error,提示客户端 C“系统现在发生了错误”,この処理方法违背了可用性(可用性) では、CAP が CP を満たすことのみが必要です。

    ここに画像の説明を挿入します

    • AP: 以下の図に示すように、为了保证可用性パーティションが発生すると、N1 ノード上のデータは y に更新されますが、N1 と N2 の間のレプリケーション チャネルが中断されたため、データ y を N2 に同期できなくなります。 N2 ノード上のデータはまだ x です。这时客户端 C 访问 N2 时,N2 将当前自己拥有的数据 x 返回给客户端 C 了、実際には最新のデータはすでに y であり、これは不满足一致性(一貫性) の要件であるため、CAP の 3 つは AP のみを満たすことができます。注: ここで N2 ノードは x を返しますが、これは「正しい」結果ではなく「妥当な」結果です。これは、x は古いデータであり、不規則な値ではなく、最新のデータではないためです。

ここに画像の説明を挿入します

  • CAP 理論ではC 在实践中是不可能完美实现的、データ複製プロセス中、ノード N1 とノード N2 のデータは一致しません (強整合性)。これが不可能な場合でも强一致性、アプリケーションは適切な方法でそれを実現できます最终一致性次のような特徴があります。

    • 基本的に可用性: 分散システムで障害が発生した場合、部分的な可用性が失われることが許可されます。つまり、コアの可用性が保証されます。
    • ソフト状態: システム全体の可用性に影響を与えることなく、システムが中間状態に存在できるようにします。ここでの中間状態は、CAP 理論におけるデータの不整合です。
    • 最终一致性(Eventual Consistency):系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

2. データベースシャーディングアーキテクチャ

読み書きの分離の問題:

読み取りと書き込みを分離すると、データベースの読み取りと書き込み操作の負荷は分散されますが、ストレージの負荷は分散されません。ビジネス データ ストレージのニーズを満たすためには、これが必要です将存储分散到多台数据库服务器上

データシャーディング:

単一のデータベースに保存されているデータを複数のデータベースまたはテーブルに分散して、パフォーマンスのボトルネックと可用性を改善します。データ シャーディングの効果的な手段は、リレーショナル データベースを実行することです分库和分表データシャーディングの分割方法は に分かれます垂直分片和水平分片

2.1. 垂直シャーディング

垂直サブライブラリ:

按照业务拆分的方式称为垂直分片,又称为纵向拆分、その中心的な概念は特別なデータベースに特化しています。分割する前は、データベースは複数のデータ テーブルで構成されており、各テーブルは異なるビジネスに対応していました。分割後、テーブルはビジネスに応じて分類され、異なるデータベースに分散されるため、異なるデータベースへの負担が分散されます。

ここに画像の説明を挿入します

次の図は、ビジネス ニーズに応じてユーザー テーブルと注文テーブルを異なるデータベースに垂直にシャーディングするソリューションを示しています。

ここに画像の説明を挿入します

垂直分割はデータ量とアクセスによって引き起こされる問題を軽減できますが、問題を解決することはできません。如果垂直拆分之后,表中的数据量依然超过单节点所能承载的阈值,则需要水平分片来进一步处理。

垂直テーブル:

垂直分表适合将表中某些不常用的列,或者是占了大量空间的列拆分出去。

出会い系 Web サイトだとします。ユーザーが他のユーザーをフィルタリングするとき、主に年齢と性別フィールドを使用してクエリを実行しますが、ニックネームと説明フィールドは主に表示に使用され、通常はビジネス クエリでは使用されません。説明自体は比較的長いため、これら 2 つのフィールドを別のテーブルに分割することができます。これにより、年齢と性別をクエリする際のパフォーマンスが向上します。

垂直テーブル シャーディングによってもたらされる複雑さは、主にテーブル操作の数の増加に反映されます。たとえば、以前は名前、年齢、性別、ニックネーム、説明を 1 つのクエリで取得できましたが、現在は 2 つのクエリ (名前、年齢、性別を取得するクエリと、ニックネームと説明を取得するクエリ) が必要になります。 。
ここに画像の説明を挿入します

水平分表适合表行数特别大的表,水平分表属于水平分片

2.2. 水平シャーディング

水平分片又称为横向拆分。垂直シャーディングと比較すると、ビジネス ロジックに従ってデータを分類するのではなく、特定のフィールド (またはいくつかのフィールド) および特定のルールに従ってデータを複数のライブラリまたはテーブルに分散します。各シャードにはデータの一部のみが含まれます。たとえば、次の図に示すように、主キー シャーディングによれば、偶数の主キーを持つレコードはデータベース 0 (またはテーブル) に配置され、奇数の主キーを持つレコードはデータベース 1 (またはテーブル) に配置されます。

ここに画像の説明を挿入します

单表进行切分后,是否将多个表分散在不同的数据库服务器中,可以根据实际的切分效果来确定。

  • **テーブルの水平分割:** 単一のテーブルが複数のテーブルに分割された後、新しいテーブルは同じデータベース サーバー内にある場合でも、パフォーマンスが大幅に向上する可能性があります。パフォーマンスがビジネス要件を満たすことができる場合は、その必要はありません。データベース サーバーも、結局のところ、ビジネス サブデータベースも非常に複雑になります。

  • **水平サブデータベース:** 1 つのテーブルが複数のテーブルに分割されていても、1 つのサーバーではパフォーマンス要件を満たせない場合は、複数のテーブルを異なるデータベース サーバーに分散する必要があります。

Alibaba Java 開発マニュアル:

[推奨事項] 単一テーブルの行数が 500 万を超える場合、または単一テーブルの容量が 2GB を超える場合にのみ、データベースとテーブルのシャーディングを実行することをお勧めします。

注: 3 年間で予想されるデータ量がこのレベルにまったく達しない場合は、请不要在创建表时就分库分表.

3. 読み取り/書き込み分離とデータシャーディングアーキテクチャ

次の図は、データ シャーディングが読み取り/書き込み分離とともに使用されている場合の、アプリケーションとデータベース クラスター間の複雑なトポロジ関係を示しています。
ここに画像の説明を挿入します

4. 実施方法

程序代码封装一般に、読み取りと書き込みの分離とデータ シャーディングを実装するには、と の2 つの具体的な方法があります中间件封装

4.1. プログラムコードのカプセル化

プログラム コードのカプセル化とは、コード内の 1 つを抽象化して、数据访问层(或中间层封装)読み取り操作と書き込み操作の分離とデータベース サーバー接続の管理を実現することを指します。

**基本的なアーキテクチャは次のとおりです。 **読み取りと書き込みの分離を例に挙げます。
ここに画像の説明を挿入します

4.2. ミドルウェアのカプセル化

独立一套系统出来ミドルウェアのカプセル化とは、読み取り操作と書き込み操作の分離とデータベース サーバー接続の管理を指します。業務サーバにとってミドルウェアへのアクセスとデータベースへのアクセスに違いはなく、業務サーバから見ればミドルウェアはデータベースサーバとなります。

**基本的なアーキテクチャは次のとおりです。 **読み取りと書き込みの分離を例に挙げます。

ここに画像の説明を挿入します

4.3. 一般的なソリューション

Apache ShardingSphere (プログラム レベルおよびミドルウェア レベル)

MyCat (データベースミドルウェア)

おすすめ

転載: blog.csdn.net/weixin_44816664/article/details/132791278