デバイスに格納するデータ量が多い（1MBの領域で可変ですが）J2MEアプリケーションを開発しています。私はファイルシステムに頼ることができないので、私はレコード管理システム（RMS）に固執しています。私の最初のターゲットプラットフォームであるBlackberryでは、それぞれ64KBに制限されています。大量のデータをJ2MEで保存するためのベストプラクティス
誰かが大量のデータをRMSに格納する問題に対処しなければならないのか、それをどう管理しているのだろうかと思います。私はレコードサイズを計算し、複数の店舗にまたがる1つのデータセットを分割しなければならないと考えていますが、その大きさが大きすぎると複雑になります。
さまざまなタイプのデータが格納されていますが、特に1セットだけが64KBの制限を超えます。
数キロバイトを超えるものについては、JSR 75またはリモートサーバーのいずれかを使用する必要があります。 RMSレコードのサイズとスピードは、一部のハイエンド端末でも非常に制限されています。 J2MEで1MBのデータをやりとりする必要がある場合は、信頼性が高くポータブルな方法は、ネットワークに格納することだけです。 HttpConnectionクラスとGETメソッドとPOSTメソッドは常にサポートされています。
JSR 75 FileConnectionをサポートするハンドセットでは、有効な代替方法である可能性がありますが、コード署名なしでは、ユーザーエクスペリエンスの悪夢です。ほぼすべての単一のAPIコールは、ブランケットのアクセス権の選択肢がないセキュリティプロンプトを呼び出します。 JSR 75を使用してアプリケーションをデプロイする企業は、通常、可能な証明書のほんの一部をカバーするために、各ポート用の半二重のバイナリが必要です。これは製造元の証明書にすぎません。一部の端末にはキャリアロックされた証明書しかありません。
最も柔軟なアプローチは、RMSの上に独自のファイルシステムを実装することだと思います。ハードドライブ上のブロックと同様の方法でRMSレコードを処理し、inode structureなどの論理ファイルを複数のブロックに分散することができます。ブロックの上にバイトまたはストリーム指向のインターフェイスを実装し、特殊なデータ構造を記述するために別のAPIレイヤーを作成することをお勧めします（または単にオブジェクトをデータストリームにシリアライズ可能にする）。
Tanenbaum's classical book on operating systemsは、単純なファイルシステムの実装方法について説明していますが、紙が気に入らなければオンラインで他のリソースを見つけることができます。
RMSのパフォーマンスと実装はデバイスによって大きく異なるため、プラットフォームの移植性に問題がある場合は、コードが一部のデバイスでうまく機能することがあります。 RMSは、大量ではない少量のデータ（ハイスコアテーブルなど）を格納するように設計されています。
複数のレコードストアに格納されているファイルの方が高速なプラットフォームもあります。 1つのストア内の複数のレコードで高速化されているものもあります。多くの場合、ストレージは大丈夫ですが、ストアから大量のデータを削除すると、使用が遅くなります。
可能な限りJSR-75を使用し、より優れたものがサポートされていない場合は、RMSにフォールバックする独自のファイルストアインターフェイスを作成することをお勧めします。
残念ながら、JavaMEについて言えば、コードのデバイス固有の変形を書くことがよくあります。
私はJavaMEをコーディングし始めたばかりですが、すべてのデータチャンクのサイズが制限されている古いバージョンのPalmOSで、レコードインデックスとオフセットを使用したデータ構造の設計が必要です。
ブラックベリーOS 4.6では、RMSストアのサイズ制限が512KBに増加しましたが、多くのデバイスが4.6をサポートしていない可能性が高いため、これはあまり役に立ちません。Blackberryのもう1つの選択肢は、レコードサイズの上限が64kbですが、デバイスの物理的限界を除いてストアのサイズに制限がない永続ストアです。
私はカルロスとイズが正しいと思います。
JSR75（FileConnection）を使用して、有効な（信頼できる）証明書でミッドレットに署名するのは忘れずにしてください。
皆さん、ありがとうございました。最後に、最も簡単な解決策は、ストアされるデータの量を制限し、ストアの大きさに応じてデータを調整するコードを実装し、ローカルに格納されていない場合はオンデマンドでサーバーからデータを取得することでした。私のコードはOS 4.6で限界が増えて面白いと思うのですが、私のコードはそれだけで調整してより多くのデータを保存します:)
.codコンパイラを使用せずにBlackberryのJ2MEアプリケーションを開発すると、JSR 75アーカイブに署名できないのでCarlos氏が指摘しているように、これはどのプラットフォームでも問題であり、私はPIMの部分を使って同様の問題を抱えています。 RMSはBlackberryプラットフォーム上では非常に遅いようですので、データがメモリにキャッシュされ、RMSに優先度の低いバックグラウンドスレッドで書き込まれない限り、iノード/ bツリーファイルシステムがどれほど役に立つかはわかりません。
読み取り専用の場合、リソースファイルのインデックスを作成して、許容時間（10秒以内）に到着します。私は2つの〜800キロバイトのCSV価格リストの輸出を持っています。プログラムクラスとその両方のファイルは300KBのJARに圧縮されます。
検索すると、私はListを表示し、背景に2つのThreadを実行すると、最初の結果がすぐに表示され、すぐに表示されます。最初は単純な線形検索を実装しましたが、それは遅すぎました（〜2分）。
次に、ファイルをアルファベット順に索引付けして、各文字の始まりを見つけました。今すぐ行ごとに解析する前に、私は最初の文字に基づいて、希望の位置に最初にInputStreamReader.skip()。私は遅れが主にリソースを解凍することから来ていると思うので、リソースを分割することでさらにスピードアップします。私はそれをしたくない、簡単なアップグレードの利点を失うことはありません。 CSVは前処理なしでエクスポートされます。
一部のデバイスでは、許可されているレコードストアの数も制限されていることに注意してください。これは2と同じくらい低くなる可能性があります。 –