HarborDB パフォーマンス最適化ガイドへようこそ。この包括的なリソースは、効率的なクエリの記述から、最大のパフォーマンスを得るための HarborDB と macOS の設定まで、PostgreSQL ワークフローのあらゆる側面を最適化するのに役立ちます。

パフォーマンス要因の理解

HarborDB でのデータベースパフォーマンスに影響する要因はいくつかあります：

| 要因 | 影響度 | 最適化レベル | | ---------------------------- | ---------- | ------------------ | | クエリ設計 | 高い | アプリケーション | | データベースインデックス | 高い | データベース | | ネットワーク接続 | 中程度 | インフラストラクチャ | | システムリソース | 中程度 | macOS | | HarborDB 設定 | 低～中程度 | アプリケーション | | PostgreSQL 設定 | 高い | データベース |

クエリ最適化

効率的なクエリの記述

1. 必要なものだけを選択する

-- ❌ 非効率
SELECT * FROM customers;

-- ✅ 効率的
SELECT customer_id, name, email FROM customers;

2. WHERE 句を効果的に使用する

-- ❌ 非効率（全テーブルスキャン）
SELECT * FROM orders
WHERE EXTRACT(YEAR FROM order_date) = 2024;

-- ✅ 効率的（インデックスを使用）
SELECT * FROM orders
WHERE order_date >= '2024-01-01'
  AND order_date < '2025-01-01';

3. 結果セットを制限する

-- 探索時は常に制限する
SELECT * FROM large_table LIMIT 100;

-- 大規模な結果にはページネーションを使用
SELECT * FROM products
ORDER BY created_at DESC
LIMIT 50 OFFSET 0;

4. N+1 クエリ問題を避ける

-- ❌ 非効率（複数クエリ）
-- 最初のクエリ: SELECT * FROM orders WHERE status = 'pending'
-- 各注文に対して: SELECT * FROM customers WHERE customer_id = ?

-- ✅ 効率的（JOIN を使用した単一クエリ）
SELECT o.*, c.name, c.email
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.status = 'pending';

EXPLAIN を使用したクエリ分析

HarborDB ではクエリパフォーマンスを簡単に分析できます：

クエリをエディタに記述
ツールバーの 「説明」（⚡）をクリック
実行計画を結果ペインで確認

EXPLAIN 出力の理解

Seq Scan: 全テーブルスキャン（大規模テーブルではしばしば遅い）
Index Scan: インデックスを使用（通常より高速）
Nested Loop: テーブルの結合（適切かどうか確認）
コスト推定: 数値が高いほど作業量が多い

一般的な最適化パターン

-- 不足しているインデックスの提案を追加
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 1234;

-- 結果に表示される可能性: "Seq Scan on orders"
-- 解決策: CREATE INDEX idx_orders_customer_id ON orders(customer_id);

データベースインデックス最適化

インデックスを追加するタイミング

以下のためにインデックスを追加：

主キー（自動的にインデックス付き）
外部キー（しばしば手動でのインデックス付けが必要）
頻繁にフィルタリングされる列
頻繁にソートされる列
JOIN 条件で使用される列

効果的なインデックスの作成

-- 単一列インデックス
CREATE INDEX idx_orders_status ON orders(status);

-- 複数列インデックス（順序が重要！）
CREATE INDEX idx_orders_date_status ON orders(order_date, status);

-- 部分インデックス（特定のサブセット用）
CREATE INDEX idx_active_users ON users(email) WHERE active = true;

-- 制約用の一意インデックス
CREATE UNIQUE INDEX idx_unique_email ON users(email);

インデックスのメンテナンス

-- インデックス使用状況の確認
SELECT schemaname, tablename, indexname
FROM pg_stat_user_indexes
WHERE idx_scan = 0;  -- 使用されていないインデックス

-- 断片化したインデックスの再構築
REINDEX INDEX idx_orders_status;

-- クエリプランナーのための統計情報の更新
ANALYZE orders;

接続最適化

接続プール設定

HarborDB 接続を最適化：

環境設定を開く → 接続
ワークフローに基づいて設定を調整：

| 設定 | 推奨値 | 目的 | | ---------------------- | ----------------- | --------------------------- | | 接続タイムアウト | 30 秒 | ハング接続の防止 | | キープアライブ | 有効 | アイドル接続の維持 | | 最大接続数 | 5-10 | パフォーマンス/メモリのバランス | | SSL モード | Prefer | オーバーヘッドなしで安全 |

ネットワーク最適化

リモートデータベースの場合：

SSH トンネリングを使用 して安全で最適化された接続を実現
大規模な結果セットに圧縮を有効化
負荷の高いクエリをピーク時間外にスケジュール
組み込みツールでネットワーク遅延を監視

-- ネットワーク遅延のテスト
SELECT 1 as test;  -- 往復時間を計測するための単純なクエリ

HarborDB パフォーマンス設定

メモリ管理

環境設定 → パフォーマンス でメモリ使用量を調整：

| 設定 | 推奨 | 影響 | | --------------------- | -------------- | ----------------------------- | | クエリキャッシュ | 256 MB | 繰り返しクエリを高速化 | | 結果セットメモリ | 512 MB | 大規模データセットの処理 | | ストリーミングモード | 有効 | 大規模な結果に適している | | 自動更新 | 30 秒 | 鮮度/パフォーマンスのバランス |

インターフェース最適化

環境設定 → 外観でアニメーションを無効化
自動補完遅延を 100ms に削減
サイドバーの自動展開深度を制限
OLED ディスプレイの効率のためにダークモードを使用

スピード向上のキーボードショートカット

これらの生産性向上ツールをマスター：

| ショートカット | アクション | 節約時間 | | -------- | -------------- | -------------- | | ⌘ + R | クエリを実行 | 2-3 秒 | | ⌘ + . | クエリをキャンセル | 待機を防止 | | ⌘ + T | 新しいクエリタブ | 1-2 秒 | | ⌘ + S | クエリを保存 | 1 秒 | | ⌘ + E | 結果をエクスポート | 2 秒 | | ⌘ + F | クエリ内を検索 | 3-5 秒 |

macOS システム最適化

ハードウェアの考慮事項

メモリ (RAM)

最小: 基本的な使用には 8 GB
推奨: プロフェッショナル作業には 16 GB
最適: 大規模データセットには 32 GB

ストレージ (SSD)

最小: 256 GB の空き容量
推奨: データベースファイルとエクスポート用に 512 GB+
大規模なデータベースストレージには外部 SSD を使用

プロセッサ

Apple Silicon: M1/M2/M3 最適化
Intel: i5 最小、i7/i9 推奨

macOS 設定

省エネルギー（システム環境設定）：
- 「ハードディスクをスリープさせない」を無効化
- 長時間のクエリ中はディスプレイをオンに維持
アクティビティモニタ：
- HarborDB のメモリ使用量を監視
- PostgreSQL プロセスのリソースを確認
ディスクユーティリティ：
- SSD TRIM が有効であることを確認
- ディスクの健全性と空き容量を監視

ターミナルパフォーマンスコマンド

# システムリソースを確認
top -o cpu  # CPU 使用率
vm_stat     # メモリ使用率
iostat      # ディスク I/O

# HarborDB を具体的に監視
ps aux | grep HarborDB
lsof -p $(pgrep HarborDB) | wc -l  # 開いているファイル数

大規模データセット戦略

数百万行の作業

1. サーバーサイドページネーション

-- すべての行を読み込む代わりに
SELECT * FROM huge_table;

-- ページネーションを使用
SELECT * FROM huge_table
ORDER BY id
LIMIT 1000 OFFSET 0;

-- 次のページ
SELECT * FROM huge_table
ORDER BY id
LIMIT 1000 OFFSET 1000;

2. 結果のストリーミング

環境設定 → パフォーマンス で有効化：

✅ 「10,000 行以上の結果でストリーミングを有効化」
✅ 「ストリーミングチャンクサイズ：1000 行」
✅ 「バックグラウンドストリーミング：有効」

3. マテリアライズドビュー

-- 高コストなクエリを事前計算
CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT
    DATE(order_date) as day,
    COUNT(*) as orders,
    SUM(total) as revenue
FROM orders
GROUP BY DATE(order_date);

-- 定期的に更新
REFRESH MATERIALIZED VIEW daily_sales_summary;

エクスポート最適化

大規模なエクスポートの場合：

CSV にエクスポート（JSON より効率的）
チャンクエクスポートを使用（環境設定 → エクスポート）
エクスポートを自動的に圧縮
外部ストレージに直接エクスポート

パフォーマンス監視

組み込み HarborDB ツール

クエリタイマー: ステータスバーに実行時間を表示
メモリモニター: ウィンドウ → パフォーマンスモニターで表示
接続ステータス: リアルタイムネットワークメトリクス
クエリ履歴: 過去のクエリパフォーマンスを確認

PostgreSQL 監視クエリ

-- アクティブなクエリ
SELECT
    pid,
    usename,
    query_start,
    state,
    query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start DESC;

-- 遅いクエリ
SELECT
    query,
    calls,
    total_time,
    mean_time,
    rows
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

-- テーブル統計
SELECT
    schemaname,
    relname,
    seq_scan,
    idx_scan,
    n_tup_ins,
    n_tup_upd,
    n_tup_del
FROM pg_stat_user_tables
ORDER BY seq_scan DESC;

一般的なパフォーマンス問題と解決策

問題: 「クエリに時間がかかりすぎる」

解決策チェックリスト:

[ ] 適切なインデックスを追加
[ ] クエリをより効率的に書き直す
[ ] PostgreSQL 設定を確認
[ ] ネットワーク接続を確認
[ ] 必要に応じてタイムアウト設定を増やす

問題: 「HarborDB がメモリを使いすぎる」

解決ステップ:

クエリキャッシュサイズを減らす（環境設定 → パフォーマンス）
未使用のクエリタブを閉じる
HarborDB を定期的に再起動
メモリリークを確認（アクティビティモニター）
常に制限に達している場合はシステム RAM を増やす

問題: 「エクスポート/インポートが非常に遅い」

最適化のヒント:

JSON の代わりに CSV 形式を使用
ターゲットフォルダのウイルス対策スキャンを無効化
HDD の代わりに SSD にエクスポート
非常に大規模な操作には PostgreSQL ネイティブツール（pg_dump/pg_restore）を使用
大規模な操作を小さなバッチに分割

問題: 「インターフェースがもたつく感じる」

クイック修正:

非常に大規模なクエリではシンタックスハイライトを無効化
サイドバーの自動展開を減らす
よりシンプルな UI テーマを使用
他のリソース集約型アプリケーションを閉じる
HarborDB と macOS を再起動

高度な最適化技術

大規模テーブルのパーティショニング

-- パーティション化されたテーブルを作成
CREATE TABLE orders_partitioned (
    order_id BIGSERIAL,
    order_date DATE NOT NULL,
    customer_id INT,
    total DECIMAL(10,2)
) PARTITION BY RANGE (order_date);

-- パーティションを作成
CREATE TABLE orders_2024_q1 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-01-01') TO ('2024-04-01');

CREATE TABLE orders_2024_q2 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-04-01') TO ('2024-07-01');

クエリプランヒント

-- インデックス使用を強制（注意して使用）
SET enable_seqscan = off;

-- 一時的に作業メモリを増加
SET work_mem = '64MB';

-- 特定の結合方法を使用
SET enable_nestloop = off;
SET enable_hashjoin = on;

PGBouncer を使用した接続プーリング

高同時実行性アプリケーションの場合：

PGBouncer をインストール（Homebrew: brew install pgbouncer）
トランザクションプーリング用に設定
PGBouncer 経由で HarborDB を接続
接続再利用統計を監視

パフォーマンステスト

ベンチマーククエリの作成

-- クエリパフォーマンスのテスト
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31'
  AND status = 'completed'
ORDER BY total DESC
LIMIT 100;

-- 異なるアプローチとの比較
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE status = 'completed'
  AND order_date >= '2024-01-01'
  AND order_date <= '2024-12-31'
ORDER BY total DESC
LIMIT 100;

時間経過による監視

パフォーマンスログテーブルを作成：

CREATE TABLE query_performance_log (
    log_id SERIAL PRIMARY KEY,
    query_hash TEXT,
    execution_time_ms INTEGER,
    row_count INTEGER,
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    notes TEXT
);

-- 遅いクエリをログ記録
INSERT INTO query_performance_log
    (query_hash, execution_time_ms, row_count, notes)
SELECT
    md5(query),
    EXTRACT(MILLISECONDS FROM NOW() - query_start),
    result_rows,
    '遅いクエリを検出'
FROM pg_stat_activity
WHERE state = 'active'
  AND NOW() - query_start > INTERVAL '5 seconds';

ベストプラクティスのまとめ

日次ワークフロー

新しい複雑なクエリは EXPLAIN から始める
データ探索時は LIMIT を使用
未使用の接続を閉じる
HarborDB を定期的に再起動（週次）
負荷の高い作業中はシステムリソースを監視

週次メンテナンス

クエリパフォーマンスログを確認
使用されていないインデックスをチェック
PostgreSQL 統計を更新（ANALYZE）
一時ファイルをクリーンアップ
パフォーマンス設定をバックアップ

月次レビュー

遅いクエリパターンを分析
成長に応じてテーブルパーティショニングを検討
ハードウェア要件を確認
HarborDB と PostgreSQL を更新
パフォーマンス改善を文書化

ヘルプの入手

パフォーマンスチューニングサポート

追加のヘルプが必要な場合：

クエリプランを共有（サポートチームへ）
パフォーマンスログをエクスポート（環境設定 → ログをエクスポート）
システム仕様を含める（macOS バージョン、RAM、ストレージ）
ワークフローと典型的なデータセットサイズを説明

パフォーマンス最適化ガイド