1億行の巨大テキストを「諦めてDBに入れる」前に — 障害調査・AIデータ前処理のための現実解と実測

技術解説

「この数十GBのファイル、DBにインポートするか、小さく分割してくれ」

定常運用なら、それが最も安全な正攻法です。しかし現場には、DBを構築する時間もディスクの空きもない障害対応や、1億行のデータセットのうち数行の構文エラーで学習パイプラインが止まった瞬間のように、生テキストをその場で直接ねじ伏せるしかない局面が確実にあります。

一般的な16GBメモリのノートPCで数十GB・数億行を扱うと何が起きるのか、実測データで整理します。私は後述する UwView シリーズの開発者で、数値はすべて自社実測です——割り引いてお読みください。

現場が直面する2大ボトルネック

分野 直面する課題 既存の回避策とその限界 求められる理想
障害調査・SRE 顧客から50GBの生ログが届くが手元は16GBのノートPCのみ。1回検索するたびに数分待たされ、翌朝の再開でまた読み込み待ち grep/ripgrepで抽出すると前後の文脈と時系列が切れる。エディタで開くとスワップでPCが固まる。一時DBを立てる容量も時間もない 開いた瞬間に末尾や任意位置へ移動できる。文脈を保持したまま追える。翌日も瞬時に再開できる
AI・機械学習の前処理 1億行のJSONL処理中、9,900万行目の構文エラーでスクリプトが停止。禁止ワードや個人情報を数万箇所一括置換したい。保存で30分フリーズし、途中で落ちると原本が破損 スクリプトを直して最初から数時間かけて再実行。原本保護のため別名保存してディスクを2倍圧迫 エラー行へ即ジャンプして破損行を削除できる。途中保存0秒で安全に中断できる。原本を絶対に壊さない

サイズ別の実測 — 境界はメモリ

3GB級(約1億行・メモリに収まる規模)

  • EmEditor: 置換2回0.9秒・総時間11.0秒で最速。メモリに収まるデータでは、置換エンジン単体の速さが圧倒的です。この事実は削らずに書いておきます
  • UwView Pro+Edit Upgrade: 置換2回6.3秒・総時間14.1秒。単発ではEmEditorに及びません。途中保存0秒と2日目以降の開き直しを含めた反復作業で逆転します
  • UltraEdit(Mac): 全置換14.1秒・途中保存4秒と軽快。5GB超で速度低下の警告が出ますが、2026年9月14日の再計測では50GBのオープン1分11秒・検索1分23秒で完走(閲覧・検索なら50GBまで実用的)

10GB級(約1億行・メモリ境界)

  • UwView Pro+Edit Upgrade: 置換2回12.41秒・保存して閉じる10.2秒(総時間51.91秒)
  • EmEditor: 置換2回28.6秒と健闘するものの、「保存して閉じる」に187.3秒を要し総時間229.9秒
  • 010 Editor(Mac): 検索11.5秒・置換16.3秒。ただし通常テキストの保存に2分40秒かかり、中断のたびの待ち時間がネックになります

48GB級(約8.9億行・メモリ超過)

  • UwView Pro+Edit Upgrade: 開いた直後から全域閲覧可能。全文検索は初回12.5〜23.9秒・2回目以降5〜14秒。置換2回47.0秒。作業途中の保存は0秒
  • EmEditor: 末尾への移動に約4分。置換2回は11分超(2回目が途中でハングし、PC再起動後の再計測値を含む)、保存に毎回31分
  • klogg: 閲覧専用。検索のたびにディスク全体を走査するため、外付けHDDでは1回に約10分
  • grep / ripgrep: 単一巨大ファイルでは並列化が効かず、grep 64.64秒・rg 71.49秒(1回きりの抽出なら十分実用的です)

UwView 各エディションの仕様(全て指定行ジャンプ対応)

  • Wasm版 UwView(ブラウザ・無料): インストール不要。ソフト導入が禁止された端末や踏み台環境の初動確認に。ブラウザの制約があるため本格調査はアプリ版で
  • 無料アプリ版 UwView: 開いた瞬間から全域閲覧。日本語文字コード自動判定(Shift-JIS/EUC-JP)。検索結果の文脈表示は前後±1行
  • UwView Pro: 永続索引(.uwvz)で2回目以降はミリ秒単位のオープン。48GB・3ストレージ合計の検索実測でklogg比約7.7倍。文脈表示は前後±64行。文脈付きコピー/矩形コピー/別ファイル保存・多段階Drill-down検索・Sequence検索
  • UwView Pro+Edit Upgrade: 上記に加え非破壊オーバーレイ編集(.ewvz)。行削除・差分置換・原本を保護したワンパス再構成。50GB級でも途中保存0秒

「途中保存0秒」の正体 — 誇張なしの仕組み

「途中保存0秒」は、完成テキスト全体の書き出し時間ではありません。原本ファイルは一切書き換えず、編集内容だけを小さな差分ファイル(.ewvz)へ書くため、作業を中断して閉じる時間がほぼゼロになる、という意味です。編集中も差分は常にディスクに残るので、クラッシュしても編集内容は失われません。

【数日にわたる作業の流れ】
1日目: 開く → 検索・置換・行削除 → 閉じる(ほぼ0秒)
2日目: 開き直す(ミリ秒) → 追加修正 → 閉じる(ほぼ0秒)
最終日: 成果物の書き出し(1回だけ実行)

では、最後の書き出しにはどれだけかかるのか。 ここは物理的なディスクI/Oが発生するので、正直に実測値を書きます。

  • 10GB級: 010 Editorの通常テキスト保存2分40秒に対し、通常テキスト作成12.3秒・圧縮.uwvzなら5.8秒
  • 48GB級: EmEditorの保存31分に対し、.uwvzの再構成(1パス)1分33秒。途中で閉じるだけなら49.9秒(差分書き出しのみ)

役割分担としての選択

これは「どちらが優れたエディタか」という話ではありません。

  • 日常的なコード編集・CSV成形・マクロ処理・メモリに収まるサイズのファイル: EmEditorをはじめとする高機能エディタが最適です
  • 手元の16GBノートPCに、突然数十GB・数億行のファイルが降ってきたとき: UwView Pro/Edit Upgrade が救急箱になります

DB化や分割の猶予がない現場で、生テキストを安全に、その場で扱うための選択肢です。

UwView Pro は発売中です(Windows・macOS・Linux、1ライセンスで全OS。買い切り/月額。14日間の無料試用あり——編集機能も使えます)。まず開けるか試すだけなら無料版 UwView をどうぞ。

正直に書いておくこと

  • 数値はすべて開発者の自社実測です(Windows 16GB機とMac M4 32GB機の結果が混在。環境をまたいだ秒数比較はできません)
  • 48GB級のEmEditorの置換は、初回試行が13分でハングしたためPC再起動後に再計測した値を使っています
  • メモリに収まるサイズの編集はEmEditorが最速です。1回きりのCLI抽出はgrepで十分です
  • 同条件で追試された方がいれば、結果に応じて本記事を修正します

実測の元記事

タイトルとURLをコピーしました