データベースワークロード統合を検討中のお客様から好評をいただいています。ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。倍のスループットを実現します。最適化に役立つガイダンスをいくつかお伝えします。「統合の費用はどれくらいかかりますか?」や「データセットはどのくらいの大きさにできますか?」など、よくある質問にお答えします。上記の質問はシンプルですが、必ずしも回答がシンプルになるわけではありません。回答は、お使いのデータセットやワークロードのパターンによって大きく異なります。操作方法について詳細を説明します。統合により、一般的にテーブルは大きくなります。アドテック、IoT、消費者向けアプリケーション分野の場合、通常は大きな同種アプリケーションのデータベースをそれぞれにデータのサブセットが含まれる大量のシャードに分割します。シャーディングを完全になくすことはできないかもしれませんが、より少数のシャードに統合して操作上のオーバーヘッドを減らすことができます。テーブル数の増加も、統合の結果見られることです。アプリケーションで一般的なものです。クラスターにまとめられ、テナントあたりの操作コストを削減します。データベースの使用率。多数の同時接続を行うなど、統合データベースワークロードの使用率が多くのメトリクスで増加します。実際には、同じプロジェクト内の複数の要素で使用率が増加することになります。以下のガイドラインは、各要素でワークロードを最適化するのに役立つはずです。最大容量に制限があります。いう最大の保存容量です。クラスターに物理的に保存できるデータ量の上限が決められます。個々のテーブルの大きさについて上限が決められます。ストレージエンジンから多くの特徴を受け継いでいます。これらの特徴には効果的な統合に影響を与えるものがあります。ページを使用してデータを保存します。ページは、テーブルと関連インデックスのコンテナとしての役割を果たすテーブルスペースにグループ化されます。別のテーブルスペースを各テーブルに使用するか、テーブルがパーティション化されている場合は各テーブルのパーティションに使用します。このようなテーブルスペースのほとんどに、以下のデータ構造が含まれています。テーブルの主キーまたは一意キーで並べられたテーブルレコードを含むクラスター化インデックス。使用してレコードを識別し並べます。テーブルのセカンダリインデックス。上記のテーブルアーキテクチャが意味することは、所定のテーブルに保存できる決まった最大行数がないということです。最大行数は、以下のとおり多くの要因によって決まります。お使いの主キーまたは一意キーを選択することでサポートされる一意値の最大数。千万を少し上回る最大行数をサポートします。セカンダリインデックスの数とサイズ。クラスター化インデックスレコードまたは外部ページに直接保存される可変長データの量。データページをいかに効果的に活用したか。効果的にテーブルを統合できるかを決める要素としては、実際にはスキーマデザインとクエリパターンが行数よりも重要です。テーブルの行数が増えるにつれ、クラスター化インデックスとセカンダリインデックスのサイズも大きくなり、これらのインデックスをトラバースするためにかかる時間も増えます。そのため、クエリのパフォーマンスはテーブルのサイズとともに低下します。詳しくパフォーマンス低下を軽減するためのベストプラクティスと方法をいくつか見てみましょう。テーブルのスキーマを多数のレコードで設計するページあたりのレコードの密度は、クエリパターンとスキーマのコンテキストではテーブルサイズが大きいとさらに相関を示すようになります。(データページの半分)。データベースはページを管理して、パフォーマンスを犠牲にすることなくストレージの効率性を維持します。将来的な書き込みに対応し、ページ分割数を減らすためにページの空白部分を残します。パーセント以下に落ちると、ページを結合しようとします。ページは完全に書き込まれることはないため、常に一定量のストレージのオーバーヘッドがあります。最適なスキーマデザインを実現することが、有用なオーバーヘッドをストレージの無駄にしないようにするための最善の方法です。そのような無駄は高いリソース使用率とレイテンシーを生み、ワークロードのパフォーマンスが許容範囲を下回るものになってしまいます。所定テーブル行の情報はすべて等しく価値があるものです。行の全フィールドのデータに同じ頻度でクエリを行い、操作する必要があります。同じ行に使用頻度が異なるデータを保存すると効率が落ちます。所定の列に保存された値を表すことができる最小のデータ型を選択してください。個別の行レベルでの節減は小さなものに思われるかもしれませんが、何十億列に及ぶと効果は大きくなり、顕著なものとなります。可能な限り多くのクラスター化インデックスレコード内の可変長データに保存を試み、外部ページに残りのデータを保存します。大きなデータレコードによりデータのレコード密度が低くなり、クエリパフォーマンスの低下を引き起こします。大きな影響を与える場合は、それでも大きなレコードが必要な場合があるかもしれません。必要がない場合は、そのような大きなフィールドを別のテーブルにオフロードすると便利なことがあります。オブジェクトストアに保存できます。インデックスはクエリのパフォーマンスを向上させるのに効果的です。これには追加費用が必要であり、追加のストレージとメモリフットプリントを消費し、書き込みのパフォーマンスを低下させます。セカンダリインデックスレコードは、行の物理的なストレージ座標を直接ポイントしません。代わりに、その行の主キー値をポイントします。その結果、どのセカンダリインデックスレコードにも基になる行の主キー値の複製が含まれます。効率性を低下させます。必要なインデックスのみを使用し、複合インデックスにおいてインデックスの選択は結果を左右する重要なものであることにご注意ください。クエリパターンで次の選択ルールが可能な場合、インデックスをさらに少数の複合インデックスに置き換えることでインデックスの数を減らせる可能性があります。最終的には、効果的なスキーマデザインを使用することで、許容範囲に満たないパフォーマンスになる前に行数を増やしたテーブルを保有できます。実際の最大行数は、データとデータのやり取りを行う方法によって決まります。大きなテーブルにおけるパフォーマンスの低下を軽減するツールです。各パーティションは別のテーブルスペースにデフォルトで保存されているため、パーティショニング表現が決定するとおりにクラスター化インデックス、セカンダリインデックス、特定のデータサブセット向けの外部ページがパーティションに含まれています。個のパーティションとサブパーティションを保有できます。パーティションの数が多いとパーティション自体にパフォーマンスの問題を引き起こします。このような問題には、メモリ使用率の増加やパーティションの数が多いクエリのパフォーマンスの問題などがあります。パーティション内のインデックス構造が小さいほどトラバースが高速になります。(パーティション排除と呼ばれる最適化)、パフォーマンスにメリットが見られる可能性があります。パーティション化された列を含まない述語を持つクエリなど、少数の特定パーティションに限定されないクエリは低速化する可能性があります。つの大きなインデックスではなく、複数の小さなインデックスをエンジンがトラバースする必要があるために起こります。そのため、パーティション化された大きなテーブルがパフォーマンスに与える影響は、パーティション排除やワークロードの選択をいかに効果的に利用できるかによって決まります。大きなテーブルがあると、クエリオプティマイザーは正確な統計を持つことが重要です。正確な統計があることでクエリオプティマイザーは正しい基数を持つ最も限定的なインデックスを使用するため、クエリパフォーマンスが向上します。ランダムインデックスページをサンプリングして統計と基数を評価します。巨大テーブルや列内に均一でない値が分散しているテーブルを取り扱う際には、この数は十分でない可能性があります。デフォルトで統計はディスクに残り、テーブルに大きな変更が加えられると自動的に再計算されます。巨大テーブルでこの規模の変更が加えられる頻度が少なくなると、統計は徐々に正確性を欠くようになる可能性があります。その結果、クリティカルポイントに到達してクエリオプティマイザーが実行プランを変更すると、影響を受けるクエリのパフォーマンスが時間をかけて低下し、突然低下することもあります。ステートメントを使用してクエリ実行プランを見直し、想定する動作からの変更を特定します。主要なワークロードのクエリに期待されるパフォーマンスの基準を定め、時間をかけてパフォーマンスをモニタリングすることをおすすめします。スロークエリログは、特定のしきい値を超えるクエリのログに有効ですが、時間をかけた緩やかな低下をキャプチャするにはそれほど有効ではありません。パフォーマンススキーマを使用できます。これを有効にするとメモリ消費が増え、全体のシステムパフォーマンスが低下することもあります。実行して適切に統計を更新する方法。サンプリングされたページを増やすと統計をコンピューティングするためにかかる時間も増えます。統計がディスクに残る際にサンプリングされたページのグローバルパラメータ。このパラメータはテーブルごとに設定することもできます。上記に類似しているものの、統計がディスクに残らない場合に使用されるグローバルパラメータ。つの要因ですが、テーブルがどの程度アクティブであるかの方が重要な場合があります。操作を実行するのに問題となる可能性があります。操作とスキーマの変更に依存している場合、このような操作が巨大テーブルを使用できる機能を制限する可能性があります。操作方法に似ています。操作はデータを正しいスキーマで新規テーブルスペースに複製します。そのため、十分な空き容量を確保する必要があります。操作範囲のテーブルをロックしますが、これを行うと通常のワークロードでは混乱をきたします。操作を行い、テーブルデータを直接変更します。この操作は一時スペースでテーブルへの新規書き込みをバッファ処理し、書き込みがマージされた場合のみテーブルをロックします。操作が行われているテーブルに大量の書き込みを生成するワークロードにより、マージされる変更量は比較的大きなものとなります。このサイズではマージフェーズのロックにさらに時間がかかります。操作の完了を大いに妨げます。値になりうる列を瞬間的な操作に近いものとしてテーブルの最後に加えることができます。関するデメリットの一部を軽減するのに役立ちます。使用して操作を実行することを検討してもよいでしょう。操作を実行できますが、巨大テーブルでは操作時間が長くなります。クラスターに保存される可能性もあります。クラスターに統合できるテーブル数はワークロードとアクセスパターンによって決まります。特定用途向けに作られた分散型のログ構造ストレージサービスを使用します。適用されないファイルシステムに固有の制限を軽減することにあります。多数のテーブルを持つことによるファイルシステムに関する影響は操作面、エラー回復面のいずれにもありません。オプションをオフにできますが、おすすめしません。このオプションはパフォーマンスや回復時間に影響を与えなくなっているからです。テーブル数が多い場合はメモリ使用率に影響を与えます。クラスターのメモリ消費は次のとおりです。(ページキャッシュ)。パラメータグループで変更できます。バッファプールのサイズ縮小は通常望ましいことではありません。