← 2026-07-05 の一覧へ戻るホーム
監視しなくても済む DB パーティションの設計

2026/07/01 22:05

監視しなくても済む DB パーティションの設計

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

本テキストは、単調増加のプライマリキー（

id
）をパーティショニング戦略として使用することが、PostgreSQL および MySQL の急速に成長するテーブルにおいて、タイムスタンプベースのアプローチ（例：
created_at
）よりも優れていると論じています。静的な時間ベースの戦略とは異なり、それは深刻なパフォーマンス劣化を引き起こすことがあり、インデックスプローブが 1 から 36 に跳躍したり、高価なマルチカラムユニーク制約を強いるなどの例があります。一方、増加する ID は定数時間のルックアップを保証し、スキーマ設計を簡素化します。現在のツールはしばしば固定された時間境界を仮定しており、その結果、アプリケーションロジックがこれらの限界をクエリに漏洩させる傾向があります。これに対し、ID ベースのアプローチは、ライフサイクルサービスに対して時間整合的な境界を動的に導出することを可能にします（例：
SELECT MAX(id)
）。これにより、キャッチオールパーティションが満杯になる前に前もって分割し、保持ウィンドウに基づいて古いデータを削除することができます。さらに、これは高コストな操作である 
ALTER TABLE ... REORGANIZE
の必要性を排除し、ワークロードの不平衡を防ぎ、ダウンタイム調整を回避しながら、アプリケーションロジックに時間をハードコーディングすることなくスケーラブルなパフォーマンスを確保します。

本文

データベース建築設計：パーティショニング戦略と運用管理

背景：成長によるボトルネック

サービス開始 6 ヶ月後、

p_future
パーティションに 8 億行のデータが蓄積しています。これを修正する 
ALTER
操作はメンテナンスウィンドウが必要です。特に重要な課題は、アプリケーションコードへの 「パーティションキー」の漏洩を防ぐ適切な設計です。

TL;DR（要点）

  • パーティションキー: 
    created_at
    を使わない。プライマリキーを使用すること。
  • 境界管理: 背景サービスで観測された成長に基づいて動的に行うこと。
  • クエリ方針: 元々存在するキー（通常は ID）を使い続け、パーティションプルーニングを自動的に機能させる。
  • 設計思想: パーティションカラムをアプリケーションコードに露出させない。

「Orders ダッシュボード」のパフォーマンス問題

問題の発覚と原因

パーティショニング導入後、オーダーダッシュボードの読み込みが大幅に遅くなりました。

  • 疑点: 新しいインデックス戦略への問題。
  • 真相: 
    EXPLAIN
    で明らかになったパーティションプルーニングの失敗。
    • クエリ: 
      SELECT * FROM orders WHERE id = 12345
    • 実行計画:36 ページのパーティション (
      orders_p2025_01
      , 
      ...
      ) が全て読み込まれた。
    • 原因: 
      WHERE
      条件にパーティションキー（日付）が含まれていないため。

パターン化した問題と解決策

  • 暫定対策: クエリに 
    created_at >= 'YYYY-MM-DD'
    を追加する。
    • 結果: 実行計画が 1 つのパーティションに絞り込まれる。
  • 組織的な対応:
    • マイグレーションスクリプトや監査ページでも同様のフィルタ追加が必要になる。
    • 内部リンター規則として「日付フィルタなしの SELECT を検知」を導入。
    • コードレビューで「パーティションフィルターを追加したか？」がチェック項目に。

結論: パーティションキーはストレージ設計の選択ではなく、全てのクエリに対する契約となります。これを忘れた場合はエラーにならず、ただ「遅いだけ」という状態になります。

パーティションキーの問題点

PostgreSQL および MySQL において、パーティションキーはテーブルの プライマリキーまたはユニーク制約の一部である必要があります。プライマリキーが単一（例: 

id
）の場合、データベースは一意性を保証できず全パーティションをスキャンせざるを得ません。

プライマリキーを変更することの影響

created_at
でパーティション化する場合、PK を 
(id, created_at)
に変更する必要があります。

  • 影響 1: ID の一意性の喪失

    • PK が 
      (id, created_at)
      となるため、同じ 
      id
      でも異なる日付であれば重複として扱われます。
    • アプリケーション側で単一 
      id
      を保証することもスキーマ上はなくなります。
    • UNIQUE (id)
      制約を追加できず、一意性が事実上放棄されます。

  • 影響 2: 実行計画の劣化（Const → Ref）

    PK 定義ルックアップタイプ性能特性
    PRIMARY KEY (id)
    		const定数時間。最適化器は正確に 1 行を把握し即座に停止。結合は「eq_ref」（最速）。
    PRIMARY KEY (id, created_at)
    		ref左端のインデックスカラムによるプレフィックススキャン。複数の行が返る可能性があるため、「eq_ref」から「ref」へ退化。

  • 影響 3: クエリ条件の必須化

    • WHERE id = 1
      のようなクエリでは、以前は 1 行の即座ヒットでしたが、現在は単なる範囲検索となります。
    • 元に戻すには 
      AND created_at = '...'
      を追加する必要があり、これがパーティションプルーニングからの漏洩と本質的に同じ現象です。

スキーマ変化比較

【パーティショニング前】

CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,  -- 単一 ID で一意性を保証
    customer_id BIGINT NOT NULL,
    total_cents INT NOT NULL,
    created_at DATETIME NOT NULL
);
-- 結果: WHERE id = 1 は const ルックアップで即座に完了

【パーティション化後（日付基準）】

CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT,                 -- 一意性を保証せず
    customer_id BIGINT NOT NULL,
    total_cents INT NOT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id, created_at)              -- created_at が PK に強制
)
PARTITION BY RANGE (TO_DAYS(created_at)) (
    PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
    ...
);

パーティションプルーニングは要求しないと機能しない

パーティションプルーニングが機能するのは、クエリの 

WHERE
条件にパーティションキーが含まれている場合のみです。

  • 機能する場合: 
    WHERE id = 12345 AND created_at >= '...'
    → 対象の 1〜2 つのパーティションのみ読み取り。
  • 機能しない場合: 
    WHERE id = 12345
    → 全てのパーティション（例: 36 ページ）をスキャン。

リスク: プルーニングが行われない場合、正しい結果が返されるだけです。例外も警告も発生せず、アプリケーションログに何も表示されません。「ただ遅いだけ」ですが、ダッシュボードのタイムアウトやスロークエリログのレビューを通じて問題が発覚します。

静的なパーティション境界は経年で機能しない

テーブル作成時にハードコードした境界は、半年後のトラフィック変化に対応できなくなります。

  • 初期状態: 
    p_future
    がキャッチオールとして想定内の成長を吸収。
  • 6 ヶ月後: 成長加速により、
    p_future
    に 8 億行が蓄積され、実働の半分を占める事態に。
-- 現状（問題発生）
PARTITION p_future VALUES LESS THAN MAXVALUE -- 8 億行、増え続けている

-- 手動再平衡の難しさ
ALTER TABLE ... REORGANIZE PARTITION ... 
-- ・数百ギバイトのテーブルをロックする必要がある
-- ・アプリケーションチームとの調整が必要
-- ・パフォーマンスインシデント発生後に修復すると莫大なコスト

より良いアプローチ：プライマリキーを活用した範囲パーティショニング

戦略：ID をパーティションキーとする

BIGINT AUTO_INCREMENT
は単調増加するため、プライマリキーそのものが最適のパーティションキーとなります。

CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,   -- ★パーティションキー候補
    customer_id BIGINT NOT NULL,
    total_cents INT NOT NULL,
    created_at DATETIME NOT NULL
)
PARTITION BY RANGE (id) (                   -- ★ID で範囲区切りの定義
    PARTITION p0001 VALUES LESS THAN (100000000),
    PARTITION p0002 VALUES LESS THAN (200000000),
    ...
    PARTITION p_future VALUES LESS THAN MAXVALUE -- ★キャッチオール
);
  • メリット: アプリケーションコードを変更せずに、ID ベースのクエリが自動的にプルーニングされる。
  • トレードオフ: 時間ベース（月単위）の境界定義は消失する。しかし、パーティショニングの主目的はインデックスサイズの管理と保守コストの低減であるため、これは致命的ではない。

範囲パーティション管理の自動化

範囲パーティショニングでは、アクティブなパーティションが満杯になる前に自動的に分割し、保留ポリシーに基づいて古いデータをドロップします。

自動化サービスの役割

  • 棚卸し: カタログから現在のレイアウトを読み取る。
  • サイズチェック: キャッチオールパーティション (
    p_future
    ) が閾値を超えたか確認。
  • 境界選択: 時間整合のパーティションへする場合、
    SELECT MAX(id) WHERE created_at < X
    で適切な境界を探す。
  • 分割 (REORGANIZE): キャッチオールを新しい有界パーティションと、新しいキャッチオールに再定義する。 
    -- メタデータ変更のみ（高速）
ALTER TABLE orders REORGANIZE PARTITION p_future INTO (
    PARTITION p0037 VALUES LESS THAN (3700000000),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);
  • 保留プルーニング: 保留ウィンドウを過ぎたパーティションを 
    DROP
    で削除。
  • 並行性ガード: DDL 実行時の競合防止と、失敗時のクリーンな回復（冪等性）を保証。

本番環境で難しい理由

  • REORGANIZE
    中に書き込みをロックしない設計が必要。
  • サービスクラッシュや同時マイグレーションへの耐性が求められる。
  • ロジック自体は簡単だが、運用のブリケット部分（エラーハンドリング、監視）に多くの労力が要る。

キーに日付を持たせない時間に基づく境界

「時間ベースのパーティショニング」＝

created_at
を PK にするわけではありません。事後で境界を計算します。

  • 手法: 
    SELECT MAX(id) FROM orders WHERE created_at < '2026-03-01'
    で、日付境界に相当する ID 範囲を取得。
  • 実装: その ID を基準として 
    REORGANIZE
    を実行し、パーティション名は時系列（例: 
    p2026_03
    ）を付けて管理。
-- ID レンジで定義だが、論理的な時間境界と整合
ALTER TABLE orders REORGANIZE PARTITION p_future INTO (
    PARTITION p2026_03 VALUES LESS THAN (3700842140),  -- ※計算された ID 境界
    PARTITION p_future VALUES LESS THAN MAXVALUE       -- 新しいキャッチオール
);
  • 結果:
    • パーティション名や保留ポリシーは時間ベース。
    • アプリケーションコードには 
      created_at
      を含めず、プルーニングも ID ベースで行うため透明性が高い。

他のパーティショニング戦略への適用

ハッシュパーティショニング

  • 自動化の目的: 境界調整ではなく、スーク（ホットスポット）の検出。
  • 手法: パーティションごとの成長率を追跡し、低基数カラムによる不均衡を早期に表面化させる。
  • 注意点: パーティション数を増やす操作はテーブル全体の再構築を伴うため、自動化で境界調整を行うのは不適切。適宜人間が判断して形状変更（
    OPTIMIZE
    など）を行う。

リストパーティショニング

  • 手法: デフォルトのキャッチオールパーティション内に新値（例: 新しいテナント）が増加した場合、独自パーティションへ「プロモート」する。 
    ALTER TABLE events REORGANIZE PARTITION p_default INTO (
    PARTITION p_tenant_108 VALUES IN (108),
    PARTITION p_default VALUES IN (DEFAULT)
);

結論：パーティションキーに入れるべきこと

どの戦略を採用する前に、**「全てのクエリで既に使われているカラムは何ですか？」**を問うべきです。

  • OLTP システム: 答えは通常プライマリキー (ID) です。これを使えば無料のプルーニングが可能。
  • マルチテナント: 
    tenant_id
    を PK に含める。
  • 時系列データ: 全てのクエリが日付でフィルタされる場合のみ 
    created_at
    を PK にする（例：TimescaleDB）。

警告: 既に使われているカラムではないカラム（例: 

created_at
）を無理に PK にしてパーティショニングすると、アプリケーションコード全体に 
AND created_at >= ?
というフィルタを追加を強いることになり、オーバーヘッドが発生します。 既存のクエリに追加するよりも、小さい DDL サービスによる動的な管理の方がコストは安価です。

同じ日のほかのニュース

一覧に戻る →

2026/07/05 8:41

鼻スプレーで脳の老化を逆転させることに成功した科学者たち

## Japanese Translation: テックス大学医学部ナーシュ K.ヴァシスト医学部の画期的な研究、アショーク・シェッティ医師をリーダーとし、再生医療研究所の下でマドフ・リラヴァーティ・ナラーヤナ氏とマハエダール・コダーリ氏といったシニア研究者が含まれたこの研究は、単純な 2 回投与の鼻スプレーが神経炎症性を逆転させ、脳機能を回復させることを示している。同研究は「細胞外小胞ジャーナル」（15(2): e70232, 2026）に発表され、数週間で炎症低減を示し、効果は数ヶ月持続することが確認された。治療法では、血脳関門を手術なしで回避しながらマイクロ RNA を直接脳組織へ届ける細胞外小胞（EVs）を使用している。細胞レベルにおいて、この治療は神経細胞のミトコンドリアを「充電」し、酸化ストレスを軽減すると同時に、NLRP3 インフラマソームおよび cGAS-STING シグナル経路といった炎症経路を抑制した。行動学試験では、対照群と比較して親しみのある物体を認識する能力や新たな環境を検出する能力に顕著な改善が確認された。シェッティ医師は、その成果が性別間で一貫性があり類似しており、このアプローチを「普遍的」と表現した。国立老人研究所（NIA）による支援を受けながら、特許出願が提出され、これは侵襲的な処置や月単位の薬物療法に代わる最小限の投与 regimes に向けた画期的な進歩を示している。2020 年の約 51 万4000 件から 2060 年には約 100 万件へと倍増するとの予測を踏まえれば、新たな認知症患者数の増加が待つのであり、このタイミングでの進展は意義深いが、世界規模で増大しつつある認知障害の負担を軽減しながら、従来の介入に伴うリスクを最小限に抑えるための変革的な一歩を提供している。

2026/07/05 4:41

Fable を用いた Command & Conquer: Generals の macOS、iPhone、iPad 向けネイティブ移植

## Japanese Translation: Zero Hour は、Apple Silicon Mac、iPhone および iPad 向けに公式ネイティブアプリケーションとして利用可能となり、DirectX 8 エンジンを Metal に変換する堅牢な翻訳パイプラインを採用しており、エミュレーションを必要とせずに動作します。このポータブルは fbraz3 が作成した GeneralsX プロジェクトを基盤とし、タップ選択、ドラッグボックス選択、ピンチによる拡大縮小など、基本的なタッチ操作を統合しています。macOS へのインストールには、外部的アセット（約 2.7 GB のバンドル）を抽出するために Steam コピーの所有が必要ですが、iOS バージョンはこれらのアセットがアプリケーションバンドル内に含められており、独立した体験を実現しています。開発プロセスには、Ammaar Reshi の指揮のもとで Claude Code が大幅な工数を投入し、MoltenVK や GPL v3 ライセンス付きコードなどのオープンソースツールを活用して、レガシーの PC アーキテクチャと最新の ARM64 ハードウェアを接続しました。Xcode 設定や特定のビルドスクリプトなどインストール前提条件が関わりますが、ユーザーはモバイルデバイス上で高性能の実時間戦略ゲームプレイを楽しむことができます。ただし、iOS ユーザーは長時間セッション中の潜在的なメモリ制限や、稀なバックグラウンド化時クラッシュについて留意する必要があります。

2026/07/05 6:51

GPT-5.5 Codex の推論トークンクラスタリングが性能低下を引き起こしている可能性があります

## Japanese Translation: 分析の結果、Codex ファミリーにおいて GPT-5.5 に特有の重大な異常が判明した。2026 年 2 月と 6 月 27 日の間、865 セッションから抽出された 390,195 トークン記録を検査したところ、GPT-5.5 の応答は過剰に正確な 516 トークンで終了する傾向があり、さらに 1034 トークンおよび 1552 トークンを周辺にクラスタリングしていた。GPT-5.5 は全応答の 19.3% に過ぎないにもかかわらず、正確な 516 トークンでのイベントの 82% を引き起こしており、非 GPT-5.5 モデルで観察されたレートと比較して約 33.6 倍高い。他のバージョン（GPT-5.4、GPT-5.2、および一部の GPT-5.3 バリエーション）では、これらの固定境界でのクラスタリングは著しく小さい。このパターンは分析深度の大幅な低下と相関しており、平均的な推論トークン強度は 2 月には 268.1 から 5 月には 107 トークン未満まで減少し、P90 も 772 から 344 トークンへと低下した。この異常は、GPT-5.5 の実行が正確な 516 トークンで終了する場合に複雑なコーディングタスクに対して誤った回答を返す過去の問題と関連している。固定トークン数でのクラスタリングは自然な変動ではなく閾値境界に似ており、推論予算のカップ、アクティブルーティングによる截断、スケジューラーの制限、または GPT-5.5 に特有のその他の内部閾値がある可能性を示唆している。この行動はEarlier モデルとの比較で severe な能力低下を示しており、高リスクなプログラミングシナリオにおける GPT-5.5 ファミリーの有用性を制限する可能性がある。専門家からは、これが劣化したサービス階級なのか、特定の内部ロジックなのか、またはその他の原因なのかを明らかにするために即時の調査を要請し、モデルと値ごとにトークンカウントイベントを照会して正確な値の数を比較したり、異なる GPT バージョンで複雑なタスクを再現するたり、正確な 516 トークンの応答とより長い推論出力を分離して行う品質評価を実施するなど、検証手順が提案されている。

監視しなくても済む DB パーティションの設計 | そっか～ニュース