1.6GBのSQLiteと付き合う——競艇・競馬のデータを個人のPCで数百万行扱うまで

1.6GBのSQLiteと付き合う——競艇・競馬のデータを個人のPCで数百万行扱うまで

集計を一本流して、コーヒーを淹れに立った。戻ってきても、まだ終わっていない。

ファイルの大きさを見たら1.6GB。テーブルは十いくつ。中身は自分で何年もかけて貯めてきた、公営競技の公開データ。「たかがSQLite」と思っていた相手に、私はある晩、はっきり負けた。

入っているのは、競艇（ボートレース）と競馬の公開データだ。

このシリーズの語り手は、BIツールで社内データを何年も扱ってきた人間である。その手つきを個人の時間に持ち出して、自作の機械学習モデルと自作の検証システムを、公営競技のオッズと結果データに当てている。仕事の話ではない。勤務先の業務とも組織とも無関係な、私ひとりの夜の作業だ。

この記事で持ち帰ってもらいたいのは三つ。

• 数百万行のSQLiteが遅くなったとき、最初に打つ手は何か。

• 「とりあえず貯める」の設計が、どこで自分の首を絞めるか。

• 個人のPCという制約の中で、私が何を捨て、何を残したか。

先に断っておく。この記事に「この買い目が当たる」の類は一行も出てこない。扱うのは、動かし終わったあとのログと、それを眺めていた私の気持ちだけ。

「貯める」までは簡単だった

個人でデータを貯めている人のまわりを見ると、だいたい同じ道をたどっている気がする。最初はCSV。増えてきたのでSQLite。ファイル一つで済むし、インストールも要らない。私もそこから入った。

BIの現場で扱っていたのは、誰かが設計して、誰かが面倒を見ている倉庫だった。私はその上で集計とグラフを作る側。だから正直に言うと、テーブルの設計というものを、自分の手で最初から最後まで背負った経験がほとんどなかった。そこが後で効いてくる。

公開データを毎日取り込む。レース、出走、オッズ、結果。取り込みのスクリプトは一晩で書けた。動いた。数日分なら一瞬で集計が返ってくる。「これで足りるじゃないか」と、私は本気で思っていた。

個人的には、この「足りるじゃないか」が一番危ない瞬間だと今は考えている。足りているうちは設計を見直す動機が生まれない。見直す動機が生まれるのは、足りなくなった夜だ。

遅くなったのは、ある日突然ではない

正確に言えば、じわじわだった。

朝の取り込みが少し長い。気のせいか。集計が前より重い。データが増えたのだから当然か。そうやって一つずつ言い訳を用意して、私は数か月、何も直さなかった。BIの仕事では「遅いクエリ」を見つけて直すのが得意なつもりだったのに、自分のPCの上では同じことができなかった。たぶん、自分のデータには甘くなる。

決定的だったのは、自作の検証システムに新しい特徴量を足そうとした晩。検証というのは、過去のオッズと結果を並べて「あのとき賭けたつもりで動かしたら、評価損益はどうなったか」を機械的に再生する作業だと思ってもらえればいい。その再生の前段で、期間をまたいだ集計を一本走らせた。

終わらない。

タスクマネージャを見るとディスクだけが忙しい。CPUは暇そうにしている。この時点で「インデックスがない」か「テーブルの切り方が悪い」か、その両方だと分かるはずなのに、私は先に「PCが古いのでは」と考えた。道具のせいにしたかったのだと思う。

ここで一度、葛藤があった。クラウドの倉庫に移せば楽になる。だが個人の趣味に月額を払い続けるのか。しかも本番bankroll、つまり実際に賭けている資金は、このシステムにはゼロだ。一円も入れていない検証装置のために、毎月いくらか払う。その釣り合いが、私にはどうしても取れなかった。

だから残す。個人のPC、SQLite、1.6GB。この制約を前提に、設計を変える。それが私の選んだ側だった。

「設計を変える」まで、集計一本に何分もかかっていた

ここからが本題になる。

最初に打った手は、派手なものではない。テーブルをいきなり分割したわけでも、別のデータベースに乗り換えたわけでもない。やったのは、遅い集計を一本だけ選んで、その一本がどの列をどう舐めているかを、実行計画で読むことだった。BIの現場で何年もやっていた、いちばん地味な作業。

読んでみて、恥ずかしくなった。日付で絞っているのに日付に索引がない。レースを引くのに、レース番号ではなく文字列の連結キーで探している。「貯める」ことしか考えずに作ったテーブルは、「取り出す」側の都合を一つも聞いていなかった。

私は、この恥ずかしさをこのシリーズの主題にしたいと考えている。数百万行を扱う技術そのものは、探せばいくらでも書かれている。書かれていないのは、それを知っている人間が、自分のデータの前でなぜ同じ失敗をするのか、という方だ。

次の部では、実際に何をどの順番で直したか、そして直したあとに検証システムの数字がどう動いたかを追う。先に言っておくと、速くなったことと、モデルが市場を上回ったことは、まったく別の話だった。

第2部 数百万行と向き合う前に、言葉をそろえる

「索引」と「実行計画」を、自分の言葉に置き換える

直す手順を書く前に、道具の名前を先にそろえておきたい。ここで言葉が食い違うと、第3部の「何をどの順に直したか」が、ただの呪文の羅列になってしまう。

SQLiteは、たった一つのファイルだ。

サーバもプロセスも要らない。1.6GBのファイルが手元にあって、それを開くと14枚のテーブルが並んでいる。私の環境ではそれだけ。このシンプルさに惚れて選んだのに、同じシンプルさに何年も足を取られた。

ファイルの中身は「ページ」という固定サイズの箱に区切られている。SQLiteが行を探すとき、実際に読んでいるのは行ではなくページの方だ。索引がなければ、条件に合う行が一件でも、先頭から最後のページまで全部めくる。これを全件走査と呼ぶ。数百万行の全件走査は、机の上の辞書を、目的の単語が出るまで1ページ目から読むのと同じ作業だ。

索引は、その辞書の巻末につく見出し語の一覧。「この日付の行は、あのページ」と先に引ける。だから速い。ここまでは、たぶん誰でも知っている。

知らなかったのは、その先だった。

当時、同じ検証をしていた知人とこんなやり取りをした。

「索引って、貼れば速くなるんでしょ。全部の列に貼っちゃえば」

「貼るたびに、書き込みが遅くなるよ。行を一つ足すたびに、索引も全部書き直すから」

「じゃあ日付だけでいいじゃん」

「日付で絞ったあと、レース番号で並べ替えてる。その並べ替えの索引がない」

「……面倒だね」

面倒なのだ。索引は「どの列で絞り、どの列で並べ、どの列を取り出すか」の組み合わせに対して効く。列ごとに一枚ずつ貼れば済む話ではない。

それをどう確かめるか。ここで実行計画が出てくる。SQLiteに「この問い合わせ、どうやって答えるつもり?」と聞くと、短い文で返してくる。全件走査するのか、索引を使うのか、途中で一時的な並べ替え用のテーブルを作るのか。私はこれを、司書が本棚をどう回るかの下書きメモだと思っている。速さの数字を測る前に、まずメモを読む。BIの現場で何年もやってきたのと同じ順番。それを個人のファイルでは飛ばしていた。

もう一つ、言葉をそろえておく。書き込みの方式だ。

SQLiteには、書き込みのたびに元のファイルを直接書き換える方式と、変更を別の帳面に追記しておき、あとでまとめて本体に反映する方式がある。後者を先行書き込みログ、略してWALと呼ぶ。私の言い方だと「レジの締めをあとでやる方式」。読む側は本体を読み、書く側は帳面に追記するので、両者がぶつかりにくい。数百万行を夜中に足しながら、朝に集計を回す暮らしでは、この違いが体感の差になった。

2025年から2026年、まわりで何が起きているか

ここからは肌感の話になる。数字は出さない。出せる調査を私は持っていない。

まわりを見ると、この一、二年で「SQLiteを本気で使う」人が目に見えて増えた。個人開発者の集まりで、以前なら「そろそろ本物のデータベースに移すべきか」という相談が定番だったのに、最近は「移さずに済ませるには」という相談の方をよく聞く。私が観察している範囲で、動きは五つある。

一つ目。列指向の分析エンジンが、SQLiteのファイルをそのまま読めるようになってきたこと。貯める側はSQLiteのまま、重い集計だけ別のエンジンに投げる。私も試した。全件を集計する種類の問いには効いたが、一レースを引く種類の問いには向かなかった。道具は一つでは足りない、という当たり前の結論。

二つ目。WALが「知っている人だけの設定」から、初期設定に近い扱いになったこと。まわりの個人開発者で、最初からWALで始めている人が普通になった。私は途中で切り替えた側で、切り替える前の自分を少し恨んでいる。

三つ目。サーバを持たない実行環境の上に、SQLiteのファイルを置いて動かす話。個人の趣味の域で言えば、ノートPCの中で完結していたものを、そのまま外に出せる。私はまだ自分のファイルを外に出していない。1.6GBを転送する気になれないのが正直なところで、これは技術というより気持ちの問題だ。

四つ目。全文検索やベクトル検索を、拡張として同じファイルの中に持てるようになったこと。公営競技の出走表に含まれる文字情報を、あとから検索の対象にする道が開けた。ただ、私はこれに手を出して一度ファイルを壊しかけた。拡張を載せる前に必ずコピーを取る。この一行を身体で覚えるまでに、一晩を無駄にした。

五つ目。これは動向というより、空気の変化かもしれない。「一ファイルで持ち歩ける」ことが、あらためて価値として語られるようになった。バックアップはコピー。移動はコピー。壊れたらコピーから戻す。運用の言葉がすべて「コピー」で済む。個人的には、この気楽さが、遅さの何倍もの価値だと考えている。

私のファイルを、数字で置いてみる

出せる数字は多くない。それでも、話の土台になるものだけ置いておく。

• 項目: ファイルの大きさ / 私の環境での値: 1.6GB

• 項目: テーブルの数 / 私の環境での値: 14

• 項目: 行数の規模 / 私の環境での値: 数百万行

• 項目: 設計を変える前の、集計一本の所要時間 / 私の環境での値: 分単位

• 項目: 設計を変えた回数 / 私の環境での値: 一度では済まなかった

ここから先は、『個人としての実感』をはじめ、私が実際に手を動かした手順と、つまずいた箇所まで含めて書いています。もう少し具体的に知りたい方は、この先で。

本シリーズは、機械学習・統計的検証を公営競技（競艇・競馬）に適用した実測記録であり、勝ち方の指南や、利益を保証する内容ではありません。本シリーズで示す損益・ROI・破産率の数値はすべて検証用シミュレーションの実測値であり、筆者が実際に購入した記録ではありません。（筆者個人には舟券・馬券を購入した経験がありますが、その購入時の金額・収支等の記録は本シリーズのいずれの数値にも使用していません。）文中の数値はすべて筆者が個人で開発・運用した検証システムのシミュレーション実測ログに基づき、投資・賭け金額の推奨を一切行いません。勝馬投票券・舟券は20歳未満の方は購入できません。ギャンブル等依存症が心配な方は、お住まいの都道府県・政令指定都市が設置する相談窓口、または医療機関にご相談ください。