Lindorm は、アクセス頻度の低い履歴データをコールドデータとして識別し、容量ストレージを使用してデータを保存することでストレージコストを削減します。このトピックでは、容量ストレージの利点と、この機能のサンプル パフォーマンス テスト結果について説明します。
機能
容量ストレージは費用対効果が高いです。
容量ストレージのコストは、標準ストレージのコストの 20% です。
容量ストレージはデータ書き込み操作をサポートし、あらゆる時点のデータを読み取ることができるようにします。
容量ストレージは使いやすくなっています。
容量ストレージを使用してコールドデータを保存するには、Lindorm インスタンスを購入する際に、[容量ストレージを購入する] を [はい] に設定し、[容量ストレージ] に値を指定します。次に、CREATE TABLE ステートメントを使用してテーブルを作成する際に、コールドデータが容量ストレージに保存されるように指定します。
容量ストレージを使用して、単一のテーブル内でホットデータとコールドデータを分離できます。
テーブルのホットデータとコールドデータの分離機能を有効にすると、Lindorm はアクセス頻度の高いデータを、データの読み取りと書き込みのパフォーマンスが高いホットストレージに保存し、アクセス頻度の低い履歴データを容量ストレージに保存してストレージ コストを削減します。ビジネスのホットデータとコールドデータを個別に保存する方法については、概要 をご参照ください。
容量ストレージを有効にする
Lindorm インスタンスの容量ストレージを有効にする方法については、容量ストレージを有効にする をご参照ください。
パフォーマンステスト
テスト環境: このテストでは、ecs.c5.xlarge タイプのマスターノードが 1 つ必要です。マスターノードには、4 つの CPU コアと 8 GB のメモリがあります。ecs.c5.xlarge タイプのリージョンサーバーが 4 つ必要です。各リージョンサーバーには、4 つの CPU コアと 8 GB のメモリがあります。
次の表は、容量ストレージの書き込みパフォーマンスを示しています。
ストレージタイプ | 平均 rt | p99 rt |
ホットストレージ | 1736 μs | 4811 μs |
容量ストレージ | 1748 μs | 5243 μs |
このテストでは、各データ行に 10 列あり、各列に 100 バイトのデータが保存されています。つまり、各行には 1 KB のデータが保存されています。システムは 16 の並列スレッドを使用してデータを書き込みます。
次の表は、容量ストレージのランダム読み取りパフォーマンスを示しています。
ストレージタイプ | 平均 rt | p99 rt |
ホットストレージ | 1704 μs | 5923 μs |
容量ストレージ | 14738 μs | 31519 μs |
パフォーマンステスト中は、BlockCache が無効になっており、システムはディスク内のデータを読み取ります。各データ行に 10 列あり、各列に 100 バイトのデータが保存されています。つまり、各行には 1 KB のデータが保存されています。システムは 8 つのスレッドを使用して、リクエストごとに 1 KB のデータを読み取ります。
次の表は、容量ストレージの範囲スキャン パフォーマンスを示しています。
ストレージタイプ | 平均 rt | p99 rt |
ホットストレージ | 6222 μs | 20975 μs |
容量ストレージ | 51134 μs | 115967 μs |
パフォーマンステスト中は、BlockCache が無効になっており、システムはディスク内のデータを読み取ります。各データ行に 10 列あり、各列に 100 バイトのデータが保存されています。つまり、各行には 1 KB のデータが保存されています。システムは 8 つのスレッドを使用して、リクエストごとに 1 KB のデータを読み取ります。キャッシング パラメータは 30 に設定されています。
容量ストレージの読み取り IOPS の制限
容量ストレージは、データがデータベースに頻繁に書き込まれるが、読み取りはあまり行われないシナリオに適しています。容量ストレージの読み取り IOPS には、次の制限があります。
各 Lindorm インスタンスの容量ストレージには、トークンプールがあります。プール内の使用可能なトークン数が
0になると、容量ストレージの読み取り IOPS が調整されます。この場合、各ノードの読み取り IOPS は最大 10 になります。インスタンストークンプール内のトークンは、インスタンスの容量ストレージサイズに応じて増加するレートで自動的に生成されます。
トークンプール内のトークン数が上限に達すると、トークンの生成が停止します。トークンプール内のトークンの最大数は、インスタンスの容量ストレージサイズに応じて増加します。
トークンプールに使用可能なトークンがまだある場合、容量ストレージの読み取り IOPS は調整されません。各 I/O 操作でトークンが 1 つ消費されます。この場合、単一ノードの最大 IOPS は 1,500 です。
LindormTable や LindormTSDB などの上位層の Lindorm エンジンによって容量ストレージで実行される I/O 操作の数は、読み取りリクエストによって発生する I/O 操作の数によって異なります。たとえば、読み取りリクエストが容量ストレージ内の複数のデータブロックのデータにヒットした場合、複数の I/O 操作が発生する可能性があります。同様に、読み取りリクエストがキャッシュ内のデータのみにヒットした場合、容量ストレージ内のデータに対して I/O 操作は実行されません。したがって、上位層の Lindorm エンジンが容量ストレージにアクセスするために実行できる読み取り操作の最大 QPS は、容量ストレージの読み取り IOPS に基づいて推定することはできません。容量ストレージへのアクセスに消費されるトークンに基づいて値を推定することをお勧めします。
容量ストレージの監視メトリクス
Lindorm コンソール にログインします。ページの左上隅で、インスタンスがデプロイされているリージョンを選択します。インスタンス一覧 ページで、管理するインスタンスの ID をクリックするか、インスタンスに対応する [アクション] 列の [管理] をクリックします。
左側のナビゲーションペインで、[インスタンスの監視] をクリックして、[基盤となるストレージメトリクス] を表示します。次の表は、基盤となるストレージメトリクスを示しています。
メトリック
説明
使用可能なトークンの割合
インスタンスレベルのメトリック。使用可能なトークンの割合。インスタンスの全体的な使用可能トークン率が
0%に減少すると、読み取りリクエストが調整されます。Datanode 容量クラウドストレージ IOPS
ノードレベルのメトリック。各読み取り IOPS でトークンが 1 つ消費されます。値が大きいほど、トークンの消費速度が速いことを示します。データエンジンと I/O モデルの違いにより、読み取りリクエストが繰り返し送信され、複数のトークンが消費される場合があります。
容量ベースのクラウドストレージ調整 OPS
ノードレベルのメトリック。調整される各ノードの読み取り OPS。
0% より大きい値は、読み取りリクエストが調整されていることを示し、上位層の読み取りレイテンシが増加します。重要インスタンスの合計使用可能トークン率が
0% より大きく、単一ノードの IOPS が1500より大きい場合、読み取りは調整されます。
考慮事項
容量ストレージの IOPS は制限されているため、容量ストレージはデータのクエリ頻度が高くないシナリオに適しています。
容量ストレージの書き込みスループットは、標準ストレージの書き込みスループットに近いです。
容量ストレージは、多数の同時読み取りリクエストを処理するのには適していません。容量ストレージを使用して多数の同時読み取りリクエストを処理すると、エラーが発生する可能性があります。
Lindorm インスタンス用に大容量の容量ストレージを購入した場合は、ビジネス要件に基づいて読み取り IOPS を調整できます。詳細については、テクニカルサポート にお問い合わせください。
各ノードには 30 TB 以下のコールドデータを保存することをお勧めします。各ノードに保存できるコールドデータの量を増やすには、テクニカルサポート にお問い合わせください。
インスタンスの容量ストレージの 95% 以上が使用されている場合、容量ストレージにデータは書き込めなくなります。インスタンスの容量ストレージの使用率を監視します。詳細については、容量ストレージの容量を表示する をご参照ください。