【データベース】分散型データベースの進化過程
前提条件
本稿では、分散型データベースの進化過程と、進化過程のソリューションについて説明します.具体的な実装手順はありません.
データベースの高可用性の発展過程
1、照会操作は比較的に多くて、キャッシュを利用して、データベースのリード圧力を緩和する2、ライト操作はデータベースのボトルネックになって、データベースの主従レプリケーションを利用して、コードの中でリードとライトの分離を行う3、ライトサーバーのダウンタイムを避けるために、ライト操作の異常をもたらして、主主レプリケーションを行う4、単台はシステムの圧力を支持する時、クラスタの拡張を行って、負荷の均衡を通じてクラスタの均一な分担圧力を完成する5、システムへのダウンタイムの影響を回避するためには、高可用性クラスタの構築が重要です.6、MySQLの単表は最大5000万をサポートし、容量を拡大するために、分庫分表が必要である
データベース高可用性ソリューション
1、キャッシュを追加し、データベースの検索操作を緩和する.キャッシュ方式は2種類あり、ローカルキャッシュ、分散キャッシュです.ローカルキャッシュは通常ehcacheを採用し、分散キャッシュには通常2つの選択があります.redisとmemcached、両者の違いについては「redisとmemcachedの違い」に移動してください.分散キャッシュとローカルキャッシュの選択については、主にビジネスの具体的な合意について説明します.ehcacheはローカルメモリを占有し、データ量が少なく、クエリーが頻繁で、システムメモリの占有に影響を与えない場合に採用でき、分散キャッシュよりも効率が高い.分散キャッシュは、データ量が大きい場合や、永続化に一定の要件がある場合に使用できます.もちろん最良の案はredis+ehcacheを2段階キャッシュにすることであり、推奨例「Spring+ehcache+redis 2段階キャッシュ–キャッシュ実戦編(1)」2、主従レプリケーション、読み書き分離主従レプリケーション、MySQLのbinlogログを利用して実現する.具体的なシナリオは『【開発段階】——MySQL構成主従同期、コード層の読み書き分離を実現する』コード層の実装シナリオには2種類あり、ブログで編集する際のJDBCの方法タイプを判断する.もう1つのスキームはspringのaop+注釈を利用して,注釈をブロックすることによって,どのデータベースを操作するかを判断する.一般的に編集する方法では、ライブラリを注釈し、クエリーする方法ではライブラリを注釈し、コードの作成は複雑ですが、コードの柔軟性が高いです.3、マスターレプリケーションは大まかにマスターレプリケーションと一致し、同じ時間binlogログを利用する.これにより、書き込み操作の高可用性が保証され、書き込みサーバのダウンタイム、システムへの影響を回避し、データベースの負荷を実現します.4、負荷等化クラスタの3つの実現方式Nginx、採用したHttpプロトコルLVS、ネットワーク依存が比較的に大きく、安定性が高いHaProxy、Http、TCPプロトコルをサポートし、しかも可視化監視ページの3つの詳細な比較がある『三大主流ソフトウェア負荷等化器対比(LVS VS Nginx VS Haproxy)』小編が採用した時HAProxy、MySQLの負荷等化を実現する.5、高可用性クラスタデータ冗長性は高可用性を実現し、小編はKeepalivedを採用して高可用性を実現する.6、ライブラリ分割テーブルの2つの分割方式は垂直に切断する:業務の次元によって、元の1つのライブラリまたはテーブルを複数のライブラリまたはテーブルに分割し、各ライブラリまたはテーブルは元の構造とは異なる.水平カット:スライスアルゴリズムに基づいて、1つのライブラリまたはテーブルを複数のライブラリまたはテーブルに分割し、各ライブラリまたはテーブルは元の構造を保持します.整理は3つの考え方1、クライアントのスライスに分けられる.は、アプリケーション層で直接実現するのに非常に一般的で、簡単な解決策であり、アプリケーション層で直接スライス規則を読み取り、その後、スライス規則を解析し、スライス規則に基づいて分割のルーティング論理を実現する.この案は業務に侵入するが、実現は比較的簡単で、迅速なオンラインに適しており、論理を切り分けるのは自分で開発するため、生産上の問題は比較的解決しやすい.しかし、これによりデータベースの接続が多くなり、アプリケーションサーバのノード数を考慮する必要があり、容量評価を事前に行う必要があり、開発者の能力に対する要求が高い.オープンソースフレームワークdbsplitは、このような方法を採用しています. カスタマイズJDBCプロトコルを通じて、カスタマイズJDBCプロトコルを通じて、業務層に対してJDBCと一致するインタフェースを提供し、開発者に業務開発に専念させ、分庫分表の実現に関心を持たず、分庫分表をJDBCの内部で実現させる.しかし,開発者はJDBCプロトコルを理解してこそ,ライブラリ分割論理を実現することができる.このスキームは、プロセスのクライアント・ライブラリ・ダイバーシティ・フレームワークSharding JDBCによって採用されています. カスタムORMフレームワークリレーショナル・データベースとオブジェクト向け言語の差のため、ORMフレームワークが広く使用されているため、カスタムORMフレームワークによってライブラリ・テーブルを実現する案がある.スライスルールをORMフレームワークに実装するか、ORMフレームワークがサポートする拡張メカニズムによって実現する.一般的には、MybatisプロファイルのSQLにテーブルインデックスのパラメータを追加することでスライスを実現するのが一般的です.
2、エージェントスライスはアプリケーション層とデータベース層にエージェント層を追加し、スライスのルーティング規則をエージェント層に配置し、エージェント層はJDBCと互換性のあるインタフェースをアプリケーション層に提供し、アプリケーション層の開発者はスライス規則に関心を持たず、業務ロジックの実現に関心を持つ必要がある.この方案は開発者に業務ロジックの実現に専念させ、ライブラリの表分けの操作を代理層に残す.不足点:エージェント層を増やし、ネットワーク伝送の負担を増大させ、エージェント層のメンテナンス、ハードウェアコストも必要です.常用エージェントスライス実装フレームワークには,CobarやMycatなどがある.3、取引をサポートする分布式データベースOceanBase、TiDBなどのデータベースは対外的に伸縮性のあるアーキテクチャを提供し、分布式取引のサポートを提供し、伸縮性と分布式取引の実現を分布式データベースの内部実現に包装し、使用者に対して透明である.分散型データベースを使用するには、技術の実現を盲目的に追求しないで、実際の状況を総合する必要があります.ライブラリ分割テーブルの弊害1、id一意性をどのように保証するか2、マルチデータソース3の構成、分散ロックの問題4、分散トランザクションの問題はもちろんこれらの問題はいずれも解決の方法があるが、物事の両面性を説明している.編集長の会社はMyCatミドルウェアを採用していますが、分庫表の部分については編集長が後続のブログで更新し続けます!
まとめ
分布式についてはデブを一口で食べないで、業務、データに対して、実際の状況を具体的に分析して、原則は兵が水を遮って土を隠すことで、問題は結局解決策があると信じています.
本稿では、分散型データベースの進化過程と、進化過程のソリューションについて説明します.具体的な実装手順はありません.
データベースの高可用性の発展過程
1、照会操作は比較的に多くて、キャッシュを利用して、データベースのリード圧力を緩和する2、ライト操作はデータベースのボトルネックになって、データベースの主従レプリケーションを利用して、コードの中でリードとライトの分離を行う3、ライトサーバーのダウンタイムを避けるために、ライト操作の異常をもたらして、主主レプリケーションを行う4、単台はシステムの圧力を支持する時、クラスタの拡張を行って、負荷の均衡を通じてクラスタの均一な分担圧力を完成する5、システムへのダウンタイムの影響を回避するためには、高可用性クラスタの構築が重要です.6、MySQLの単表は最大5000万をサポートし、容量を拡大するために、分庫分表が必要である
データベース高可用性ソリューション
1、キャッシュを追加し、データベースの検索操作を緩和する.キャッシュ方式は2種類あり、ローカルキャッシュ、分散キャッシュです.ローカルキャッシュは通常ehcacheを採用し、分散キャッシュには通常2つの選択があります.redisとmemcached、両者の違いについては「redisとmemcachedの違い」に移動してください.分散キャッシュとローカルキャッシュの選択については、主にビジネスの具体的な合意について説明します.ehcacheはローカルメモリを占有し、データ量が少なく、クエリーが頻繁で、システムメモリの占有に影響を与えない場合に採用でき、分散キャッシュよりも効率が高い.分散キャッシュは、データ量が大きい場合や、永続化に一定の要件がある場合に使用できます.もちろん最良の案はredis+ehcacheを2段階キャッシュにすることであり、推奨例「Spring+ehcache+redis 2段階キャッシュ–キャッシュ実戦編(1)」2、主従レプリケーション、読み書き分離主従レプリケーション、MySQLのbinlogログを利用して実現する.具体的なシナリオは『【開発段階】——MySQL構成主従同期、コード層の読み書き分離を実現する』コード層の実装シナリオには2種類あり、ブログで編集する際のJDBCの方法タイプを判断する.もう1つのスキームはspringのaop+注釈を利用して,注釈をブロックすることによって,どのデータベースを操作するかを判断する.一般的に編集する方法では、ライブラリを注釈し、クエリーする方法ではライブラリを注釈し、コードの作成は複雑ですが、コードの柔軟性が高いです.3、マスターレプリケーションは大まかにマスターレプリケーションと一致し、同じ時間binlogログを利用する.これにより、書き込み操作の高可用性が保証され、書き込みサーバのダウンタイム、システムへの影響を回避し、データベースの負荷を実現します.4、負荷等化クラスタの3つの実現方式Nginx、採用したHttpプロトコルLVS、ネットワーク依存が比較的に大きく、安定性が高いHaProxy、Http、TCPプロトコルをサポートし、しかも可視化監視ページの3つの詳細な比較がある『三大主流ソフトウェア負荷等化器対比(LVS VS Nginx VS Haproxy)』小編が採用した時HAProxy、MySQLの負荷等化を実現する.5、高可用性クラスタデータ冗長性は高可用性を実現し、小編はKeepalivedを採用して高可用性を実現する.6、ライブラリ分割テーブルの2つの分割方式は垂直に切断する:業務の次元によって、元の1つのライブラリまたはテーブルを複数のライブラリまたはテーブルに分割し、各ライブラリまたはテーブルは元の構造とは異なる.水平カット:スライスアルゴリズムに基づいて、1つのライブラリまたはテーブルを複数のライブラリまたはテーブルに分割し、各ライブラリまたはテーブルは元の構造を保持します.整理は3つの考え方1、クライアントのスライスに分けられる.
<select id="getUser" parameterType="java.util.Map" resultType="User">
select userId,username
from user_#{index}
where userId = #{userId}
select>2、エージェントスライスはアプリケーション層とデータベース層にエージェント層を追加し、スライスのルーティング規則をエージェント層に配置し、エージェント層はJDBCと互換性のあるインタフェースをアプリケーション層に提供し、アプリケーション層の開発者はスライス規則に関心を持たず、業務ロジックの実現に関心を持つ必要がある.この方案は開発者に業務ロジックの実現に専念させ、ライブラリの表分けの操作を代理層に残す.不足点:エージェント層を増やし、ネットワーク伝送の負担を増大させ、エージェント層のメンテナンス、ハードウェアコストも必要です.常用エージェントスライス実装フレームワークには,CobarやMycatなどがある.3、取引をサポートする分布式データベースOceanBase、TiDBなどのデータベースは対外的に伸縮性のあるアーキテクチャを提供し、分布式取引のサポートを提供し、伸縮性と分布式取引の実現を分布式データベースの内部実現に包装し、使用者に対して透明である.分散型データベースを使用するには、技術の実現を盲目的に追求しないで、実際の状況を総合する必要があります.ライブラリ分割テーブルの弊害1、id一意性をどのように保証するか2、マルチデータソース3の構成、分散ロックの問題4、分散トランザクションの問題はもちろんこれらの問題はいずれも解決の方法があるが、物事の両面性を説明している.編集長の会社はMyCatミドルウェアを採用していますが、分庫表の部分については編集長が後続のブログで更新し続けます!
まとめ
分布式についてはデブを一口で食べないで、業務、データに対して、実際の状況を具体的に分析して、原則は兵が水を遮って土を隠すことで、問題は結局解決策があると信じています.