📝 3行まとめ

DictSQLiteが高機能化で破綻したので、シンプルで速いNanaSQLiteをゼロから作り直した
「とりあえずRustにすれば速くなる」と思っていたら逆に遅くなった失敗をした
ベンチマーク計測でボトルネックを特定してから改善したら、バッチ処理が19.9倍速になった

🔗 公式サイト: https://nanasqlite.disnana.com/
🐙 GitHub: https://github.com/disnana/nanasqlite

はじめに

「SQLiteをdictで使えるライブラリを作ろう」——そのシンプルな動機から始まったDictSQLiteは、気づけば誰も幸せにしないモンスターになっていました。

そこからNanaSQLiteを作り直す中で、設計の失敗とRustの罠という2つの痛い経験をしました。
この記事は「なぜ作り直したか」「なぜRustで失敗したか」「どう立て直したか」の開発記録です。

1. DictSQLiteが破綻した理由

DictSQLiteの当初のコンセプトはシンプルでした。

db["key"] = "value"  # これだけでSQLiteに保存したい

しかし機能追加を重ねるうちに、こうなりました。

db = DictSQLite(
    "data.db",
    encryption_key="secret",
    cache_size=1000,
    journal_mode="WAL"
)

with db.transaction():
    db.set("key", "value", encrypt=True)

気がついたら「重い・複雑・バグが多い」ライブラリができあがっていた。問題を整理すると以下の通りです。

問題	具体的な症状
重い	暗号化・複雑な最適化処理がオーバーヘッドになる
複雑	オプションが多すぎて使い方がわからない
不具合	機能間の相互作用でバグが頻発
学習コスト	ドキュメントを読まないと動かせない

「ただSQLiteをdictで使いたいだけ」なのに、こんなに難しくする必要があったのか？
その問いがNanaSQLiteの出発点でした。

2. 「とりあえずRustで高速化」は失敗した

最初の作り直しでは、「コア部分をRustで書けば解決する」と安直に考えていました。

失敗談：Rustにすれば無条件に速くなるわけではない

ボトルネックを計測せず、コア部分をRustで実装した結果、PythonとRust間のFFI（外部関数インターフェース）のオーバーヘッドが支配的になり、純粋なPython実装より処理速度が悪化しました。「速い言語を使う」だけでは速くならないことを身をもって体験しました。

原因は明快でした。データのやり取りのたびに発生するPython↔Rustの型変換コストが、Rustの高速化メリットを上回っていたのです。

3. 計測駆動で作り直したNanaSQLiteのアーキテクチャ

反省を踏まえ、今回は**「計測→特定→改善→再計測」**のサイクルを徹底しました。

設計の優先順位を変えた

DictSQLite: 高機能 → 複雑 → 重い
NanaSQLite: シンプル → 速い → 使いやすい

あえて削除した機能と、追加した機能を明確に決めました。

削除したもの（意図的に）

❌ pickleシリアライズ（セキュリティリスクの排除）
❌ 複雑な最適化オプション（設定不要にする）
❌ 高度なトランザクション管理

追加したもの

✅ JSON自動シリアライズ（安全・他言語との互換性）
✅ 即時永続化（書いた瞬間にSQLiteへ保存）
✅ スマートキャッシング（遅延ロード・一括ロードの切り替え）
✅ async/await完全対応（Discord bot・FastAPIへの組み込みを想定）
✅ Pydanticサポート
✅ セキュリティ機能（strict_sql_validation, ReDoS対策）

内部の速度を支えるSQLite設定

-- 設定不要で自動適用される最適化
PRAGMA journal_mode=WAL;       -- 並行書き込みを可能にする
PRAGMA synchronous=NORMAL;     -- 安全性と速度のバランス
PRAGMA mmap_size=268435456;    -- 256MBメモリマップで高速化
PRAGMA cache_size=-64000;      -- 64MBキャッシュ
PRAGMA temp_store=MEMORY;      -- 一時領域はメモリに

これらを自動適用することで、ユーザーは何も意識しなくても最適化された状態で使えます。

標準のsqlite3ではなく、低レベル高速バインディングのapswを採用しているのも速度の要因のひとつです。

Rustを「使う箇所だけ」に絞った

前回の失敗を踏まえ、今回はプロファイラで計測して本当にFFIオーバーヘッドに見合う箇所のみにRustを採用しました。「とりあえず全体をRust化」ではなく、ピンポイントで効かせる設計です。

4. ベンチマーク結果

同一環境（Windows 11、Python 3.11、SSD）でDictSQLiteと比較した結果です。

操作	DictSQLite	NanaSQLite	倍率
初期化	84.88ms	11.00ms	⚡ 7.7倍速
単純書き込み（1000件）	101.08ms	110.86ms	ほぼ同等
バッチ書き込み（1000件）	88.88ms	4.47ms	⚡ 19.9倍速
読み取り（1000件）	31.17ms	19.25ms	⚡ 1.6倍速
一括ロード＋読み取り	—	3.78ms	—
ネストデータ（100件）	10.02ms	8.84ms	⚡ 1.1倍速
混合操作（1500操作）	101.80ms	123.62ms	0.8倍

単純書き込みと混合操作はDictSQLiteと同等〜若干遅い

1件ずつの書き込みは、SQLiteのトランザクションオーバーヘッドが支配的なため速度差が出にくいです。大量データにはbatch_update()を必ず使ってください。

スループット比較

操作	DictSQLite	NanaSQLite
バッチ書き込み	11,251件/秒	223,494件/秒
読み取り（遅延ロード）	32,079件/秒	51,961件/秒
読み取り（一括ロード）	—	4,570,384件/秒

なぜバッチ処理でここまで差が出るのか

# DictSQLite — 1件ずつ処理するたびに余分なロジックが走る
for key, value in data.items():
    # 暗号化チェック → pickle/JSON判定 → トランザクション管理 → 保存
    db[key] = value

# NanaSQLite — JSON一括変換 → SQLite一括INSERTで直行
db.batch_update(data)

余計な判定処理を削ぎ落としたことで、バッチ処理時のオーバーヘッドが激減しました。
「機能を削る」ことがパフォーマンス向上に直結した典型例です。

5. 実装例

基本的な使い方（3行）

from nanasqlite import NanaSQLite

db = NanaSQLite("myapp.db")
db["user"] = {"name": "Nana", "age": 20, "tags": ["admin"]}
print(db["user"]["name"])  # 'Nana'

Pydanticモデルと組み合わせる

from pydantic import BaseModel
from nanasqlite import NanaSQLite

class User(BaseModel):
    name: str
    age: int

with NanaSQLite("app.db") as db:
    db.set_model("user_1", User(name="Nana", age=20))
    user = db.get_model("user_1", User)
    print(type(user))  # <class 'User'>  型付きで返ってくる

Discord bot / FastAPIでの非同期対応

from nanasqlite import AsyncNanaSQLite
import asyncio

async def main():
    async with AsyncNanaSQLite("bot.db", max_workers=10) as db:
        await db.aset("guild_123", {"prefix": "!", "lang": "ja"})
        config = await db.aget("guild_123")
        print(config)

asyncio.run(main())

6. 開発環境

pip install nanasqlite

1日で集中開発し、以下を整備してリリースしました。

pytest による自動テスト完備
GitHub Actions によるCI/CD（push → 自動テスト → PyPI自動デプロイ）
Dependabot によるライブラリの自動更新

実際に自分が運営しているDiscordボット・VPSホスティングサービス「Disnana」の本番環境でも使用中です。

おわりに

DictSQLiteでの設計的な失敗、無計画なRust化での速度悪化、その2つの失敗があったからこそNanaSQLiteは生まれました。

「シンプルにすること」と「機能を削ること」は勇気が要りますが、それが最大のパフォーマンス改善につながるという実感を得られた開発でした。

「SQLiteをdictで使いたいだけ」な方は、ぜひ触ってみてください。

🔗 公式サイト: https://nanasqlite.disnana.com/
🐙 GitHub: https://github.com/disnana/nanasqlite （Starいただけると泣いて喜びます！）