クライアントサイド (すなわちローカルディスク) に何らかのデータを保存する Web 技術が、何種類かあります。ブラウザーがどれだけの容量を Web データストレージに割り当てるかや、容量の上限に達したときにどのデータを削除するかのプロセスは単純ではなく、またブラウザーにより異なります。この記事では、これらがどのように動作するかを説明します。
注記: 以下の情報はほとんどの最新ブラウザーでおおむね正確ですが、既知の詳細情報も記載しています。Opera および Chrome は、すべての場合において同じ動作になるでしょう。Opera Mini (Presto ベースで、サーバーサイドでレンダリングする) は、クライアントにデータを保存しません。
ブラウザーのデータストレージを使用する技術は何か?
Firefox では以下の技術が、必要なデータを保存するためにブラウザーのデータストレージを使用します。ここではそれらの技術を "クォータクライアント" と呼びます:
注: Firefox では、Web Storage もすぐに同じストレージ管理ツールとして使えるようになり、それはこの文書で記述します。
注: プライベートブラウジングモードでは、大半のデータストレージがサポートされません。local Storage データと cookies は保存されますが、短命です — 最後のプライベートブラウジングウィンドウを閉じた時にデータは消去されます。
生成元の "最終アクセス日時" は、これらのいずれかによってアクティブ化/非アクティブ化される origin eviction によって、すべてのクォータクライアントでデータ削除が行われたときに更新されます。
Chrome/Opera では、Quota Management API が AppCache、IndexedDB、WebSQL、File System API のクォータ管理を制御しています。
さまざまな種類のデータストレージ
同じブラウザー内で同じ保存方法を使用していても、解釈されるデータストレージの種類はさまざまです。この章では、さまざまなブラウザーで見つけられる多様なストレージについて説明します。
一般的に、ストレージは以下のように大きく 2 種類に分けられます:
- 永続的: 長期間にわたって保持されることを意図するデータです。これはユーザーが決断した場合にのみ削除されます (例えば Firefox では、各ページのページ情報ダイアログに "ストレージを消去" ボタンがあります)。
- 一時的: 長期間にわたって維持する必要がないデータです。ストレージの容量制限に達すると、もっとも過去に使用されたものから削除されます (LRU ポリシー)。
デフォルトでは、一時的なストレージがほとんどの使用環境 (例えば、標準的な Web アプリ) で使用され、永続的なストレージはインストールされたアプリ (例えば、Firefox OS やデスクトップ版 Firefox にインストールした Firefox アプリ、および Chrome アプリ) で使用されます。
データの保存先は?
それぞれのストレージタイプが別々のリポジトリに相当しており、ユーザーの Firefox プロファイル内のディレクトリーとは以下のように対応づけられます (ほかのブラウザーでは、若干異なるでしょう):
<profile>/storage— クォータマネージャ (後述) に管理されている、ストレージの主要なトップレベルディレクトリーです。<profile>/storage/permanent— 永続的なデータストレージのリポジトリです。<profile>/storage/temporary— 一時的なデータストレージのリポジトリです。<profile>/storage/default— デフォルトのデータストレージのリポジトリです。
注: Storage API の導入後は、"permanent" フォルダは廃止されると考えられます。"permanent" フォルダは IndexedDB の永続的なタイプのデータベースのみ保存します。ボックスモードが "best-effort" や "persistent" であっても。、データは <profile>/storage/default 以下に保存されます。
注記: Firefox では URL バーに about:support と入力して移動して、プロファイルフォルダ の隣にある フォルダを開く ボタン (Mac OS X では Finder で開く) を押下すると、プロファイルのフォルダを見つけることができます。
注記: プロファイルフォルダでデータを保存する場所を見ていると、第 4 のフォルダ persistent が見つかるかもしれません。本来は更新や移行を単純化するため、少し前に persistent フォルダを permanent フォルダに改名しました。
注記: ユーザーが <profile>/storage の配下に、独自のディレクトリーやファイルを作成すべきではありません。このようなことを行うと、ストレージの初期化が失敗します。例えば、open() でエラーイベントが発生します。
ストレージの制限
ブラウザーのストレージの最大容量は動的であり、ハードディスクドライブのサイズに応じて変わります。グローバルリミットはディスクの空き量量の 50% に決められます。Firefox では、クォータマネージャと飛ばれる内部のブラウザーツールが生成元ごとにどれだけディスク容量を使用しているかを絶えず注視しており、必要に応じてデータを削除します。
従ってハードディスクドライブが 500GB であれば、ブラウザーの合計ストレージサイズは 250GB になります。上限に達すると origin eviction と呼ばれる処理を実行して、ストレージの総量が再び上限を下回るまで、生成元全体に相当するデータを削除します。生成元内の一部分を削除するような縮小法はありません。生成元内のひとつのデータベースだけ削除すると、矛盾の問題が発生するおそれがあります。
また、グループリミットというもうひとつの制限もあります。これは、グローバルリミットの 20% として定義されます。それぞれの生成元は、グループ (生成元のグループ) の一部です。グループは、eTLD+1 ドメインごとに 1 つ作られます。例えば次の通り:
mozilla.org— グループ 1、生成元 1www.mozilla.org— グループ 1、生成元 2joe.blogs.mozilla.org— グループ 1、生成元 3firefox.com— グループ 2、生成元 4
このグループでは mozilla.org、www.mozilla.org、joe.blogs.mozilla.org が、合わせてグローバルリミットの 20% を上限としてストレージを使用できます。firefox.com は、別に 20% の上限を持ちます。
これら 2 種類の制限は、制限に達したときの動作が異なります:
- グループリミットは "ハードリミット" とも呼ばれます。origin eviction を発生させません。
- グローバルリミットは、いくらかの領域が解放されて処理を継続できる可能性がありますので "ソフトリミット" です。
注: グループリミットは、上記で触れた最小のグループリミットにかかわらず、グローバルリミットより大きくすることはできません。グローバルリミットが 8MB といった本当に低メモリな状況では、グループリミットも 8MB となります。
注記: グループリミットに達したとき、あるいは origin eviction で十分な空き容量を確保できないときは、ブラウザーで QuotaExceededError が発生します。
LRU ポリシー
使用可能なディスク領域がすべて埋まったときは、クォータマネージャが LRU ポリシーに基づいてデータの削除処理を始めます。もっとも過去に使用された生成元のデータが始めに削除され、上限に達しなくなるなるまで削除を繰り返します。
一時的なストレージを使用して、生成元ごとに "最終アクセス日時" を記録しています。一時的なストレージがグローバルリミットに達する (後に上限をさらに超える) と、現在使用していない (すなわち、データストアを開き続けているタブやアプリがない) 生成元をすべて発見しようとします。これらは、"最終アクセス日時" によって整列されます。origin eviction を発生させたリクエストを満たすのに十分な領域を確保するまで、もっとも過去に使用された生成元を削除し続けます。
関連情報
- Working with quota on mobile browsers, by Eiji Kitamura. モバイルブラウザーのクライアントサイドストレージについて詳しく分析した記事。
- Quota Management API : Fast Facts, by Eiji Kitamura. Chrome/Blink (Opera も含まれるでしょう) の Quota Management API について見ていく記事。