デバイスに大量のデータを格納する J2ME アプリケーションを開発しています (1MB 程度ですが可変)。ファイル システムに頼ることができないので、レコード管理システム (RMS) に行き詰まっています。RMS は、複数のレコード ストアを許可しますが、それぞれのサイズには制限があります。私の最初のターゲット プラットフォームである Blackberry では、それぞれが 64KB に制限されています。
大量のデータを RMS に保存するという問題と、それをどのように管理したかという問題に、他の誰かが取り組まなければならなかったのでしょうか? レコードサイズを計算し、1 つのデータセットが大きすぎる場合は複数のストアに分割する必要があると考えていますが、それを維持するには多くの複雑さが追加されます。
さまざまな種類のデータが保存されていますが、特に 1 つのセットだけが 64KB の制限を超えています。
数キロバイトを超えるものについては、JSR 75 またはリモート サーバーのいずれかを使用する必要があります。RMS レコードは、一部のハイエンド携帯電話であっても、サイズと速度が非常に制限されています。J2ME で 1MB のデータを処理する必要がある場合、信頼性が高く移植可能な唯一の方法は、データをネットワークに保存することです。HttpConnection クラスと GET および POST メソッドは常にサポートされています。
JSR 75 FileConnection をサポートするハンドセットでは有効な代替手段かもしれませんが、コード署名がなければユーザー エクスペリエンスは悪夢です。ほぼすべての API 呼び出しで、セキュリティ プロンプトが呼び出され、包括的なアクセス許可を選択することはできません。JSR 75 を使用してアプリを展開する企業は、通常、可能な証明書のごく一部をカバーするためだけに、ポートごとに半ダースのバイナリを必要とします。これはメーカーの証明書用です。一部のハンドセットには、キャリアロック証明書しかありません。
RMS のパフォーマンスと実装はデバイスによって大きく異なるため、プラットフォームの移植性に問題がある場合、コードが一部のデバイスで適切に機能する場合とそうでない場合があります。RMS は、大量ではなく少量のデータ (ハイ スコア テーブルなど) を格納するように設計されています。
複数のレコード ストアにファイルが保存されているプラットフォームの方が高速であることがわかる場合があります。1 つのストア内に複数のレコードがある方が高速な場合もあります。多くはストレージには問題ありませんが、ストアから大量のデータを削除すると、使用できないほど遅くなります。
最善の策は、利用可能な場合は代わりに JSR-75 を使用し、それ以上のものがサポートされていない場合は RMS にフォールバックする独自のファイル ストア インターフェイスを作成することです。
残念ながら、JavaME に関して言えば、多くの場合、コードのデバイス固有のバリアントを作成することに引き込まれます。
最も柔軟なアプローチは、RMS の上に独自のファイル システムを実装することだと思います。ハードドライブ上のブロックと同様の方法で RMS レコードを処理し、inode 構造などを使用して論理ファイルを複数のブロックに分散させることができます。ブロックの上にバイトまたはストリーム指向のインターフェイスを実装し、その上に特別なデータ構造を書き込むための別の API レイヤーを作成することをお勧めします (または、単にオブジェクトをデータ ストリームにシリアル化できるようにします)。
オペレーティング システムに関する Tanenbaum の古典的な本には、単純なファイル システムの実装方法が記載されていますが、紙が苦手な場合は、他のリソースをオンラインで見つけることができると確信しています。
読み取り専用の場合、リソース ファイルのインデックスを作成することで、許容できる時間 (10 秒以内) に到着します。2 つの ~800 KB の CSV 価格表のエクスポートがあります。プログラム クラスとこれらの両方のファイルは、300 KB の JAR に圧縮されます。
検索では、 a を表示し、バックグラウンドでList2 つの s を実行しThreadてそれを埋めるので、最初の結果はすぐに表示され、すぐに表示されます。最初に単純な線形検索を実装しましたが、遅すぎました (~2 分)。
次に、各文字の始まりを見つけるために、ファイル (アルファベット順に並べ替えられています) にインデックスを付けました。行ごとに解析する前にInputStreamReader.skip()、最初の文字に基づいて、最初に目的の位置に移動します。遅延は主にリソースの解凍に起因すると思われるため、リソースを分割するとさらに高速になります。簡単にアップグレードできるという利点を失いたくないからです。CSV は前処理なしでエクスポートされます。
Blackberry OS 4.6 では、RMS ストアのサイズ制限が 512Kb に増加しましたが、多くのデバイスが 4.6 をサポートしていない可能性が高いため、これはあまり役に立ちません。Blackberry のもう 1 つのオプションは、レコード サイズの制限が 64kb ですが、ストアのサイズに制限がない永続ストアです (デバイスの物理的な制限以外)。
カルロスとイズブは正しいと思います。
JSR75 (FileConnection) を使用し、有効な (信頼できる) 証明書で midlet に署名することを忘れないでください。
JavaMEのコーディングを始めたばかりですが、古いバージョンのPalmOSの経験があります。このバージョンでは、すべてのデータチャンクのサイズが制限されており、レコードインデックスとオフセットを使用してデータ構造を設計する必要があります。
有益なコメントをありがとうございました。結局のところ、最も簡単な解決策は、保存するデータの量を制限し、ストアのサイズに応じてデータを調整するコードを実装し、ローカルに保存されていない場合はオンデマンドでサーバーからデータをフェッチすることでした。OS 4.6で制限が引き上げられたことは興味深いことです。運が良ければ、私のコードはそれ自体で調整され、より多くのデータを保存します:)
.codコンパイラを使用せずにBlackberry用のJ2MEアプリケーションを開発すると、アーカイブに署名できないため、JSR75の使用が制限されます。Carlosが指摘したように、これはどのプラットフォームでも問題であり、PIM部分を使用しても同様の問題が発生しました。BlackberryプラットフォームではRMSが非常に遅いように思われるため、データがメモリにキャッシュされ、優先度の低いバックグラウンドスレッドでRMSに書き込まれない限り、最上位のiノード/bツリーファイルシステムがどれほど役立つかはわかりません。