Day 6: 総合プロジェクト - 解説

MiniDBの設計原則

1. Arc + Mutex パターンの深堀り

pub struct MiniDB<K, V> {
    data: Arc<Mutex<HashMap<K, V>>>,
}

この一行に、Rustの並行処理の全てが凝縮されています。

レイヤー構造の理解

MiniDB (ユーザーインターフェース)
  │
  └─ Arc (共有所有権)
       │
       └─ Mutex (排他制御)
            │
            └─ HashMap (データ)

各レイヤーの役割:

• HashMap: 実際のデータを格納
• Mutex: データへのアクセスを排他制御（同時に1つのスレッドのみ）
• Arc: Mutexをスレッド間で共有
• MiniDB: 使いやすいAPIを提供

なぜこの順序なのか？

// ❌ 間違った順序
Arc<HashMap<K, Mutex<V>>>  // 各値にMutex → オーバーヘッド大

// ✅ 正しい順序
Arc<Mutex<HashMap<K, V>>>  // HashMap全体をMutex → シンプル

理由:

• HashMap全体を1つのMutexで保護することで、ロック管理がシンプル
• 各値に個別のMutexを持つと、ロックの取得/解放が頻繁に発生

2. 型パラメータとトレイト境界

impl<K, V> MiniDB<K, V>
where
    K: Eq + Hash + Clone,
    V: Clone,
{
    // メソッド
}

なぜこれらのトレイト境界が必要か？

K: Eq + Hash

HashMapは内部でハッシュテーブルを使用するため、キーは以下の条件を満たす必要があります：

// Hashトレイトが必要
let hash_value = hash(key);  // キーからハッシュ値を計算
let index = hash_value % bucket_count;  // バケットのインデックスを決定

// Eqトレイトが必要（ハッシュ衝突時の比較）
if existing_key == new_key {  // 同じキーか確認
    // 値を上書き
}

K: Clone

updateメソッドで使用：

pub fn update(&self, key: &K, value: V) -> bool {
    let mut map = self.data.lock().unwrap();
    if map.contains_key(key) {
        map.insert(key.clone(), value);  // ← ここでCloneが必要
        true
    } else {
        false
    }
}

借用&Kから所有権を持つKを作るため、Cloneが必要です。

V: Clone

getメソッドで使用：

pub fn get(&self, key: &K) -> Option<V> {
    let map = self.data.lock().unwrap();
    map.get(key).cloned()  // ← ここでCloneが必要
}

HashMapは&Vを返しますが、ロックを解放後も値を使えるようにするため、値をクローンして返します。

3. 内部可変性パターン

pub fn insert(&self, key: K, value: V) {
    // &self なのに内部を変更できる！
    let mut map = self.data.lock().unwrap();
    map.insert(key, value);
}

内部可変性とは？

通常のRustのルール:

• &self → 読み取り専用
• &mut self → 書き込み可能

しかしMutexは内部可変性を提供：

• &self でもMutexを通じて内部を変更可能

なぜこれが重要か？

// ❌ &mut self を使う設計
let mut db = MiniDB::new();
db.insert("key", "value");  // &mut self が必要

// 並行処理で問題:
let db_clone = db.clone();
thread::spawn(move || {
    db_clone.insert(...);  // エラー: &mut が必要だがクローンは不可
});

// ✅ &self を使う設計
let db = MiniDB::new();
db.insert("key", "value");  // &self で OK

// 並行処理で動作:
let db_clone = db.clone();
thread::spawn(move || {
    db_clone.insert(...);  // OK: &self だけでOK
});

4. Clone実装の妙

impl<K, V> Clone for MiniDB<K, V> {
    fn clone(&self) -> Self {
        MiniDB {
            data: Arc::clone(&self.data),
        }
    }
}

Arc::cloneは何をしているか？

初期状態:
MiniDB { Arc { count: 1, data: HashMap } }

db2 = db1.clone() 後:
MiniDB { Arc { count: 2, data: HashMap } }  ← db1
             ↑
             └─ 同じArcを指す
             ↓
MiniDB { Arc { count: 2, data: HashMap } }  ← db2

重要なポイント:

• HashMapはコピーされない（同じインスタンスを共有）
• 参照カウントが増えるだけ（高速）
• スレッド間で同じデータを共有

5. ロックのスコープ管理

// ❌ 悪い例: ロックを長時間保持
pub fn bad_method(&self) {
    let mut map = self.data.lock().unwrap();
    // 長い処理...
    expensive_operation();  // ロックを保持したまま
    map.insert(key, value);
}

// ✅ 良い例: ロックを最小限に
pub fn good_method(&self) {
    // 長い処理を先に実行
    let value = expensive_operation();

    // ロックを取得
    {
        let mut map = self.data.lock().unwrap();
        map.insert(key, value);
    }  // すぐにロック解放
}

RAIIパターン:

MutexGuardはDropトレイトを実装しているため、スコープを抜けると自動的にロックが解放されます：

{
    let guard = mutex.lock().unwrap();  // ロック取得
    // guardを使用
}  // ← ここで自動的にロック解放（Dropが呼ばれる）

メンタルモデル：設計の考え方

1. 型で不変条件を表現

// 型がAPIの制約を表現
pub struct MiniDB<K, V> {
    data: Arc<Mutex<HashMap<K, V>>>,  // 常にスレッドセーフ
}

// K: Eq + Hash → HashMapのキーとして使える保証
// V: Clone → 値を返せる保証

型システムが以下を保証：

• コンパイル時にスレッド安全性を検証
• 不正な操作は型エラーになる
• ランタイムチェック不要

2. APIの対称性

// 対称的なAPI設計
pub fn insert(&self, key: K, value: V)       // 所有権を受け取る
pub fn get(&self, key: &K) -> Option<V>      // 借用で検索
pub fn remove(&self, key: &K) -> Option<V>   // 借用で削除
pub fn update(&self, key: &K, value: V) -> bool  // 借用＋所有権

設計の一貫性:

• insert: 新しいデータ → 所有権を渡す
• get, remove, update: 既存データ → キーを借用

3. エラー処理の段階

// レベル1: Option（キーの存在）
pub fn get(&self, key: &K) -> Option<V>

// レベル2: Result（操作の成功/失敗）
pub fn get_checked(&self, key: &K) -> Result<V, DBError>

// レベル3: panic（回復不可能なエラー）
let map = self.data.lock().unwrap();  // poison時はpanic

使い分け:

• Option: 通常の失敗（キーがない等）
• Result: エラー詳細が必要
• panic: システムエラー（Mutexがpoison等）

パフォーマンス考察

1. ロック競合の分析

10スレッドが同時にアクセス:

スレッド1  ──┬──→ [ロック待ち] ──→ 処理
スレッド2  ──┼──→ [ロック待ち] ──→ 処理
スレッド3  ──┼──→ [ロック待ち] ──→ 処理
スレッド4  ──┘
   ...

ボトルネック: Mutexのロック取得

改善案:

// Sharding: 複数のMutexに分散
pub struct ShardedDB<K, V> {
    shards: Vec<Arc<Mutex<HashMap<K, V>>>>,
}

// キーのハッシュ値でシャードを選択
fn get_shard(&self, key: &K) -> &Arc<Mutex<HashMap<K, V>>> {
    let hash = calculate_hash(key);
    &self.shards[hash % self.shards.len()]
}

効果:

• 4シャード → 4倍の並行性
• ロック競合が劇的に減少

2. RwLockによる最適化

// 読み取りが多い場合
use std::sync::RwLock;

pub struct ReadOptimizedDB<K, V> {
    data: Arc<RwLock<HashMap<K, V>>>,
}

impl<K, V> ReadOptimizedDB<K, V> {
    pub fn get(&self, key: &K) -> Option<V> {
        let map = self.data.read().unwrap();  // 複数同時OK
        map.get(key).cloned()
    }

    pub fn insert(&self, key: K, value: V) {
        let mut map = self.data.write().unwrap();  // 排他的
        map.insert(key, value);
    }
}

ベンチマーク結果（読み取り90%、書き込み10%）:

実装	スループット
Mutex	100,000 ops/sec
RwLock	450,000 ops/sec

3. メモリオーバーヘッド

Arc<Mutex<HashMap>>のメモリレイアウト:

┌─────────────────────────┐
│ Arc ヘッダー            │  16 bytes (strong_count, weak_count)
├─────────────────────────┤
│ Mutex ヘッダー          │  8 bytes (lock state)
├─────────────────────────┤
│ HashMap                 │
│  - capacity            │  8 bytes
│  - len                 │  8 bytes
│  - buckets             │  depends on size
└─────────────────────────┘

合計オーバーヘッド: 約40 bytes + HashMap自体

実世界への応用

1. プロダクションデータベースとの比較

MiniDB vs Redis:

機能	MiniDB	Redis
データ構造	HashMap	20+ 種類
永続化	なし	RDB/AOF
レプリケーション	なし	Master-Slave
スケーリング	単一サーバー	クラスタ
メモリ効率	Arc/Mutex	jemalloc

2. 拡張への道筋

段階的な進化:

Phase 1: MiniDB
  ├─ 基本CRUD
  └─ スレッドセーフ

Phase 2: Persistent DB
  ├─ ファイル保存
  ├─ WAL
  └─ クラッシュリカバリ

Phase 3: Distributed DB
  ├─ ネットワーク通信
  ├─ レプリケーション
  └─ Raftコンセンサス

Phase 4: Production DB
  ├─ クエリ最適化
  ├─ インデックス
  └─ トランザクション

セルフチェック質問

基礎レベル

• Q: なぜArc>ではなくMutex>ではないのか？

• Q: getメソッドがOptionではなくOption<&V>を返せないのはなぜ？

中級レベル

• Q: Clone for MiniDBでデータがコピーされないのはなぜ？

• Q: なぜ&selfで内部を変更できるのか？

上級レベル

• Q: Mutexがpoisonされるのはどんな時？

• Q: RwLockの方が常に高速か？

次のステップ

Rust Piscineを完了したあなたは、以下の道を選べます：

• Rust Electives: 実践的なアプリケーション開発
• Rust Deep Dive: async/await、マクロ、unsafe
• OSS貢献: Rustエコシステムへの貢献
• プロダクション開発: 実務でRustを使用

おめでとうございます！あなたはRustaceanです！

最後に

Rustを学ぶことは、単に新しい言語を学ぶことではありません。それはプログラミングの考え方を変えることです：

• 所有権で考える
• 型で保証する
• コンパイラを信頼する
• 安全に並行処理する

これらの概念は、他の言語でも活かせる普遍的なスキルです。

Happy Rusting!