DSQLの大規模な照会・集計とOLTPへの干渉
DSQLの大きなクエリの性能・OLTPへの干渉・チューニングの負担は？
結果の要約
この実験では、DSQLで大きなJOIN・集計クエリにどれだけ時間と費用がかかるか、そしてそのようなクエリを注文業務（OLTP）と同時に実行するとOLTPがどれだけ遅くなるかを確認しました。最小範囲（MVP）として、計画のL規模の代わりにE002のS規模のデータ（注文1,100万行、注文品目2,750万行）で選択度の異なる4つのクエリを実行し、毎秒1,000件のOLTP負荷の中で集計を繰り返す干渉試験を行いました。対照群は今回測定していません。
インデックスを使う顧客ごとの最近の注文20件のJOINは、30回の実行でp50 4.4 ms、p95 32.9 msでした。注文の10%（約110万行）を日付別に集計するクエリは2.4–2.6秒、注文1%の範囲の注文品目（約27万行）で商品ランキングを付けるwindowクエリは0.7秒、注文1,100万行全体をステータス別に集計するクエリは約36秒かかりました。同じクエリを2回実行した結果、行数と結果ハッシュは同じで、2回目も1回目とほぼ同じ時間がかかり、繰り返し実行による高速化の効果は見られませんでした。
DSQLはクエリが処理した量だけDPUで課金します。分単位の使用量から推定すると、全体集計1回に約1,700 DPU（約$0.017）、10%集計1回に約100–150 DPUかかりました。毎秒1,000件のOLTP負荷を送りながら10%集計を休みなく繰り返した（5分間で124回、p50 2.4秒）ところ、OLTPは失敗0件でSLOを守り、注文作成のp95は27.5 msから32.0 msに、p99は30.7 msから41.8 msに、商品照会のp99は6.9 msから16.4 msに増えました。
本番利用の観点
DSQLではインデックスを使う照会は速いものの、数百万行以上を走査する集計は数秒から数十秒かかり（1,100万行で約36秒）、トランザクションの300秒上限のため、より大きな集計は分割して実行する必要があります。サーバー側の statement_timeout と文のキャンセルが機能しないため（E001）、長時間かかるクエリを途中で止める手段も限られます。集計を繰り返してもOLTPは目標内で処理され、干渉は小さいものでした。ただし集計は処理したデータ量に応じてDPU料金が発生するため、定期レポートやダッシュボードのように大きな集計が頻繁な業務は、分析用のストアに分離するほうが費用面で安全です。対照群との速度比較は行っていません。
確認する問い
DSQLの大きなクエリの性能・OLTPへの干渉・チューニングの負担は？
実行条件
- リージョンと日時: ソウル（ap-northeast-2）、2026-09-29 10:53–11:07 UTC。
- 構成: D1 Aurora DSQL 単一リージョン、E002規模のデータ（注文1,100万行、注文品目2,750万行、元帳1,100万行、約5 GiB）と、先行する測定で蓄積された行。E002の2回目の測定と同じクラスターです。
- クエリ:
- 顧客ごとの最近の注文:
ordersとorder_itemsのJOIN、顧客ID条件、最近の20件（インデックスorders_customer_createdを使用）。30回。 - 日別売上（10%）:
ordersのid < 1,100,000の範囲を日付別にcount・sum。2回。 - 商品ランキング（1%）: 注文IDが
< 110,000の注文品目を商品別に合計した後、rank()window。2回。 - ステータス別の全体集計:
orders全体をステータス別にcount・sum。2回。
- 顧客ごとの最近の注文:
- DPUの推定: クエリの間に90秒ずつ休止を入れ、CloudWatch
TotalDPUの分ごとの合計をクエリの区間に合わせて分けました。分単位の集計のため、クエリごとの値は近似値です。 - 干渉試験: 固定到着率1,000 TPSのOLTP（ウォームアップ60秒 + 測定300秒）の間、1つの接続が10%集計を休みなく繰り返しました。比較の基準は、同じクラスターで先に測定したE008の負荷のみのセルです。
- 負荷発生器:
m7g.4xlargeのSpotランナー1台。 - 計画から変わった点： Lデータ、JSON条件の照会、集計の同時実行数1/4/16の探索、20分 × 3回の測定、対照群とreader分離の条件は実行していません。
性能結果
| クエリ | 処理範囲 | 結果行 | 実行時間 | DPU（推定） |
|---|---|---|---|---|
| 顧客ごとの最近の注文 | インデックス範囲 | 20 | p50 4.4 ms、p95 32.9 ms、p99 80.8 ms | 無視できる水準 |
| 日別売上（10%） | 注文約110万行 | 90 | 2.61秒、2.39秒 | 約 100–150 |
| 商品ランキング（1%） | 注文品目約27万行 | 10 | 0.69秒、0.66秒 | 約 10 |
| ステータス別の全体集計 | 注文1,100万行以上 | 2 | 36.3秒、35.9秒 | 約 1,700 |
OLTP 1,000 TPSでの集計の繰り返しの有無によるp95 / p99（ms）。両セルとも失敗0、不変条件違反0件、SLO合格。
| 業務 | 負荷のみ（E008基準セル） | 10%集計の繰り返し中 |
|---|---|---|
| 商品照会 | 6.0 / 6.9 | 6.4 / 16.4 |
| 注文履歴 | 8.7 / 9.8 | 11.8 / 23.5 |
| 注文作成 | 27.5 / 30.7 | 32.0 / 41.8 |
| 注文キャンセル | 27.0 / 29.2 | 28.1 / 39.8 |
- 干渉試験中の10%集計は124回すべて成功し、p50 2.42秒、p99 2.66秒でした。単独実行（2.4–2.6秒）と同じで、OLTPが集計を遅くすることもありませんでした。
- 干渉区間のDSQL使用量は毎分約4,400 DPUで、OLTPのみのとき（毎分約1,800 DPUと推定）の約2.4倍でした。
開発・運用のしやすさ
- 同じクエリを繰り返しても実行時間がほぼ同じで、初回実行と繰り返し実行を分けてチューニングする余地（キャッシュ効果）は今回のクエリでは見られませんでした。
- DSQLでは
work_memのようなメモリ設定や実行中のクエリのキャンセル手段をユーザーが調整できません。クエリを速くするには、インデックスとクエリの範囲を変えることが主な手段です。 - 大きな集計は300秒のトランザクション上限を超えると拒否されるため、データが増え続ける集計は範囲を分けて実行するように設計する必要があります。
費用
同じクラスターを使ったE002の2回目の測定の一部として、この試験区間（10:54–11:09 UTC）のDSQL使用量は27,921 DPU（約$0.28）でした。クラスターとランナーの費用は E002レポート の費用の節に含めています。
結論と限界
- DSQLはインデックスによる照会は速く、大きな集計は処理した行数に比例して遅くなり（1,100万行で約36秒）、DPU料金が発生しました。集計の繰り返しがOLTPに与えた干渉は小さいものでした。
- 限界: Sデータ、1回の実行、各クエリ2回、DSQL単独です。対照群との速度・費用の比較とLデータでの動作は測定していません。DPUは分単位の合計から分けた近似値です。
後片付けの記録
- この試験はE002の2回目の測定実行（
e002-20260929t081139z-4dce）のクラスターとランナーを使いました。リソースは11:08–11:10 UTCに削除し、e002.py verifyのremaining_count=0（11:10:30 UTC）と手動のクロスチェック（DSQLクラスター・実験用VPC・実験用IAMロール・オープンなSpotリクエスト0個）を完了しました。