【10万行を瞬殺】三連単オッズでフリーズするSQLiteを覚醒させた「バルクインサート」の限界突破!Alma Core Pro開発記 #6

どうも、アルマコアです！

本業は工場の自動化機械やシーケンサー（PLC・制御盤）の設計に向き合っている、現役の機械エンジニアです。

前回の第5回では、昭和の二重圧縮マトリョーシカ（.zipの中に.lzh）を7-Zipエンジンで全自動解体し、29テーブルへ仕分ける「自動開梱・仕分けコンベア」の構築劇をお話ししました。

「よっしゃ！ これでどんなデータが落ちてきても、ボタン一発でコンベアに乗っかるぞ！」

……と、またしても深夜2時に缶コーヒーを開けて喜びに浸っていた私。

しかし、過去10年分のビッグデータを一括投入した瞬間、モニターの前で完全に凍りつきました。

「……おい、プログレスバーが1ミリも動いてへんやないか！！」

今回は、データ供給コンベアが悲鳴を上げて大渋滞を起こした「SQLiteの書き込みボトルネック」を、機械屋の現場仕込みのチューニングでねじ伏せ、数百万行のデータを瞬殺させた限界突破の舞台裏をお届けします！

1. 搬送コンベアは爆速なのに、プレス機（SQLite）で大渋滞！？

工場の製造ラインでよくあるトラブルに、「搬送コンベアの供給スピードに対して、加工機（プレス機や溶接ロボット）の処理タクトタイムが遅すぎて、手前で製品が山積みになってラインが完全停止する」という現象があります。

まさに、前回の第5回を作ったあとの私のPCの中で、それが起きていました。

二重圧縮の皮むきはバックグラウンドで一瞬で終わる。

29テーブルへのファイル仕分けも、Pythonの辞書を使って瞬時に振り分けられる。

「搬送ライン」は公差±0の完璧なスピードでした。

なのに……いざSQLiteのデータベースへ書き込もうとすると、PCのハードディスクアクセスランプが真っ青に点灯したまま、タスクマネージャーの応答が怪しくなっていく。

計算してみると、1開催（土日2日間）のデータを入れるだけで数十分。

過去10年分を遡ろうとしたら、完了予定時間はなんと「3日後」。

「誰がそんなに待てるかーーーッッ！！」

「月曜の朝に週末のデータを取り込み始めて、終わるのが木曜日って何やねん！ 週末の予想に間に合わへんわ！」

2. 三連単4,896通りの暴力と「1行ずつコミット」の愚行

なぜ、これほどまでに時間がかかるのか？

原因を突き止めるため、データ量を改めて計算して青ざめました。

競馬データの中で、桁違いのレコード数を誇る最大のモンスター。

それが「オッズデータ（特に三連単）」です。

フルゲート18頭立ての場合、三連単の買い目の総数は、

18 × 17 × 16 = 4,896

たった1レースだけで約5,000行。

1日3場・全36レースが行われれば、1日だけで約18万行。

土日の1開催だけで、オッズ明細テーブル（kol_kod3_detail）には36万件以上のレコードが雪崩のように押し寄せてきます。

初期の私が書いていた、恥ずかしすぎるアンチパターンコードがこちらです。

Python

# 【最悪のコード】1件ずつディスクにハンコを押しに行く愚行
for comb, odds in trifecta_list:
    cursor.execute(
        "INSERT OR REPLACE INTO kol_kod3_detail VALUES (?, ...)",
        (year, venue, times, day, r_no, comb, odds)
    )
    conn.commit()  # ← ここが諸悪の根源！！

データベースにおける conn.commit() とは、工場の作業で言えば「ボルトを1本締めるたびに作業台から離れて事務所へ行き、完了伝票に工場長の承認印をもらいに行く」ようなものです。

1秒間に何十億回もクロックを刻むCPUの超高速世界で、1行ごとに物理ディスク（SSDやHDD）へアクセスして「書き込み完了」を確認していたら、遅くて当たり前です。

4,896回、事務所と往復していたら日が暮れます（笑）。

3. SQLiteを覚醒させる三種の神器

この大渋滞を解消するため、私はSQLiteの内部構造にメスを入れ、機械制御の割り込み処理と同じ発想で3つの高速化チューニングを投入しました。

Python

# 実際の db_importer.py より抜粋
def initialize_all_tables(db_path: str):
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()
    try:
        # ① WALモードの開放（並列アクセスと追記書き込みの最適化）
        cursor.execute("PRAGMA journal_mode = WAL;")

        # ② OSへの過剰な同期待ちをスキップ
        cursor.execute("PRAGMA synchronous = NORMAL;")

        # ③ トランザクションを手動制御（巨大な1つの箱として扱う）
        conn.execute("BEGIN TRANSACTION;")

        # （テーブル作成・インデックス作成処理...）

        conn.commit()

① WALモード（Write-Ahead Logging）

SQLiteのデフォルトは「ロールバックジャーナル」という古い仕組みで、誰かが書き込んでいる間はデータベース全体に頑丈な鍵がかかります。

これを journal_mode = WAL に切り替えると、変更差分を専用ログファイル（-wal）に一直線（シーケンシャル）に追記していくモードに変わります。磁気ヘッドやフラッシュメモリが無駄に飛び回るのを防ぎ、書き込み性能が劇的に跳ね上がります。

② PRAGMA synchronous = NORMAL

デフォルトの FULL だと、OSに対して「本当にディスクの磁気面に物理的に電気が書き込まれたか？」を毎回厳格に問い合わせます。家庭用のデスクトップアプリであれば、これを NORMAL に緩めてもデータベースが破損する心配は実用上ゼロです。無駄な同期待ち時間を徹底的に削ぎ落としました。

③ トランザクションの完全手動制御

BEGIN TRANSACTION; を宣言し、Python側の自動コミットを停止。「すべての部品が所定の位置に並ぶまで、事務所へ判子はもらいに行かない」状態を作りました。

4. メモリを溢れさせない「バッチ排出機構」

「ほな、36万件のオッズを全部メモリに溜め込んで、最後に1回だけコミットすれば最速なんちゃう？ 知らんけど！」

そう思うかもしれませんが、それをやると今度はパソコンのメモリ（RAM）がパンクしてアプリが強制終了（クラッシュ）します。

工場の部品プールだって、無限に部品を積み上げたら床が抜けてしまいます。

そこで組んだのが、「5,000件ごとにドッと押し出すバッチインサート機構」です。

Python

# 実際の db_importer.py より抜粋
batch_size = 5000
records_base = []
records_detail = []

with open(kd3_file_path, "rb") as f:
    for line in f:
        # （バイナリのパース処理...）
        row_tuple = tuple(parsed_dict[col] for col in columns_base)
        records_base.append(row_tuple)

        # 5,000件のバッファが満杯になった瞬間、一撃でSQLiteへ流し込む！
        if len(records_base) >= batch_size:
            cursor.executemany(insert_sql_base, records_base)
            records_base.clear()  # メモリを即座に解放！

            if is_odds_table and records_detail:
                cursor.executemany(insert_sql_detail, records_detail)
                records_detail.clear()

# 最後に残った端数を流し込んで、まとめてコミット！
if records_base:
    cursor.executemany(insert_sql_base, records_base)
conn.commit()

Pythonの cursor.executemany() を使い、C言語レベルで最適化されたバルクインサート命令を叩き込みます。

5,000件たまったら、ドスン！と一括プレス。終わったらメモリを即座に clear() して次の5,000件を迎える。

このタクトタイム管理により、メモリ消費量を数十MB程度に抑えながら、最高速のプレススピードを維持することに成功しました。

5. 『Alma Core Pro』なら、数年分の膨大なデータも数分で吸い込まれる

この限界突破チューニングを施した結果、何が起きたか。

これまで1レースのオッズに10秒以上かかり、1開催のインポートでフリーズしていた処理が――

1開催日（36レース分・オッズ数十万件）を、わずか数秒〜十数秒で飲み込むモンスターエンジンに化けました！

1年分の全レース・全成績・全オッズをまとめて流し込んでも、カップラーメンにお湯を入れて待っている間に完了します。

• 「大量のデータを扱うと、PCが重くて固まる」

• 「オッズデータなんて重すぎて個人のPCでは保存できない」

そんな常識は、適切なアーキテクチャ設計とトランザクション制御があれば過去のものです。

『Alma Core Pro』の心臓部（SQLite）は、何百万行という過去の競馬の歴史を、静かに、そして超高速にその身に宿すことができるようになりました！

……しかし。

データが完璧に揃い、意気揚々と競馬分析画面を作ろうとした私に、競馬データの「最大の闇」（笑）が牙を剥くことになります。

6. 次回予告：公式データに無いなら逆算で作る！「各馬ハロンラップ」物理復元の執念

「よし！ オッズも着順もタイムも、すべてコンマ数秒で検索できるようになったぞ！」

さっそく、競走成績テーブル（kol_sei1, kol_sei2）を眺めながら、各馬の走破ラップを分析しようとしたその時。

私は画面の前で頭を抱えました。

「……待てよ。公式データに『各馬の道中ラップ』が載ってないやないか！！」

競馬ブックにも、JRA公式にも載っているのは「先頭馬のレースラップ」と「各馬の上がり3F」、そして「各馬の前3F」（前3Fは競馬ブック独自の貴重データ！）。

中団や後方にいた馬が、道中1ハロン（200m）あたり何秒で走っていたのかは、地球上のどこにも記録されていなかったのです！

「道中ラップが分からんかったら、前が激流でバテた先行馬と、後方で死んだふりして脚を溜めた差し馬の強さの比較なんてできへんやろ！！」

次回、

【Alma Core Pro開発記 NO.7】公式データに無いなら逆算で作る！通過順位と着差から「各馬の個別ハロンラップ」を物理復元した執念のアルゴリズム。

データが無いなら、工学知識で逆算して作り出す！

コーナー通過順位と着差、そして物理運動方程式を組み合わせて、49万頭分の個別ラップを復元させた「機械エンジニアの意地」を語ります！

どうぞお楽しみに！

☕ 最後まで読んでいただき、ホンマにありがとうございました！

「WALモードとバルクインサートの威力がよく分かった！」「オッズのデータ量ってそんなにヤバいのか！」と感じていただけたら、ぜひ画面下の「スキ（ハートマーク）」や「フォロー」をポチッと押していただけると、開発と執筆を続ける最高のガソリンになります！

◀️ 前の記事はこちら

👉 【第5回：昭和の遺産LZHを全自動で剥く！Python×7-Zipで組んだ29テーブル自動仕分けライン】

📚 【全話イッキ読み】自作競馬ソフト開発記マガジン

👉 [Alma Core Pro / MDI Pro 開発マガジンを開く]

💡 「なぜExcelでもサーバー型DBでもなくSQLiteなのか？」原点の第1回はこちら

👉 [開発記 第1回を読む]

⏩ 次のお話はこちら

👉 【第7回：49万頭分の走破ログを復元！通過順位と着差から個別ラップを逆算した狂気の物理式】

🤖 工場のPLC屋が本気で書く！痛快＆重厚な自作Web小説も連載中

👉 [『転生したらイーロン・マスクが大統領だった件（笑）』第1話へ]

👉 [本格クライムSFサスペンス『アブダクション・プロトコル』第1話へ]