プログラミングをしていると、
「とりあえずJSONで持っておけばいいか」
となる場面はかなり多いと思います。
今回は、JSONでデータ管理していた結果、データ量が膨大になりすぎて詰んだ話を書きます。
最初はJSON管理が正解だった
当初の構成はとてもシンプルでした。
- 設定ファイル
- ユーザーデータ
- 状態管理用データ
すべてを 1つのJSONファイル にまとめて管理。
{
"users": [...],
"items": [...],
"logs": [...]
}
- 人間が読める
- 差分管理しやすい
- 実装が楽
この時点では、JSONは最適解に見えました。
データが増え始めてからが地獄
サービスやツールを使い続けるうちに、
- ログが増える
- ユーザーデータが増える
- 履歴データが蓄積される
結果として、JSONファイルは数百MB級に成長。
起きたこと
- プログラムから読み込むと固まる
- メモ帳で開こうとしても無反応
- VS Code でも読み込みに失敗
「中身を確認したい」
→ できない
という最悪の状態になりました。
なぜJSONが限界を迎えたのか
1. 全読み込みが前提
JSONは基本的に
- ファイル全体を読み込む
- パースする
- メモリに展開する
という流れになります。
つまり、巨大JSON = 一気にメモリを食う。
2. ランダムアクセスができない
- 1件だけ読みたい
- 最新のログだけ欲しい
こういった用途でも、
毎回ファイル全体を読む必要があります。
3. 人間可読＝人間が読めるサイズとは限らない
「JSONは人間が読める」と言われますが、
- 数十MB → まだ読める
- 数百MB → 無理
- 数GB → 完全に無理
という現実がありました。
実際に詰んだ瞬間
- 壊れているかどうか確認できない
- 途中までしか読めない
- 修正もできない
結果として、
データは存在するが、触れない
という状態になりました。
どう対処したか
1. JSON分割
- 日付ごと
- 種類ごと
- ユーザーごと
にファイルを分割。
2. ログはJSONをやめた
ログ系データは、
- CSV
- SQLite
- 専用DB
に移行しました。
3. 永続データはDBへ
- 検索
- 更新
- 部分取得
が必要なものは、
最初からDBに逃がすべきだったと反省しています。
JSONが向いている用途・向いていない用途
向いている
- 設定ファイル
- 小規模データ
- 一時データ
- APIレスポンス
向いていない
- ログ蓄積
- 履歴管理
- 大量データの永続化
- 頻繁な更新があるデータ
学び
JSONは便利だが、スケールしない
最初は楽でも、
**「将来どこまで増えるか」**を考えずに使うと、
あとで確実に詰みます。
まとめ
- JSONは万能ではない
- データ量が増えると一気に破綻する
- 永続化・検索・更新が必要ならDBを使う
「JSONで管理していて重くなってきたな…」
と感じた時点で、移行を考えるのが正解だと思います。
同じ轍を踏む人が一人でも減れば幸いです。