先月の初めに、Perconaのブログでコンピューティングストレージのパフォーマンステストに関する記事を見ました（詳細については、記事の最後にあるリンクを参照してください）。そこに記載されている機能のいくつかが私の興味をそそったので、コンピューティングを拡張しましたストレージ関連のテクノロジーは、データベースシステムのコンピューティングとストレージが、パフォーマンスに影響を与えることなく、いくつかのボトルネックと問題点を多かれ少なかれ解決し、TCOを大幅に削減できる可能性があることを突然発見しました。そのような魔法の力はどのような特徴を持っていますか？
ここが重要なポイントです。後で記事で説明する内容について説明します。データベースシステムのライフサイクル管理で発生する可能性のあるボトルネックと問題点を見てみましょう。次に、コンピューティングストレージがこれらのボトルネックと問題点を体系的に解決する方法を紹介します。
PS：以下のコンテンツは、個人的な見解のみを表しています。さらに、私はMySQLに精通しているので、例としてMySQLInnoDBエンジンのいくつかの典型的な問題点を簡単にリストします。
1.データベースシステムの典型的なボトルネックと問題点は何ですか？
データベースパフォーマンスの2つの重要な指標:(待ち時間）と並列トランザクション数（tps）2つは互いに補完し合い、反比例します。トランザクションの待ち時間が短いほど、許容されるtpsは高くなります。逆に、トランザクションの待ち時間が長くなると、許容tpsが低くなります。tpsが高いほどパフォーマンスが向上し、その逆も同様です。パフォーマンスは低下します。データベースはIOの応答遅延に非常に敏感であり、これはトランザクションの応答遅延に直接影響し、トランザクションの応答遅延がデータベースのtpsを大きく決定します。したがって、MySQLデータベースが妥当なハードウェア仕様のサーバーで実行され、MySQLインデックスが比較的標準化されているシナリオでは、最初のボトルネックがIOサブシステムであることがよくわかります。
これらの2つの主要な指標に焦点を当てて、ボトルネックと問題点が発生する可能性のある4つの典型的なシナリオを次のようにリストしました。
1.1。単一のデータベースサーバーのストレージ容量が不十分です
不十分なストレージ容量
従来のソリューション
*時間が押されると、ファイルを頻繁に削除してスペースを解放し、一時的に問題を解決できます。
*予算が十分な場合は、大容量のストレージデバイスを交換して完全なデータ移行を行うことができます
*予算と時間が十分な場合は、データ分割用にサーバーを追加できます
ストレージの負荷が高すぎる（スループットが高すぎる）
従来のソリューション：
*時間が厳しい場合は、ストレージスループットを最も消費するプロセスを強制終了することで一時的に解決できます
*予算が十分にある場合は、ストレージデバイスをより高いスループット帯域幅に交換し、完全なデータ移行を実行します
*予算と時間が十分な場合は、データ分割用にサーバーを追加できます
短所：
一時的な解決策は、ストレージの負荷状態に頻繁に注意を払う必要があり、多くの場合、一方と他方を無視します
部品の交換には追加のコストが必要です。データ分割により、ビジネスの複雑さとメンテナンスコストが増加し、いくつかの新しい問題も発生します（「1.4。同時クエリの数が多すぎるとデータベースインスタンスの負荷が高くなる」を参照） ）に記載されている欠点
1.2。データベースサーバーのメモリが不足しています
従来のソリューション：
不要なテーブルデータを一時的にクリーンアップするか、さまざまなキャッシュ割り当てでMySQLのパラメータ値を減らして、より多くのメモリを解放し、MySQLServerがより多くのことを実行できるようにします
物理メモリを増やし、MySQLのさまざまなバッファ割り当てパラメータの値を増やします
短所：
一時的な解決策は、メモリ使用量と頻繁な操作に継続的な注意を払う必要があります。さらに、これは西壁を補うために東壁を掘る慣行です。
コストの増加に加えて、物理メモリの増加もビジネスに一定の影響を及ぼします（サーバーをシャットダウンする必要があります）
1.3。単一のトランザクションが大きすぎるため、クエリのパフォーマンスが低下します
従来のソリューション：大きなトランザクションを小さなトランザクションに分割する
分割できない大規模なトランザクションの場合、同じハードウェア仕様を前提として、読み取りトランザクションと書き込みトランザクションを別々に最適化できます。次に例を示します。書き込みでは、実行前にセッションレベルでbinlog形式をステートメントに変更して、マスターインスタンスとスレーブインスタンス間で送信されるbinlogの量を減らすことができます。読み取りトランザクションを読み取り専用のスレーブライブラリに分割して、マスターライブラリのアクセス圧力を減らすことができます。
短所：
大きなトランザクションを小さなトランザクションに分割しても、元の大きなトランザクションで完了する必要のある作業タスクの数は減りませんが、小さなトランザクションに分割した後は、他の並列トランザクションへの影響が減ります（たとえば、大きなトランザクションには長い時間がかかる場合があります）。ロックの保持、バイナリログファイルハンドルリソースなどにより、他の並列トランザクションが長期間ブロックされ、並列トランザクションの実行が失敗します）
1.4。同時クエリの数が多すぎると、データベースインスタンスに過度の負荷がかかります
従来のソリューション：
高負荷のクエリセッションを強制終了し、その後、低速のクエリを最適化します
読み取りと書き込みの分離、読み取り専用スレーブライブラリの増加、読み取り専用機能の拡張
データ分割、複数のデータベースインスタンスへのデータの分散、読み取り/書き込み機能の拡張。
*大きなテーブルのデータを分割するには、最初に垂直分割を実行し（ビジネス分割によって、さまざまなビジネスのフィールドをさまざまなテーブル、さまざまなデータベース、またはさまざまなインスタンスに分割します）、次に水平分割を実行します（フィールドを分割し続けることができないテーブルの場合、データ量がパフォーマンスに影響を与えるほど大きい場合は、1000W行以下のデータの標準で大きなテーブルを分割し続ける必要がある場合があります。これはしばしばデータ断片化と呼ばれます）
短所：垂直分割と水平分割の両方を対応する変換で適用する必要があります。さらに、データ分割後、次のような新しい問題点が導入されます（これらの問題点は技術的な変換によって解決できますが、コストが高すぎます、また、安定させるには慣らし運転に時間がかかります。さらに、ビジネスを深く理解する必要がある場合があります。顧客ごとに異なる変換を行う必要がある場合があります）：クロスシャードアクセス。その結果、分散トランザクションを有効にする必要があります。クロスシャードアクセスのデータの一貫性を確保するため、および分散トランザクション自体には実装するためのある程度のエンジニアリングがあり、アプリケーション自体も変更する必要があります
シャードが異なるインスタンスにまたがる場合、データのグローバルな一貫性のあるバックアップを実現できません。インスタンス間の複数のデータシャードにわたってグローバルなデータの一貫性のあるバックアップを実現するには、ミドルウェアとデータベースにいくつかの変換が必要です。
トランザクション制御下にないDDLステートメントは、分散トランザクションを通じてデータのグローバルな一貫性を保証できません。したがって、データのグローバルな一貫性を保証するには、追加のメカニズムが必要です。
シャードデータが歪んでいる場合、またはアクセス負荷が歪んでいる場合は、シャードデータを頻繁に移行する必要がある場合もあります（データ量の多いシャードと高負荷インスタンスのシャードを比較的アイドル状態のインスタンスに移行します）。
2.コンピューティングストレージは、データベースのボトルネックと問題点をどのように解決しますか？
計算ストレージについては、私がより重要だと思う3つの機能をリストします。最初に、それらの原則を簡単に紹介し（関連する原則の詳細な紹介については、記事の最後にあるリンクを参照してください）、次にこれらの機能が上記のデータベースをどのように解決するかについて説明します。ボトルネックと問題点
最初の重要な機能：ストレージはハードウェアレベルのアトミック書き込みをサポートします
データベースにアトミック書き込みが必要なのはなぜですか？
※InnoDBデータファイルのデフォルトページサイズは16k、ファイルシステムのデフォルトブロックサイズは4kです。つまり、InnoDBデータファイルの最小IO操作単位は16k、ファイルシステムの最小IO操作単位は4kです。InnoDBデータファイルを書き込む場合16kページがファイルシステムに送信されると、ファイルシステムはそれを4つの4kブロックに分解してから、それらをストレージデバイスに書き込む必要があります。ほとんどのファイルシステムはアトミック書き込みをサポートしていないため、ストレージデバイスへのファイルシステムの書き込み中に事故（電源障害など）が発生すると、InnoDBのページサイズが部分的に書き込まれる（破損する）可能性があり、それによってMySQLサーバーが失敗する可能性があります通常のスタート
*この問題を回避するために、InnoDBはダブルライト機能を導入しました。ダブルライトは何に使用されますか？データファイルへの書き込み（つまり、フラッシュ）が必要なデータがある場合は、最初にdoublewriteに書き込みます（MySQL 8.0.20より前では、doublewriteは共有テーブルスペースibdata1にあります。バージョン8.0.20以降、独立したファイルストレージを使用し、複数をサポートします。ファイルですが、ファイルの最大数はバッファプールインスタンスの2倍です。つまり、各バッファプールインスタンスには2つのダブルライトファイルがあります）、1MBが連続して書き込まれるたびに、ダブルライトが成功した後にデータページが書き込まれ、次にデータページが書き込まれます。このように、事故によりデータページが破損した場合、データベースのクラッシュリカバリ中に、ダブルライトから破損したページを見つけて上書きして修復しようとします。修復後、MySQLサーバーは正常に起動できます（注：Redoはデータ回復をサポートできますが、完全なデータページではなく、データページの増分変更コンテンツを記録しますが、ダブルライトのデータページは完全であるため、ダブルライトで完全なデータページを使用できます。破損したデータページを復元すると、通常どおりREDOを適用できます）
*ダブルライトは2つの部分に分かれています。メモリに2Mのダブルライトバッファがあり、ディスクファイルにも2つの1Mの連続ダブルライトスペースがあります。ダブルライトの導入後のデータ書き込みの簡単な図は次のとおりです。図から、ダーティデータが成功する必要があることがわかります。データファイルに書き込むには、ディスクに2回書き込む必要があります（1回はダブルライト、もう1回はデータファイル）。
コンピューティングストレージはアトミック書き込みをサポートしています。データベースの利点は何ですか？
*ストレージはハードウェアレベルのアトミック書き込みをサポートしているため、つまり、データベースレベルでの二重書き込み機能をオフにすることができます。オフにした後、データファイルに書き込まれるダーティデータはディスクに1回書き込むだけで済み、半分を節約できます。ブラシの汚れた流れ。つまり、データページが部分的に書き込まれないようにする場合、不十分なストレージスループットの緊急の必要性を直接軽減できます。
2番目の重要な機能：透過的なデータの圧縮/解凍
データベースを圧縮/解凍する必要があるのはなぜですか？
*簡単に言うと、データ量が一定のレベルに達すると、ストレージコストが大幅に節約され、ストレージのTCOが削減されます。
データ透過圧縮/解凍とは何ですか？いくつかの現在の主流の圧縮/解凍方法の観点から理解し始めることができます
*ソフト圧縮/解凍（つまりCPU圧縮）：次の図に示すように、圧縮および解凍操作を実行するのはホストCPUに依存しているため、大量のデータ複製があり、複製リンクが長く、圧縮および解凍操作ロジックをアプリケーションプログラムで実装および制御する必要があります。
*ハードウェアの圧縮/解凍（圧縮カード）：下図に示すように、圧縮および解凍操作は、PCIスロットを占有する専用の圧縮カードによって実行されます。ホストCPUリソースは解放されますが、ホストメモリと圧縮カードの間で大量のコピーが必要です。データは、多くのホスト帯域幅リソースを占有します
*透過的な圧縮/解凍：下図に示すように、圧縮/解凍の計算作業は、アプリケーションに対して完全に透過的なメモリカードに統合されたコンピューティングユニットによって直接実行されます。データの圧縮と解凍は完全にディスクで実行され、ホストのCPUリソースを解放します。同時に、ホスト帯域幅リソースも解放され、ホストメモリと圧縮カード間で大量のデータをコピーする必要がありません（ゼロコピー）。また、メモリカードを拡張すると、圧縮/解凍コンピューティングユニットを同時に拡張できるため、並列化が可能です。圧縮/解凍操作
コンピューティングストレージは透過的な圧縮/解凍をサポートしています。データベースの利点は何ですか？
*アプリケーションに対して透過的であり、ホストのリソースを占有しないことを前提として、ストレージコストを大幅に削減します
※メモリカードのストレージユニットでは、保存データが圧縮されているため、保存データ量が大幅に削減されます。ソリッドステートストレージコンポーネントの場合、書き込み増幅が大幅に削減され、書き込み増幅の削減が可能になります。ソリッドステートストレージコンポーネントのパフォーマンス上の利点を最大化し、IO応答の遅延を減らします。したがって、データベースの場合、データ圧縮を実装すると、パフォーマンスに影響を与えることはなく、パフォーマンスを向上させることもできます（特に、MySQLデータベースでは、データボリュームが特定のサイズに達した後、圧縮率が高くなるにつれて、コンピューティングストレージの透過的な圧縮+厳密な二重書き込み、一部のシナリオではパフォーマンスを大幅に向上させることもできます）
*圧縮機能は、binlogが占める物理スペースを削減するため、ストレージスペースが不足しているためにbinlogをクリーニングする頻度も削減します。同時に、圧縮/解凍機能はディスク上で実行されるため（データを書き込むときは、最初にディスク内の計算要素によって実行されます）。圧縮されてからストレージユニットに保存されます。最初にストレージユニットから読み取られ、次にディスク内のコンピューティングユニットによって解凍されます）。これにより、ストレージデバイスの帯域幅の占有がさらに削減されます。
* InnoDBのバッファプールは主にIO操作を減らすために使用されます。読み取りおよび書き込みIO応答遅延の削減は、ホストメモリへの依存も削減されることを意味します。つまり、InnoDBのバッファプールを小さく設定でき、言い換えると、ホストのメモリリソースをさらに解放して、ユーザー接続要求を処理するためにより多く使用することができます。
3番目の重要な機能：計算をストレージにプッシュダウンします（もちろん、ビジネスごとにプッシュダウンする必要のある計算ロジックは異なる場合があるため、一般的でない計算ロジックのプッシュダウンには共同の研究開発が必要になる場合があります）
データベースが計算をストレージにプッシュする必要があるのはなぜですか？
*実稼働環境での実際のクエリタイプ、同等ではないクエリ（非一意のインデックスクエリ、結合テーブルクエリなど）は、比較的高い割合を占めることが多く、これらのクエリ（特にクエリ条件に複数の列が含まれる場合）はMySQLとは異なります。 ICP機能のサポートにより、ストレージエンジンから読み取られるデータの量は、実際に必要なデータの量を超えることがよくあります（たとえば、すべてのクエリ条件を満たすデータは10行しかない場合がありますが、ストレージエンジンから実際に読み取られるデータの量は100行です）。これは、MySQLがクエリを実行すると、条件列を選択してストレージエンジンでデータを取得し、取得したデータをMySQL Serverに返し、残りの条件列を使用してデータをフィルタリングするためです。その後、すべての条件を満たすデータがクライアントに返されます。このプロセスでは、フィルタリングされたデータは実際には無駄です。MySQLICPと同様の機能を使用する場合、すべての条件列をストレージエンジン層にプッシュし、すべての条件列を満たすデータを直接返すことができます。すべての条件を満たすわけではないデータを読み取る必要はありません。
* MySQL ICPの特性により、ストレージエンジンからの不要なデータの読み取りを回避できますが、ストレージエンジン層のフィルタリング計算では、ホストCPUリソースを消費する必要があります。計算量をストレージデバイスにさらにプッシュダウンできますか？できる！
ストレージへのコンピューティングプッシュダウンとは何ですか？次の3つの図は、ストレージへのプッシュダウンを計算する実装ロジックを簡単に説明しています。
*複数の条件付き列を持つクエリを想定しています（注：複数の条件付き列はインデックス列であると想定されているため、以下では繰り返しません）。MySQLICP機能がサポートされていない場合、クエリの実行プロセスはおおよそ次のようになります（注：赤いフォント、以下の詳細には立ち入らないでください）。クエリが複数列のインデックスを使用できると仮定すると、インデックスシーケンスの最初の列がデータ取得（列の取得）に使用され、データがストレージエンジンから取得され、残りの条件付き列（列のフィルタリング）がMySQLServerレイヤーで使用されます。すべての条件を満たすデータを除外する
*上記のクエリがMySQLICPと同様の機能でサポートされている場合、クエリはストレージエンジンからのすべての条件を満たさないデータの読み取りを回避できます。次の図に示すように、すべての条件列（インデックス列である必要があります）がダウンロードされます。ストレージエンジンレイヤーにプッシュし、すべての条件付き列に一致するデータのみを読み取ります。MySQLサーバーレイヤーでデータフィルタリングを行う必要はありません。
*ストレージデバイスへのプッシュダウンの計算とは、次の図に示すように、MySQL ICPと同様の特性をさらに最適化し、計算ロジックをストレージデバイスにプッシュダウンし、ホストCPUリソースとホスト帯域幅リソースをさらに解放することを意味します。
コンピューティングストレージのサポートにより、計算がストレージデバイスにまで押し下げられます。データベースのメリットは何ですか。
*上記の紹介を通して、MySQLICPのような計算をストレージデバイスにプッシュダウンすることの利点は何であるかを言う必要はないと思います！より多くのコンピューティングロジックをストレージデバイスにプッシュダウンできる場合、必然的にホストのCPU、帯域幅、さらにはメモリリソースがさらに解放されるため、ホストのリソースを使用してユーザーのビジネス要求を受け入れて処理することができます。データベースのパフォーマンスをさらに向上させます！
3.コンピューティングストレージの将来の見通し
コンピューティングとストレージの多くの優れた機能により、時間と労力とコストがかかり、他のデータベースを失うことが多い従来の方法の代わりに、一度に複数のデータベースのボトルネックと問題点を体系的に軽減および解決することができます。
すべての道がローマに通じていますが、解決できない技術的な問題はありません。ストレージを計算しないと、他にもさまざまな解決策がありますが、それがどのように解決されるかを確認する必要もあります。より近い道がある場合は、なぜあなたは遠くにいたいのですか？
個人的には、コンピューティングストレージはデータベース分野での将来を見据えた開発の方向性であると考えています。もちろん、コンピューティングストレージを完全に使用できるという意味ではありませんが、少なくとも、データ量がコンピューティングストレージでサポートできないレベルに達していない場合は、さらに多くのことができます。上記のボトルネックと問題点のいくつかを回避または遅延させます。さらに、もう1つの重要なポイントがあります。単一サーバーのTCOコストを削減するのは苦痛ではないかもしれませんが、サーバーの規模が大きい場合、コスト削減を過小評価することはできません。
将来的には、どのようなコンピューティングストレージに発展するのか、神様は知っていますが、最下層からの技術革新は、アプリケーション層では使いにくい技術変革よりも費用対効果が高いと思いますので、強い要望がある限りは、ブレークスルーを続けていく勇敢な男がいるに違いない！
PS：上記のコンテンツは、いくつかの公開された記事に基づいて編集されています（詳細については、記事の最後にあるリンクを参照してください）。詳細を知る必要がある読者は、記事の最後にある参照リンクを参照してください。詳細な手順と完全なパフォーマンスが含まれています。データをテストします。この記事がデータベースへの旅に多かれ少なかれ役立つことを願っています。
4.参照リンク
PerconaブログでのScaleFluxCSD 2000（ScaleFluxの高性能コンピューティングストレージ製品）の紹介：https：//www.percona.com/blog/2020/08/06/how-can-scaleflux-handle-mysql-ワークロード/テクニカルホワイトペーパー（CSD 2000テストの結論とデータの詳細を含む）：https：//learn.percona.com/hubfs/Collateral/Whitepapers/Testing-the-Value-of-ScaleFlux.pdf
WeChatパブリックアカウント「yangyidba」の「翻訳| ScaleFluxSSDパフォーマンステストに基づくMySQL」：https：//mp.weixin.qq.com/s/MNBNKlxiBBXGSOyzm5HGdQ
WeChatパブリックアカウント「LaoyeTeahouse」の「コンピュータストレージ：データ圧縮とデータベース計算のプッシュダウン」：https：//mp.weixin.qq.com/s/iAg64XNrrZxRCLdlRJjFCQ
WeChatパブリックアカウント「ScaleFlux」の「コンピュータストレージ：透過圧縮、データベースIOモデル、SSDライフタイム」：https：//mp.weixin.qq.com/s/jh4JzyXSGhxldT01paCPvw
WeChatパブリックアカウント「SSDFans」の「強力すぎる！NVMe SSDがメモリになりました」：https：//mp.weixin.qq.com/s/niZmq170l4HDnfyw0rmRFg
MariaDBでの自動アトミック書き込みの実現の概要：https：//mariadb.com/kb/en/atomic-write-support/
-
https://mariadb.com/kb/en/mariadb-1055-changelog/
著者について：
Luo Xiaobo @ ScaleFlux、「千の黄金のレシピ-MySQLパフォーマンス最適化ピラミッド」の著者の1人。
MySQLアーキテクチャに精通し、オープンソーステクノロジーに特化するなど、データベース全体のチューニングに精通し、オープンソーステクノロジーの推進に熱心であり、オンラインおよびオフラインで多くのパブリックデータベーストピック共有を行い、100近くのデータベース関連の研究記事を公開しています。
全文は終わりました。
TeacherYeの「MySQLCoreOptimization」クラスがMySQL8.0にアップグレードされました。コードをスキャンして、MySQL8.0の練習の旅を始めてください。