フリーヒルズラボデータベースリファクタリング
特許データベースの再構築
数百万件規模の特許公報データを実用レベルで捌くために、どのような課題感からデータベースを一から再構築し、どのようなアプローチをとったのかを記録しています。
フリーヒルズラボに参画して直面した最大の技術的課題は、事業の根幹となる「特許データベース」の構造的な限界でした。
スケールアップを阻むデータ構造
当時、すでに前任者によって特許DBの原型は構築されていました。しかし、その中身を見た私は強い危機感を覚えました。
採用されていたのは、特許公報のXMLを1行ずつ中間テーブルに保存する設計でした。
テスト用の少量のデータであれば、どのようなタグが存在するのかを把握しやすく、柔軟な抽出ができるアプローチだったのかもしれません。しかし、数百万件の実データを投入すれば、この中間テーブルの行数は数十億という天文学的な数に膨れ上がり、ストレージの容量も検索速度も即座に限界を迎えます。
テスト用の少量のデータであれば、どのようなタグが存在するのかを把握しやすく、柔軟な抽出ができるアプローチだったのかもしれません。しかし、数百万件の実データを投入すれば、この中間テーブルの行数は数十億という天文学的な数に膨れ上がり、ストレージの容量も検索速度も即座に限界を迎えます。
実際に、データベース本来の検索機能（インデックス）が有効に働かず、検索のたびに数億の行をフルスキャンする状態に陥っていました。さらに、分散したデータをプログラム側でかき集めて元の文書構造に組み立て直す処理が必要となり、これがサーバーのメモリを枯渇させ、システムをクラッシュさせる要因になっていました。
研究室での小規模な検証から実運用へフェーズを移行するためには、このスケールしない構造からの脱却が急務でした。
課題を解決するためのアプローチ
数百万件の生データ（数百GB規模）を現実的な時間とリソースで処理するため、私はデータベースの設計を一から見直しました。
同時に、使用するデータベースエンジンも MySQL からXML型をサポートしている PostgreSQL へ移行しました。
- データの適材適所な配置
XMLタグの過度な分割をやめ、そのまま保持すべき文書データと検索用に構造化すべきメタデータ（出願人や特許分類など）を明確に分離しました。これにより、無駄なデータ結合を排除し、データベース本来の検索能力を最大限に引き出しています。 - メモリを逼迫させないパイプライン
巨大な圧縮ファイルを一旦ディスクに展開するのではなく、メモリ上で少しずつ読み込みながら、直接データベースへ一括で流し込む設計に変更しました。ボトルネックとなるデータ転送の負荷（I/O負荷）を極限まで抑え込んでいます。 - LLM連携を見据えた検索基盤の整備
単なるキーワード検索にとどまらず、日本語の全文検索や、文章の意味を解釈して関連技術を探し出す「ベクトル検索」をネイティブにサポートする基盤を構築しました。
数百万のデータ規模に耐えうる堅牢性
この新しいアーキテクチャにより、現時点で約470万件の特許公報データの解析から格納までの全処理を、メモリを溢れさせることなく現実的な時間で完遂できるようになりました。
これほどの大規模データになると、処理途中の予期せぬエラーや中断は避けられません。そのため、何度実行しても、いつ中断してもデータが重複・破損しない冪等性（べきとうせい）を重視した設計を取り入れ、実運用に耐えうる堅牢なシステムを実現しています。
Webアプリの枠を超えた基盤としての価値
特許DBを再構築した最大の成果は、現在開発中のWebアプリケーションの裏側を支えるだけでなく、データ基盤として独立した価値を生み出せたことです。
先日、別プロジェクトから LLM の継続事前学習用として、特許データの提供依頼を受けました。以前のデータ構造であれば、途方もない時間がかかるか、メモリ不足で抽出できなかったはずです。しかし、現在の盤石な基盤と省メモリな抽出パイプラインが整っていたため、依頼に対して即座に数百万件規模のクリーンなデータセットを生成し、提供することができました。
個人開発の規模を超え、ハードウェアの限界と計算量を意識しながら構築したこのデータ基盤は、フリーヒルズラボの幅広い事業展開を支える確かな土台になったのではないかと考えています。