分散データサービスについてお話しましょう

ターゲット

データ ストレージ リソースは、システムの最も重要なコンポーネントです。特に分散分野では、データがすべてです。主な焦点は次の点にあります。

• 高可用性: ネットワークまたはシステムに障害が発生しても、システムは利用可能な状態を維持します。
• 高いスケーラビリティ: データ規模が増大しても、データストレージシステムは自動的にこの変化に適応できます。
• 高いパフォーマンス: データ規模やアクセス規模が大きくなっても、パフォーマンスに大きな影響はありません
• コストは、システム設計が合理的であることを反映している
• 安全で、さまざまなシステム障害や人的障害が発生してもデータが失われることはありません

マイグレーション

MySQL は、ACID トランザクションをサポートする OLTP リレーショナル データベースです。これはメインのストレージ システムであり、現在使用されているバージョンは 5.7 です。

MySQL 自体は分散システムではありません。サポートされるデータ レプリケーション テクノロジは、基本的にデータの災害復旧を目的としています。ただし、現在はマスター スレーブ レプリケーションを使用して読み取りと書き込みを分離し、単一のマシンへの読み取り負荷を軽減しています。

MySQL サービスが Alibaba Cloud でホストされている場合は、高可用性バージョン、数秒でのマスター/スレーブ切り替え、クラウド ディスクに基づくディスク拡張テクノロジを使用できます。読み取り専用ノードをすばやくコピーできるため、独自の MySQL を構築するときに発生する多くの問題を軽減できます。さらに、インデックス分析、SQL レビュー、スロー クエリ分析、動的拡張など、多くの追加機能も提供します。

クラウドホスト型 RDS は本質的には MySQL ですが、次のような多くの問題が発生する可能性があります。

• データ ストレージはシャーディングをサポートしておらず、シャーディングによって水平方向にのみ拡張できます。現在、アプリケーション層はシャーディング ルーティングをサポートしていません。シャーディングを実行しても、テーブルを分割するときに多くの問題が発生します。
• テーブル設計とインデックス設計が適切でない場合、大量の更新でマスタースレーブ遅延の問題が発生し、アプリケーション レベルから完全に解決することは困難です。
• Alibaba Cloud RDS は、ロード バランシングのマスターとスレーブの分離を 1 つだけサポートしているため、バックグラウンド アプリケーションとキュー アプリケーションは、360 Atlas の読み取り/書き込み分離サービスを使用します。これは現在単一ポイントであり、読み取りと書き込みのパフォーマンスにも影響します。
• MySQL アプリケーションの仕様はまだ確立されていません。たとえば、どのようなアプリケーションで MySQL を選択すべきでしょうか? MySQL は主にトランザクションに使用されます。トランザクションシナリオがない場合、他のデータベースを選択できますか?
• Alibaba Cloud は、1 つのテーブル内のレコード数が 500 万を超えると、パフォーマンスが大幅に低下すると公式に述べています。
• DDL 操作、特に大きなテーブルの場合、大幅な同期遅延が発生する可能性があります。

クラウドホスト型 RDS は基本的に ECS + クラウド ディスクに基づいて構築されており、データの増加、バックアップ、パフォーマンス、移行、アップグレード、読み取り専用インスタンス、ディスク容量、Binlog の遅延などが依然として影響します。

では将来はどうなるのでしょうか?実際、クラウドベンダーも Alibaba Cloud の PolarDB や PolarDB-X など、クラウドネイティブ データベースやクラウドネイティブ分散データの概念を模索し、提案しています。

クラウドネイティブ データベースは、コスト、パフォーマンス、オンライン ビジネスの拡張、データ セキュリティに重点を置いています。そのコアテクノロジーには、コンピューティングとストレージの分離、物理レプリケーション、Binlog 行レプリケーション モード、共有ストレージ デバイス、RDMA 高速ネットワーク プロトコルによるストレージ間の転送などがあります。同時に、PolarDB-X はパーティショニング モードをサポートしており、ライブラリとテーブルのシャーディングの問題を解決します。

これらの革新により、同期の遅延、バックアップ、コスト、データベースとテーブルのシャーディング、パフォーマンスなど、従来の MySQL の欠点が解決されました。

将来的には、コアデータベースをクラウドネイティブデータベースに移行して、コアビジネスの安定性と拡張性を確保することができます。 OLTP 以外の業務の場合は、他のデータベースを選択して MySQL アプリケーション仕様を策定し、MySQL を使用する業務モデル、正しいインデックス設計、容量計画、SQL 文の使用仕様などを明確にすることができます。

レディス

Redis は K/V データベースです。シングルスレッドのメモリ操作に基づいているため、パフォーマンスが非常に高くなります。さらに、文字列、ハッシュ、リスト、コレクションなどの豊富なデータ構造をサポートしており、幅広いアプリケーションシナリオを備えています。

AOF と RDB を通じてデータの永続性を確保し、レプリケーション テクノロジーを通じてデータをバックアップし、センチネルとパーティションを通じて高可用性と容量拡張をサポートし、LUA スクリプトを通じて複数のコマンドのトランザクション操作をサポートします。

Redis はスタンドアロン システムですが、レプリケーションとクラスタリングのテクノロジを通じて分散ストレージ システムと見なすこともできます。現在、West Fifth Street では広く使用されており、主に次の 3 種類のアプリケーションに分かれています。

• ユーザーポイント、記事数、その他の失われないデータなどのストレージ
• ユーザー記事リストデータなどのキャッシュは、キャッシュ侵入や雪崩などの問題を考慮する必要がある
• メッセージキューは現在、Kafkaなどの純粋なメッセージングシステムに徐々に置き換えられつつあります。

Alibaba Cloud が管理する Redis コミュニティ バージョン 5.0 サービス クラスター バージョン。

アプリケーション設計にはいくつかの問題があります。

• ストレージとキャッシュは一緒に使用され、分割できないため、容量の見積もりが不透明になります。
• キャッシュ更新メカニズムの標準や統合された Lib アプリケーション パッケージなど、アプリケーション モデルに関する適切な仕様は存在しません。

Alibaba Cloud Redis が提供するデプロイメント アーキテクチャにより、アプリケーション シナリオを適切に理解できます。

• スタンダードエディション - デュアルレプリカ: 信頼性の高いサービス、信頼性の高いデータ、比較的標準的な使用モード、ストレージサービスとキャッシュサービスの両方が利用可能
• クラスター バージョン: プロキシ モードとシャーディングにより、スケーラブルなクラスター モードを構築して、Redis 自体のシングル スレッドのボトルネックを解決し、大容量と高性能のビジネス ニーズを満たすことができます。さらに、レプリカ セットは主にリカバリに使用されるため、ストレージ シナリオに非常に適しており、同期遅延の問題はありません。
• 読み取り/書き込み分離アーキテクチャ: キャッシュ シナリオなど、同期の遅延が問題にならないシナリオでは、このモードを選択できます。容量が不足している場合は、クライアント側の一貫性のあるハッシュ技術を使用して複数の Redis インスタンスを拡張できます。

次に、Redis の使用仕様を決定し、ストレージとキャッシュのシナリオを分割し、統合された Lib パッケージに基づいてほとんどの問題を解決します。

エラスティックサーチ

Elasticseach は、ほぼリアルタイムの分散検索エンジンおよび分析エンジンです。

検索エンジンとしては、現在オープンソース分野でナンバー 1 のデータベースです。転置インデックスに基づいて強力な検索機能を備えているため、アプリケーションでもビッグデータ分野でも非常に汎用的な分析エンジンです。

ほぼリアルタイムとは、Elasticseach のアプリケーション シナリオを理解する必要があることを意味します。 ACID をサポートしていないため、OLTP データベースにすることはできませんが、使用圧力ははるかに小さくなります。ポリシー分析、バックグラウンド アプリケーション、リアルタイム クエリなど、幅広いシナリオに対応します。

分散アプリケーションとして、レプリカ セット メカニズムを通じて高可用性の問題を解決することで、単一マシン障害の問題を解決できますが、データが誤って削除された場合は、Elasticseach のスナップショット メカニズムなどのバックアップ メカニズムが依然として必要です。

レプリカ セットの同期は最終的に一貫性に達します。書き込みパフォーマンスに関しては、プライマリ ノードは書き込みが完了するとすぐにクライアントに書き込みを返すように構成することもできます。

容量のスケーラビリティに関しては、シャーディング メカニズムを使用して、データを異なるノード上の異なるシャードに分割し、水平方向の容量スケーリングの問題を解決できます。シャードを調整する場合は、インデックスを再作成する必要があります。

パフォーマンスの面では、クエリの負荷は複数のレプリカ セット ノードによって共有されます。また、専用のトランスポート ノードを使用して、データ ノードの負荷を共有し、シャード クエリやレプリカ クエリなどのルーティングおよびマージ アクションの結果を集約することもできます。

Elasticseach は ELK ソリューションの一部であり、Filebat、Kibana、Logstash などの多くのサービスも含まれています。ビッグデータの分野でも良い方向性です。

Elasticseach は、ELK 上に構築された 3 ノードのサービスです。スケールの問題により、シャーディング技術はほとんど使用されません。コアとなるのは、記事全体のテーブルとユーザー全体のテーブルです。

検索シナリオと分析シナリオを組み合わせて、複数の MySQL テーブルが Binlog+Canal+Kafka+Go サービスを通じて大きなワイド テーブルに集約されます。大きくて幅の広い表は主に記事情報用です。一方では検索シナリオを満たし、他方では戦略およびアプリケーションのシナリオを満たします。

現在、大きな幅広のテーブルには多くのアプリケーション モードがあります。フリー スキーマ モードに基づいて、クエリ モードは非常に柔軟です。サブスクリプションを通じてデータを同期すると、アプリケーション層の負担も軽減され、データの正確性が大幅に保証されます。

今後、Elasticseach の応用に向けて、一方では不均等なデータのシャーディングやクエリパフォーマンスの最適化といったパフォーマンスチューニングを強化するとともに、一方では再インデックスやエイリアスといった機能の探求など、Elasticseach を十分に理解するといった保守性の向上も必要となります。

国内のクラウドベンダーの中で、Elasticseach に大幅なアップグレードを行ったベンダーはありません。基本的に、Elasticseach サービスをクラウドでホストするだけです。

カクファ

Kakfa は分散型の高スループット メッセージ キューです。サブスクリプション/消費モデルは、ストレージ容量よりも高いパフォーマンスを追求します。ただし、ログ自体は再生機能を持ち、分散ストレージシステムとして捉えることもできます。

Kafka のコア機能には、分離、ピーク除去、キャッシュが含まれます。幅広い応用シナリオがあり、システムに欠かせないコンポーネントです。

分散システムであるため、高可用性と高スループットを確保するためのレプリケーションおよびパーティショニング メカニズムも備えています。セグメントを順次書き込むことで、非常に高い書き込みパフォーマンスが保証され、コンシューマ グループの概念に基づいて、コンシューマのスループット容量も水平に拡張できます。同時に、各ブローカーがクエリを担当できるため、スループットが向上します。

Kafka は、リーダー選出、負荷分散、メタ ストレージなど、Zookeeper に基づく多くの分散管理機能を提供します。

現在、Kafka の 3 ノード クラスターは ECS によって構築されており、ほぼ 1 年間稼働しています。このサービスは比較的安定しており、管理作業をほとんど必要とせずに保守可能です。多くのコア サービスではすでに Kafka キューが使用されており、元の Redis ベースのキューもできるだけ早く移行できます。

モンゴDB

MongoDB は、ACID トランザクションをサポートする分散データベースを目指す分散ドキュメント データベースです。ドキュメント指向であるため、モードは非常に柔軟で、構造は緩やかであり、使用シナリオは非常に標準化されています。 MySQL と比較すると、バイナリ ストレージ モードの圧縮率は非常に高く、ストレージ コストが大幅に削減されます。同時に、WiredTiger エンジンに基づいて、さまざまな種類のインデックスを作成でき、サブドキュメントでもインデックスを作成できるため、クエリのパフォーマンスが向上します。

MongoDB は、oplog テクノロジーを通じてレプリカ セットをサポートし、パーティションもサポートします。パーティション キーはカスタマイズできます。パーティションのため、mongos ルーティング サーバーと構成サーバーが追加されます。 mongos ルーティング サーバーは、構成サーバーにクエリを実行して、ノードとパーティションにサービスを送信します。

MongoDB は、一貫性とパフォーマンスの要件をクライアントに任せ、読み取りコンセンサス、書き込みコンセンサス、読み取り優先テクノロジを通じてさまざまな柔軟性を提供します。たとえば、強力な一貫性が必要な場合は、majority を使用します。データが失われないようにする必要がある場合は、ジャーナルを true に設定します。

MongoDB 4.0 と MongoDB 4.2 は、マルチドキュメント トランザクションをサポートし、それぞれレプリカ セットとパーティション ディメンションのトランザクション特性をサポートします。ただし、使用と理解が非常に複雑であり、分散システムで学習するのが最も難しい部分である可能性があります。

これは、トランザクションを意図的に使用する必要がないことを示しています。 MongoDB を適切にモデル化し、OLTP リレーショナル データを補完することで、パフォーマンス、コスト、高可用性、スケーラビリティの面で利点が得られます。実際、MySQL では、テーブル間トランザクションやステートメント間トランザクションはほとんど使用されない為、トランザクションについてあまり迷信的にならず、適切なアプリケーション シナリオを選択してください。

MongoDB はクエリに加えて、さまざまな集計操作もサポートしており、分析分野で幅広い使用シナリオを備えている点が Elasticsearch と非常に似ています。

現在、MongoDB の 3 ノード クラスターは ECS 自体によって構築されており、ストレージ規模が小さく、使用シナリオもほとんどありません。

MySQL や Elasticsearch と比較すると、MongoDB には、分析シナリオ、トランザクション要件が低いシナリオ、比較的データの増加が大きいシナリオ (プライベート メッセージ データなど)、比較的柔軟なビジネス モデルを持つシナリオ (さまざまな条件下でのクエリや集計操作など) など、幅広いアプリケーション シナリオがまだあります。

ただし、Elasticseach と同様に、すべての主要なクラウド ベンダーは、あまり最適化を行わずに、このサービスをクラウドでホストするだけです。