1.最初に書く
vivoクラウドサービスは、連絡先、テキストメッセージ、メモ、ブックマークなどのデータを携帯電話にバックアップする機能をユーザーに提供します。基盤となるストレージは、データストレージにMySQLデータベースを使用します。
生体内クラウドサービス事業の発展に伴い、クラウドサービス利用者数は急増し、クラウドに保存されるデータ量はますます大きくなり、大量のデータがバックエンドストレージに大きな課題をもたらしています。近年のクラウドサービス事業の最大の課題は、ユーザーの大量のデータを保存するという問題をどのように解決するかです。
2.直面する課題
2017年から2018年まで、クラウドサービス製品の主要な指標はユーザー数の増加に焦点を合わせていました。クラウドサービスは、製品戦略に大幅な調整を加えました。ユーザーがvivoアカウントにログインすると、クラウドサービスのデータ同期スイッチがデフォルトでオンになります。
この製品戦略により、クラウドサービスユーザーの数は爆発的に増加しました。ユーザー数は100万人から数千万人に直接急増し、バックエンドに保存されるデータの量も数百億から数千億に跳ね上がりました。
大規模なデータストレージの問題を解決するために、クラウドサービスは、サブデータベースサブテーブルの4つの戦略、水平サブテーブル、垂直サブテーブル、水平サブデータベース、および垂直サブデータベースを実装しました。
1.レベルスコアテーブル
とげの道1：ブラウザのブックマーク、メモリストライブラリ、および単一のテーブルで単一のテーブルのデータ量が1億を超える場合は、どうすればよいですか？
サブデータベースとサブテーブルの知識システムを理解している兄弟は、すぐに答えられるようになると思います。1つのテーブルのデータ量が多すぎると、テーブルが分割されます。同じことを行い、ブラウザのブックマークとメモモジュールの単一のテーブルを100個のテーブルに分割しました。
ブラウザのブックマークとノートシートの10億レベルのデータ量を、それぞれが1000Wのデータ量を運ぶ100個のサブテーブルに 移行し ます。
これは誰もがよく知っている最初の攻撃です：レベルスコアテーブル。
2.水平サブライブラリ
とげの道2：連絡先とSMSデータはテーブルに分割されましたが、最初は50のテーブルのみが分割され、データベースは分割されませんでした。ユーザー数が急増した後、1つのデータベースの連絡先データの合計量は数十億に達し、1つのテーブルのデータ量は5000Wに達しました。継続的な増加は、mysqlのパフォーマンスに深刻な影響を及ぼします。どうすればよいですか。
2番目のトリックは、ライブラリを水平方向に分割することです。1つのライブラリでサポートできない場合は、さらにいくつかのライブラリに分割します。私たちは10個のデータベースに、元の単一のデータベースを分割し、100個のテーブルに連絡先やテキストメッセージの50個のテーブルから元の単一のデータベースを拡大した。同じ期間に、移行および保存されたデータの十億の再ルーティングは非常に苦痛でした。
3.垂直サブライブラリ、垂直サブテーブル
とげの道3：最初は、クラウドサービスの各モジュールのデータストレージはすべて一緒に混合されています。
スペースにボトルネックがある場合、各モジュールデータのストレージスペースの分布を分析しました。状況は次のとおりです。
単一ライブラリディスク容量がある5T、連絡先データが占めるの2.75T（55％）の記憶スペースを、SMSデータが占めるの1T（20％）の記憶スペースを、他のすべてのモジュールデータは、総占有の500G（5％）の記憶スペースを、そして残りの空き容量が1Tである。お人とSMSデータは総スペースの75％を占めます。
残りの1Tのスペース容量は、ユーザーデータの継続的な増加をサポートできず、状況は楽観的ではありません。スペースが足りない場合、スペースの問題ですべてのモジュールが利用できなくなります。どうすればよいですか？
（下図は、当時のクラウドサービスのデータストレージスペースの分布を示しています）
3番目と4番目の軸、垂直サブデータベースと垂直サブテーブル：連絡先データ、SMSデータ、その他のモジュールデータを保存および分離します。連絡先データとSMSデータをライブラリに分割します。
これまでのところ、クラウドサービスは、サブデータベースとサブテーブルの4つのトリックすべてを実践してきました。データを分割し、分割を分割する必要があります。
4.ルーティングテーブルに基づく動的拡張スキーム
とげの道4：上記の説明から、分割連絡先データベースは固定の10データベースサブデータベース戦略を採用していることがわかります。10データベース* 100テーブルの予備評価は、ビジネスデータの増加のニーズを満たすことができます。連絡先データの増加率は予想を上回りました。
連絡先データベースが個別に分割されてから9か月後、1つのデータベースのストレージスペースが35％から65％に増加しました。この成長率によると、さらに6か月後、独立した連絡先データベースは再び不十分なスペースの問題に直面します。
の解き方？継続的な拡大は肯定的であり、核となるのはどの拡大戦略を採用するかです。従来の拡張計画を採用すると、コストがかかりすぎる大量のストックデータの移行と再ルーティングの問題に直面します。
技術チームによるコミュニケーションと話し合いの後、クラウドサービスの連絡先ビジネスの特性（古いユーザーの連絡先の数は基本的に安定しており、多数の連絡先が頻繁に追加されることはなく、古いユーザーの連絡先データの増加率は制御可能です）、最終的に、ルーティングテーブルに基づく動的拡張スキームを採用しました。
以下に、このプログラムの機能について説明します。
- ユーザールーティングテーブルを追加して、ユーザーの連絡先データがルーティングされるデータベースとテーブルを記録します。
- 新しいユーザーの連絡先データは、新しく拡張されたデータベースにルーティングされます。これにより、元の古いデータベースにデータストレージの負荷がかかることはありません。
- 古いユーザーのデータは移動されず、元のデータベースに保存されたままになります。
- このソリューションの機能は、元の古いデータベースが古いユーザーのデータ増加を保証するだけでよく、すべての新しいユーザーが新しく拡張されたデータベースによって運ばれるようにすることです。
古いユーザーの連絡先の増加率は制御可能ですが、元のライブラリは、古いユーザーのデータの増加をサポートするためにストレージスペースの60％を予約できると予想されます。現在、古いライブラリの利用可能なスペースの35％しか残っておらず、要件を満たしていません。
古いデータベースデータが占めるストレージスペースを削減するために、当然、データ圧縮レベルから始めることを考えました。
3.圧縮スキームに関する事前調査
クラウドサービスは、データベースデータ圧縮のための次の3つのソリューションについて事前調査を実施しました。
スキーム1：プログラムはそれ自体でデータ圧縮を実装し、圧縮後にデータベースに保存します
利点：
データベースを変更する必要はなく、変更はプログラム自体によって完全に収束され、圧縮が必要なフィールドは自由に制御できます。
短所：
既存のデータは、データ圧縮のために追加の圧縮タスクを開発する必要があり、既存のデータの量が多すぎ、プログラムによるデータ圧縮には時間がかかり、制御できません。
データが圧縮されてデータベースに保存されると、dbプラットフォームから直接実行する必要のあるselect queryフィールドのコンテンツが読み取れなくなり、その後のロケーションの問題が発生しにくくなります。
オプション2：MySQLデータベースInnoDBにはデータ圧縮機能が付属しています
利点：
上位レベルのプログラムを変更せずに、データ圧縮にInnoDBの既存の機能を使用し、後続の選択データクエリに影響を与えません。
短所：
これは、データ量が多く、読み取りと書き込みが少ないビジネスシナリオに適しており、高いクエリパフォーマンスを必要とするビジネスには適していません。
解決策3：InnoDBストレージエンジンをTokuDBに切り替え、TokuDBエンジンの自然なデータ圧縮機能を使用します
利点：
TokuDBは当然、データ圧縮をサポートし、複数の圧縮アルゴリズムをサポートし、頻繁なデータ書き込みシナリオをサポートし、大規模なデータストレージに自然な利点をもたらします。
短所：
MySQLはTokuDBエンジンをサポートするために追加のプラグインをインストールする必要があり、同社は現在TokuDBの成熟した使用経験を持つビジネスを持っておらず、アクセス後のリスクは不明であり、その後のDBAメンテナンスも課題です。
総合的に検討した結果、最終的に2番目の圧縮スキームであるInnoDB独自の圧縮機能を採用することを決定しました。
主な理由は次のとおりです。
- 簡単な操作： dbaによって既存のinnodbデータテーブルのファイル形式を変更してデータを圧縮します。
- 制御可能な圧縮速度：テスト後、2000Wのデータテーブルを使用して、1〜2日以内にテーブル全体を圧縮できます。
- 低変換コスト：変換プロセス全体では、dbaが関連するSQLを実行し、データテーブルのファイル形式を変更するだけで、上位のプログラムコードを変更する必要はありません。
- クラウドサービスのビジネスシナリオにより適しています：ユーザーデータのバックアップとリカバリは、高性能で高QPSのビジネスシナリオではなく、クラウドサービスのデータテーブルは、データ圧縮に非常に適した多数の文字列フィールドの特性にほぼ準拠しています。
第四に、圧縮スキームの検証
1.InnoDB圧縮機能の概要
MySQLバージョン5.1.38より前は、innodbベースのストレージエンジンしかありませんでした。デフォルトのファイル形式はAntelopeでした。このファイル形式は、COMPACTとREDUNDANTの2つの行形式（ROW_FORMAT）をサポートし、どちらもデータ圧縮タイプの行形式ではありません。
MySQL 5.1.38以降、innodb-pluginが導入され、Barracudeタイプのファイル形式も導入されました。Barracudeは、Antelopeのファイル形式と完全に互換性があり、他の2つの行形式DYNAMICおよびCOMPRESSED（データ圧縮をサポート）をサポートします。
2.圧縮環境の準備
データベース構成の変更：データベースのファイル形式を変更します。デフォルトはAntelopeで、Barracudaに変更されています。
SET GLOBAL innodb_file_format = Barracuda;
SET GLOBAL innodb_file_format_max = Barracuda;
SET GLOBAL innodb_file_per_table = 1
注：innodb_file_per_tableは1に設定する必要があります。その理由は、InnoDBシステムテーブルスペースを圧縮できないためです。システムテーブルスペースには、ユーザーデータだけでなく、圧縮できないInnoDBの内部システム情報も含まれているため、圧縮をサポートするには、テーブルごとに異なるテーブルスペースを設定する必要があります。
OKを設定した後、SHOW GLOBAL VARIABLES LIKE '％file_format％'およびSHOW GLOBAL VARIABLES LIKE '％file_per％'を実行して、変更が有効かどうかを確認できます。
（この設定は現在のセッションでのみ有効であり、mysqlインスタンスを再起動すると無効になります。永続的に有効にする必要がある場合は、mysqlグローバル構成ファイルで構成してください）
3.圧縮効果の検証をテストします
圧縮形式をサポートするデータテーブルと圧縮をサポートしないデータテーブルを準備します。フィールド形式はすべて同じです。
圧縮テーブル：
説明：row_format = compressed、指定された行フォーマットは圧縮されています。推奨されるkey_block_size = 8。key_block_sizeのデフォルトは16です。オプションの値16、8、4は、InnoDBデータページのサイズを表します。値が小さいほど、圧縮率が高くなります。CPUと圧縮率の包括的な考慮に基づいて、オンラインで推奨される設定は8です。
非圧縮テーブル：
データの準備：保存されたプロシージャを使用して、同じデータの10W個をt_nocompressテーブルとt_compressテーブルに同時に挿入します。2つのテーブルが占めるスペースは次のとおりです。
t_compressテーブルデータは10Mを占め、t_nocompressテーブルデータは20Mを占め、圧縮率は50％です。
注：圧縮効果はテーブルフィールドのタイプによって異なります。通常、データには繰り返し値があるため、効果的に圧縮できます。CHAR、VARCHAR、TEXT、BLOBなど。
文字列データは通常、適切に圧縮できます。ただし、バイナリデータ（整数または浮動小数点数）および圧縮データ（JPEGまたはPNG画像）は通常、圧縮を実現しません。
5、オンライン練習
上記のテスト検証から、圧縮率が50％に達すると、連絡先データベースが占めるスペースは65％から33％に圧縮され、残りのスペースの60％を達成できます。
ただし、オンラインデータに畏敬の念を抱く必要があります。オンラインで練習する前に、オフラインプランを確認する必要があります。同時に、次の問題も考慮する必要があります。
1.データの圧縮と解凍はdbサーバーのパフォーマンスに影響しますか？
パフォーマンスストレステストを使用して、圧縮前後のデータベースサーバーCPUへの影響を評価します。以下は、圧縮前後のdbサーバーのCPU比較チャートです。
連絡先リストのデータ量がすでに2000Wであることを前提として、このテーブルにデータが挿入されます。
圧縮前：一度に50個の接点を挿入し、同時に200個、10分、TPS 150、CPU 33％
圧縮後：一度に50個の接点を挿入、200個の同時、10分、TPS 140、CPU 43％
データテーブルが圧縮された後、データベースへの頻繁なデータ挿入のCPUは実際に増加しますが、TPSは大きな影響を受けません。ストレステストを繰り返した後、データベースサーバーのCPUは基本的に約40％で安定しており、これはビジネスに受け入れられます。
2.データテーブルファイルの形式を変更すると、ビジネスSQLの読み取りと書き込みに影響し、通常のビジネス機能に影響しますか？
私たちは主にオフライン検証とオンライン検証を行いました：
オフライン検証：テスト環境は、すべての連絡先データテーブルを圧縮形式に調整し、テストエンジニアが連絡先の全機能のチェックを支援するように手配し、最終的な機能はすべて正常でした。
起動前の環境は、再度テスト環境の手順に従い、機能チェックに異常はありません。
オンライン検証：圧縮するユーザーの影響を受けない通話記録モジュールのデータテーブルを選択し、1つのライブラリで1つのテーブルを圧縮することを選択し、このテーブルのデータの読み取りと書き込みの状況に注意し、ユーザーの苦情に注意します。
1週間の継続的な観察の後、この時計の通話記録データは正常に読み書きでき、この期間中にユーザーからの異常なフィードバックは受信されていません。
3.オンラインの連絡先データの量は膨大ですが、圧縮中にサービスの安定性を確保するにはどうすればよいですか？
私たちは主に次のアイデアに従ってトレードオフを行います。
- 圧縮する連絡先データテーブルを選択し、単一のテーブルに費やされた時間を評価します。
- 単一のデータベースを選択し、複数テーブルの同時圧縮を実行して、CPU使用率を観察します。DBAは、最大CPU値が55％を超えてはならないことを考慮し、この標準に基づいて同時圧縮の数を徐々に調整して、CPUが約55％で安定するようにし、最終的に、圧縮のために単一のデータベースでサポートされるテーブルの最大数を同時に取得します。
- 1番目と2番目の手順を組み合わせて、すべてのライブラリのすべてのデータテーブルを圧縮するのにかかるおおよその時間を計算できます。プロジェクトチームと関係者に同期した後、手順に従って圧縮作業を実装します。
最終的なオンライン連絡先データベースに対するデータ圧縮の影響は次のとおりです。
6、最後に書く
この記事では、ビジネスおよび大規模なデータストレージの開発に伴うクラウドサービスによってもたらされる課題と、参照を提供することを期待して、サブデータベースサブテーブル、データベースデータ圧縮におけるクラウドサービスの経験を紹介します。
InnoDB データ圧縮は、次のシナリオに適しています。
大量のビジネスデータとデータベースディスクのスペースプレッシャーがあるビジネス。
これは、読み取りと書き込みが少ないビジネスシナリオに適しており、パフォーマンスとQPSの要件が高いビジネスには適していません。
- これは、ビジネスデータテーブル構造内の多数の文字列タイプのデータに適しています。このタイプのデータテーブルは、通常、効果的に圧縮できます。
やっと：
ビジネス用のデータベースとテーブルを選択するときは、データ量の増加を完全に見積もる必要があります。その後のデータベース拡張によってもたらされるデータ移行作業は骨を傷つけます。
- オンラインデータに畏敬の念を抱き、ソリューションはオフライン検証を繰り返した後にのみオンラインで適用する必要があります。
著者：製品開発チームのためのvivoプラットフォーム