2021 年に AWS に入社して以来、私は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスファミリーが成長するのを見てきました。そのペースは今でも驚きを隠せません。AWS Graviton 搭載のインスタンスから、特殊な高速コンピューティングオプションまで、パフォーマンスの限界をさらに押し上げる新しいインスタンスタイプが数か月ごとにリリースされているように感じられます。2026 年 2 月の時点で、AWS は 1,160 を超える Amazon EC2 インスタンスタイプを提供しており、その数は今も増え続けています。 2026 年 2 月 16 日週最初のニュースである Amazon EC2 M8azn インスタンスの一般提供はその良い例です。M8azn インスタンスは、第 5 世代 AMD EPYC プロセッサを搭載した高周波で高ネットワークの汎用インスタンスであり、クラウド内で最も高い 5 GHz の最大 CPU 周波数を提供しています。前世代の M5zn インスタンスと比較した場合、M8azn インスタンスは最大 2 倍優れたコンピューティングパフォーマンス、4.3 倍広いメモリ帯域幅、10 倍大きい L3 キャッシュを提供します。また、M5zn より最大 2 倍のネットワークスループット、最大 3 倍の Amazon Elastic Block Store (Amazon EBS) スループットも提供します。 第 6 世代の Nitro Card を使用して AWS Nitro System 上に構築された M8azn インスタンスは、自動車、航空宇宙、エネルギー、電気通信分野におけるリアルタイム財務分析、ハイパフォーマンスコンピューティング、高頻度取引、CI/CD パイプライン、ゲーム、シミュレーションモデリングなどのワークロード向けです。このインスタンスでは、メモリと vCPU の比率が 4:1 になっており、2 個から 96 個の vCPU 数、最大 384 GiB のメモリを搭載した 9 種類のサイズ (2 種類のベアメタルタイプを含む) で利用できます。詳細については、 Amazon EC2 M8azn インスタンスページ をご覧ください。 2026 年 2 月 9 日週のリリース 以下は、2026 年 2 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock が 6 つのフルマネージドオープンウェイトモデルのサポートを追加 – Amazon Bedrock が、DeepSeek V3.2、MiniMax M2.1、GLM 4.7、GLM 4.7 Flash、Kimi K2.5、Qwen3 Coder Next のサポートを開始しました。これらのモデルは、フロンティア推論とエージェンティックコーディングのワークロードに対応します。DeepSeek V3.2 と Kimi K2.5 は推論とエージェンティックインテリジェンスを対象としており、GLM 4.7 と MiniMax M2.1 は大規模な出力ウィンドウでの自律コーディングをサポートし、Qwen3 Coder Next と GLM 4.7 Flash は本番環境デプロイ用のコスト効率に優れた代替手段を提供します。Project Mantle を活用するこれらのモデルは、OpenAI API 仕様との設定不要の互換性を提供します。 このリリースにより、仕様主導型の AI 開発ツールである Kiro での DeepSeek v3.2、MiniMax 2.1、Qwen3 Coder Next といった新しいオープンウェイトモデルの使用も可能になります。 Amazon Bedrock が AWS PrivateLink のサポートを拡大 – Amazon Bedrock が、 bedrock-runtime エンドポイントの既存サポートに加えて、 bedrock-mantle エンドポイントでも AWS PrivateLink をサポートするようになりました。bedrock-mantle エンドポイントは、Amazon Bedrock で提供される大規模な機械学習モデル用の分散型推論エンジンである Project Mantle を活用しています。Project Mantle は、サービス品質制御を備えたサーバーレス推論、自動化されたキャパシティ管理によって引き上げられたデフォルトカスタマークォータ、OpenAI API 仕様との設定不要の互換性を提供します。OpenAI API 互換エンドポイントの AWS PrivateLink サポートは、14 の AWS リージョンでご利用いただけます。使用を開始するには、Amazon Bedrock コンソールにアクセスするか、OpenAI API 互換性ドキュメントを参照してください。 Amazon EKS Auto Mode がマネージド Kubernetes 機能のための強化されたロギング機能を発表 – Amazon EKS Auto Mode で Amazon CloudWatch Vended Logs を使用するログ配信ソースを設定できるようになりました。これは、Auto Mode のマネージド Kubernetes 機能からコンピューティングの自動スケーリング、ブロックストレージ、負荷分散、ポッドネットワーキングに関するログを収集するために役立ちます。各 Auto Mode 機能は、AWS 認証と承認が組み込まれた CloudWatch Vended Logs 配信ソースとして、標準の CloudWatch Logs よりも低い料金で設定できます。ログは、CloudWatch Logs、Amazon S3、または Amazon Data Firehose を宛先として配信できます。この機能は、EKS Auto Mode が提供されているすべてのリージョンでご利用いただけます。 Amazon OpenSearch Serverless がコレクショングループのサポートを開始 – 新しいコレクショングループを使用して、異なる AWS Key Management Service (AWS KMS) キーを持つコレクションの全体で OCU (OpenSearch Compute Unit) を共有できるようになりました。コレクショングループは、コレクションレベルのセキュリティとアクセス制御を維持しながら、共有コンピューティングモデルを通じて全体的な OCU コストを削減します。また、最大 OCU 制限に加えて最小 OCU 割り当てを指定することも可能になったため、遅延の影響を受けやすいアプリケーションの起動時におけるベースラインキャパシティが保証されます。コレクショングループは、現在 Amazon OpenSearch Serverless が提供されているすべてのリージョンでご利用いただけます。 Amazon RDS がスナップショットの復元時におけるバックアップ設定のサポートを開始 – スナップショット復元操作の実行前と実行中にバックアップ保持期間と希望するバックアップウィンドウを表示し、変更できるようになりました。これまで、復元されたデータベースインスタンスとクラスターはスナップショットメタデータからのバックアップパラメータ値を継承し、変更できるのは復元完了後のみでした。これからは、自動バックアップとスナップショットの一部としてバックアップ設定を表示し、復元時にこれらの値を指定または変更できるようになるため、復元後に変更する必要がなくなります。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンにあるすべての Amazon RDS データベースエンジン (MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2) と Amazon Aurora (MySQL 互換および PostgreSQL 互換エディション) で利用でき、追加料金はかかりません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS AI and Data Conference 2026 – 3 月 12 日にアイルランドの Lyrath Convention Centre で開催される、1 日限りの無料対面イベントです。このカンファレンスでは、Amazon Bedrock、Amazon SageMaker、QuickSight を用いたエージェントの設計、トレーニング、およびデプロイの他、エージェントの AWS データサービスとの統合、エージェントを大規模に運用するためのガバナンスプラクティスの適用といったトピックを取り上げます。アジェンダには、アーキテクト、開発者、ビジネスリーダー向けの戦略的ガイダンスとハンズオンラボが含まれています。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。このイベントは、 アーメダバード (2 月 28 日)、 スロバキア (3 月 11 日)、 プネー (3 月 21 日) で開催される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧ください。 2026 年 2 月 16 日週のニュースは以上です。2026 年 2 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第一弾は、「2025 Japan AWS Jr. Champions」 を受賞された 間世田 秀（ませだ しゅう）さん。 Japan AWS Jr. Champions は、AWSを積極的に学び、自らアクションを起こし、その取り組みが周囲にも良い影響を与えている若手エンジニアが選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、間世田さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Jr. Champions 所属： ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 氏名： 間世田　秀 【自己紹介】 2023年度入社後、AWS内製化支援サービス「 テクニカルエスコート 」のメンバーとしてお客様を支援させていただいています。 テクニカルエスコートでは、AWS導入検討から、設計、構築、運用改善まで幅広く内製化を後押ししつつ、お客様の課題解決に取り組んでいます。   本編  AWSエンジニアになった背景を教えてください。 もともと情報工学科出身でプログラミングに馴染みがあったため、アプリケーション開発希望で入社しました。  ただ、新人研修で改めてインフラ領域を学びなおしていくうちに、「 ネットワーク って パズルみたい でおもしろいな 」 と思ったことがインフラに飛び込むきっかけ になりました。AWSを初めて触ったのも、おなじく新人研修中です。AWSの持つシェアの大きさや豊富なサービス、そしてその柔軟性の良さに魅力を感じ、そこから、クラウドの中でもAWSを深く学びたいという思いが芽生えました。 研修後には 、 AWS内製化支援サービス「テクニカルエスコート」 チーム に配属 され、 AWSで課題を抱えたお客様と伴走しながら、共に課題解決に取り組む日々を送っています。 お客様と共に成長していく過程で、学ぶことの楽しさはもちろんのこと、複雑なシステムをシンプルに提供している点に魅力を感じ、AWSの奥深さを改めて認識しています！ エンジニアとして大切にしている価値観や信条はありますか？ 業務で必要な範囲にとどまらず、視野を広げるために最新技術を追い続ける姿勢を意識しています。今すぐ使う予定がなくても、知っていることで選択肢が増え、設計や提案の質を高めることにつながると考えているからです。近年は技術進化のスピードが非常に速く、アップデートが追いついていないと感じる場面もありますが、取り残されないよう頑張ってキャッチアップしています。 また、私たちは先人たちのアウトプットに多く支えられてきたと感じています。だからこそ、自分も 「巨人の肩に立つ」 だけで終わらせず 、 学んだことを言語化し、アウトプット として残すことを大切にしています。 言語化 することで 自分自身の理解が整理されるだけでなく、同じ悩みを抱えている人や、同じところでつまずいている人の助けになればと考えています。 ヨコのつながりを大切にすることも信条 の一つです。社内の他部署はもちろん、他社のJr. Championsとの交流を通じて、新しい発想やこれまで気づけなかった視点を多く得ることができました。そうしたヨコのつながりから生まれた刺激が、登壇や社内でのAWS活動といった次のアクションのアイディアにつながっています。 この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 受 賞の決め手は、苦手なことでも積極的に挑戦し続けたこと だと考えています。 人前で話すことは得意ではありませんでしたが、堂々と伝えられる自分になりたくて、イベント登壇への挑戦を重ねました。積極的に手を上げ続けた結果、登壇機会にも恵まれ、2024年度には登壇5回（社内2回・社外3回）の経験を積むことができました。 「 迷ったらとりあえず手を挙げる 」 を胸に、一歩ずつ積み重ねた 結果が評価につながったのだと思います。 受賞がご自身のキャリアやチームに与えた影響はありますか？ 受賞をきっかけに、2025年度から一部AWSマーケティング業務に携わらせていただいています。 マーケティングチームに参画したことで、我々の商材を外部の視点から見られるようになったことは大きな変化です。 プロモーション活動を通して外から見ることで、商材の良さや改善点を客観的に捉え直すことができたと思っています。 また、これまで技術職としてのキャリアしか考えていませんでしたが、マーケティングという新たな軸が加わったことでキャリアの幅が広がりました。 活動の中でAWS事業を どうビジネスとして発展させていくか を具体的に考える機会が増え、会社で働く上での マーケティングの視点の重要性を実感 しています。 この一年間は、年次を重ねていくうえで必要となる考え方を学ぶ貴重な機会だったと振り返っています。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 AWS/オンプレミスのネットワーク知識を身につけ、ネットワークアーキテクチャの提案についてチームの先輩方と同じ目線で議論できるエンジニアになりたいです。 テクニカルエスコートチームには、長年アプリケーション開発やデータセンターのネットワーク構築に携わってきたメンバーが多く在籍しており、AWSに限らない幅広い知識を持っている点が大きな魅力だと感じています。 AWS歴は3年目となり、 クラウドの設計・運用の経験 は増えてきましたが、 リフト＆シフト案件に携わる中で、オンプレミスのネットワーク知識不足を痛感 する場面がありました。また、オンプレミス歴の長いお客様に対しては、クラウド単体の説明ではなく、オンプレミスとの比較を交えて説明する方が理解・納得いただきやすいと感じており、そのためにも オンプレミスを含めたネットワーク全体の理解が不可欠だと考えています。 今後、AWSはもちろんですが、ネットワークを軸としたクラウドとオンプレミスどちらも積極的に学び続けていきます！ 次のインタビューは同じJr. Championsの「佐藤 優音」さんです！佐藤さんにお聞きしたいことはありますか？ 佐藤さんは、業務ではOracle Databaseを扱っているとお聞きしました。 AWS と Oracle 並行して、 学び続ける秘訣 を教えてください！   間世田さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ 私自身が若手エンジニアの模範となるよう 、さらなるアウトプットを通じて皆様への良い影響を与えられるよう 挑戦 していきます！私の活動が同世代のエンジニアに広がり、そこから先輩・後輩との繋がりに発展していけば、「 クラウドに強いSCSK 」 の実現に寄与でき、お客様に還元 できると信じています。   次回インタビューは、2025 Japan AWS Jr. Champions を受賞された 佐藤 優音（さとう ゆうと）さんです。 次回の記事もお楽しみにお待ちください！

本記事は 2026/02/04に投稿された Auto Analyze in Aurora DSQL: Managed optimizer statistics in a multi-Region database を翻訳した記事です。 Amazon Aurora DSQL  および他の最新のリレーショナルデータベースシステムにおいて、正確な統計情報はクエリプランにおける最も重要な要因の一つです。悪いクエリプランを良いクエリプランの代わりに誤って選択してしまうと、100倍の性能低下を引き起こす可能性があります。プランのリグレッションが発生するリスクを最小化するために、最新の統計情報が重要です。この投稿では、DSQL オプティマイザー統計を自動的に計算する確率的かつ事実上ステートレスな手法である Aurora DSQL Auto Analyze について解説します。PostgreSQL に精通しているユーザーは、 autovacuum analyze  との類似性を理解していただけるでしょう。 クエリパフォーマンスにおける統計情報の重要性 統計情報がクエリパフォーマンスに与える影響を説明するために、オプティマイザーがフルテーブルスキャンまたはインデックススキャンを使用してデータにアクセスするかを選択できる基本的な例を見てみましょう。統計情報の効果を説明するために、内部パラメータを使用してAuto Analyzeを無効にしました。お客様にとって、Auto Analyze は常に有効になっており、無効にするオプションはありません。 まず、int 型の列 A とtext 型の列 B を持つテーブルを生成します。また、列 A にインデックスを作成します。次に、このテーブルに 600,000 行を挿入します。この例では、列 A に注目します。300,000 行は 0 から 299,999 までの A 値を含みます。残りの 300,000 行は A 値が 42 です。 create table mytable (A int, B text); create index async mytableidx on mytable(A); SELECT 'INSERT INTO mytable SELECT generate_series(3000 * ' || i-1 || ', 3000 * ' || i || ' - 1), ''AWS Aurora DSQL is great'';' FROM generate_series(1, 100) i; \gexec SELECT 'INSERT INTO mytable SELECT 42, ''AWS Aurora DSQL is great'' FROM generate_series(1, 3000);' FROM generate_series(1, 100); \gexec 以下のクエリを使用して、 A 値が 42 の行が 300,001 行あることを確認します。したがって、 A 値が 42 の行は全体の半分以上を占めています。 SELECT count(*) FROM mytable GROUP BY GROUPING SETS (A = 42); count -------- 299999 300001 (2 rows) 以下のコマンドを実行して、 A 値が 42 の全ての行を選択する場合に、オプティマイザーがどのプランを選択するかを観察してみましょう。 EXPLAIN ANALYZE SELECT * FROM mytable WHERE A = 42; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------ Index Scan using mytableidx on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual time=15.926..5217.368 rows=300001 loops=1) Index Cond: (a = 42) -> Storage Scan on mytableidx (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) -> B-Tree Scan on mytableidx (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Index Cond: (a = 42) -> Storage Lookup on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Projections: a, b -> B-Tree Lookup on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Planning Time: 3.367 ms Execution Time: 5228.314 ms (10 rows) 選択されたプランにはインデックススキャンが含まれていることがわかります。 A = 42 が半数を占めることから、明らかにインデックスからの間接参照のコストを避けて、フルテーブルスキャンを選択することが期待されます。 オプティマイザーが最適なプランを見つけるのを助けるために、テーブルで ANALYZE を実行します。 ANALYZE mytable; 今度は選択されたプランにフルテーブルスキャンが含まれています。クエリは半分以下の時間で完了するようになりました。 EXPLAIN ANALYZE SELECT * FROM mytable WHERE A = 42; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------- Full Scan (btree-table) on mytable (cost=74756.80..87915.45 rows=296975 width=32) (actual time=1.179..1977.851 rows=300001 loops=1) -> Storage Scan on mytable (cost=74756.80..87915.45 rows=296975 width=32) (actual rows=300001 loops=1) Projections: a, b Filters: (a = 42) Rows Filtered: 299999 -> B-Tree Scan on mytable (cost=74756.80..87915.45 rows=597254 width=32) (actual rows=600000 loops=1) Planning Time: 5.055 ms Execution Time: 1989.230 ms (8 rows) Aurora DSQL クラスターでこの例を再現すると、手動で analyze を実行する前でも、フルテーブルスキャンを使用する高速なクエリプランが得られることがわかります。Auto Analyze がバックグラウンドで自動的に統計情報を計算し、このパフォーマンス向上を提供してくれます。 Aurora DSQL における Auto Analyze このセクションでは、まず PostgreSQL の autovacuuming について再確認します。次に、Aurora DSQL が マルチAWSリージョン 環境において、事実上無制限のスケールで2つの構成要素を通じて PostgreSQL の動作を模倣する方法を説明します。 PostgreSQL では、 ANALYZE は autovacuum デーモン ( AUTOVACUUM ) を通じて自動的にトリガーされます。これはテーブルの変更を継続的に監視し、事前定義された閾値に達した時（通常はテーブルの行の 10% が挿入、更新、または削除された後）に統計情報を更新します。詳細については、 autovacuumデーモン のPostgreSQL ドキュメントを参照してください。 Aurora DSQL において、Auto Analyze 機能は PostgreSQL の autovacuum による ANALYZE 処理プロセスに相当し、クエリプランニングに不可欠なテーブル統計情報を自動的に維持します。PostgreSQL の決定論的な閾値ベースのアプローチとは異なり、DSQL は 2 つの主要な構成要素に基づいたマルチリージョン対応のソリューションを実装しています： 確率的トリガー がトリガーメカニズムとして機能します。テーブルの変更を監視・追跡する代わりに、各トランザクションは、テーブルサイズに対して変更する行数に基づいて ANALYZE をトリガーする確率を計算します。この確率的アプローチにより、セッション間の調整の必要性がなくなり、テーブルの進化に応じて統計情報が更新されることを保証します。 サンプリングベースの analyze 手法 が実際の統計計算を処理します。トリガーされると、ANALYZE はサンプリング技術を使用して、大規模なマルチテラバイトテーブルであっても効率的に正確な統計情報を計算し、Aurora DSQL が事実上無制限のテーブルサイズにスケールできるようにします。 確率的トリガー Aurora DSQL は、テーブル統計情報をいつ更新するかを決定するために、Auto Analyze の確率的トリガーを使用します。コミットする各トランザクションは、テーブルサイズと挿入、更新、削除操作を通じて行う変更数に依存する ANALYZE をトリガーする確率を持ちます。 ANALYZE のトリガーはトランザクションのパフォーマンスに大きな影響を与えないことに注意してください。このセクションでは、トランザクションの ANALYZE 確率がどのように決定されるかを説明します。 Aurora DSQL は各トランザクション内でテーブルごとの変更を追跡します。トランザクションがコミットされると、変更された各テーブルが 10% の閾値比に対して評価されます。トランザクションがテーブルの行の 10% 以上を変更する場合、 ANALYZE は常にトリガーされます。より小さな変更の場合、 ANALYZE をトリガーする確率は変更された行の割合に比例します。 Let threshold_ratio = 0.1 for each modified table R: change_count = num_inserts + num_updates + num_deletes threshold_count = threshold_ratio * pg_class.reltuples(R) probability = change_count / threshold_count if random_number(0,1) <= probability: submit_job("ANALYZE R") この説明は現在、100万行以上のテーブルについてのみ正確です。より小さなテーブルについては、Aurora DSQLの別のクエリプロセッサで実行される ANALYZE のセットアップコストを考慮した減衰係数があります。 この確率的アプローチは、データベースセッション間の調整を必要とせずに、平均してテーブルの 10% が変更された後に ANALYZE をトリガーします。システムは、確率を計算するために pg_class.reltuples (以前の ANALYZE 実行によって設定される) からの行数推定値を使用し、分析されていないテーブルについてはデフォルトで1行とします。 確率的メカニズムはワークロードパターンに自然に適応します。頻繁に変更されるテーブルでは、統計情報がより頻繁に更新されます。逆に、静的なテーブルでは不要な ANALYZE オーバーヘッドを回避します。 サンプリングベースの ANALYZE Aurora DSQL が ANALYZE 操作をトリガーすると、テーブル全体をスキャンすることなく効率的に正確な統計情報を計算するためにサンプリングを使用します。システムは最低30,000行のサンプルを収集するように設計されたサンプリング率を計算し、大きなテーブルではさらに多くの行を収集します。このサンプルは pg_class のテーブル全体の統計情報を計算するために使用されます。その後、PostgreSQLと同様に、厳密な30,000行のサブセットが列固有の統計情報を生成するために使用されます。 私たちの手法は、計算された確率に基づいてストレージから行をランダムに選択することで機能します。このアプローチは PostgreSQL のサンプリング手法を反映しながら、Aurora DSQL の分散アーキテクチャに適応しています。サンプリング率は、以前の統計情報から推定されるテーブルサイズに対する目標行数によって決定されます。 前述したように、収集されたサンプルは2種類の統計情報を生成します： pg_class に格納されるテーブル全体の統計情報と、pg_stats の列固有の統計情報です。テーブル全体の推定値は行数とページ数の推定値です。 pg_stats の列固有の統計情報には、null値の割合、個別値の比率、ヒストグラム、最頻値が含まれます。これらの統計情報は、効率的な実行プランを生成するために必要な情報をクエリオプティマイザーに提供します。 Aurora DSQLが使用するサンプリングベースの Analyze 手法は、テーブルの成長に関係なく一貫したサンプルサイズを提供することで、マルチテラバイトのテーブルであっても効率的な計算を保証します。実験では、最大240TBまでのあらゆるサイズのテーブルで ANALYZE が数分で完了することがわかりました。 まとめ この投稿では、Aurora DSQL の Auto Analyze 機能について学びました。Auto Analyze は、分散マルチリージョンデータベースシステム特有の課題に対処しながら、PostgreSQL の autovacuum による ANALYZE の信頼性を提供します。確率的トリガーと効率的なサンプリングベースの計算を組み合わせることで、手動介入なしにクエリが適切に維持された統計情報から一貫して恩恵を受けることができます。確率的アプローチは、従来の閾値ベースのシステムが必要とする調整オーバーヘッドの多くを排除し、分散アーキテクチャに自然に適しています。一方、サンプリングベースの分析は、小さなテーブルから大規模な 240TB のデータセットまでスケールします。Aurora DSQL Auto Analyze は、バックグラウンドで透過的に動作しながら、適切に維持されたオプティマイザー統計情報の利点を提供し、開発者がテーブル統計の管理ではなくアプリケーションの構築に集中できるようにします。 Aurora DSQL Auto Analyze は、 Aurora DSQLが利用可能なすべてのリージョン で利用できます。Aurora DSQL の詳細については、 ウェブページ と ドキュメント をご覧ください。 Magnus Mueller Magnus  は AWS の応用科学者で、カーディナリティ推定、クエリ最適化、システム向け機械学習を専門としています。カーディナリティ推定の博士号を取得し、主要なデータベース会議で研究を発表しています。 James Morle James  はプリンシパルエンジニア兼分散データベースアーキテクトで、ハイパースケールでの大規模トランザクショナル・分析システムの設計・実装において 20 年以上の経験を持ちます。 Matthys Strydom Matthys  は AWS のプリンシパルエンジニアで、分散データベースクエリ処理、AWS クラウドサービスコントロールプレーン、高スループット電話網統合、デスクトップCADプログラムなど、幅広いソフトウェアシステムにおいて 20 年以上の経験を持ちます。 Vishwas Karthiveerya Vishwas  は AWS のシニアソフトウェア開発・データベースシステムエンジニアで、大規模分散データベースのクエリプランニング、コストベース最適化、実行性能を専門としています。 Raluca Constantin Raluca  は AWSのシニアデータベースエンジニアで、Amazon Aurora DSQL を専門としています。Oracle、MySQL、PostgreSQL およびクラウドネイティブソリューションにわたる 18年のデータベース専門知識を持ち、データベースのスケーラビリティ、性能、リアルタイムデータ処理に焦点を当てています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。