Scala では、ペア (X, Y) の非常に長いリストが必要です。サイズが大きすぎてメモリに収まりません (ただし、ディスクにはうまく収まります)。
つまり、これは基本的に「disk-persisted-lazy-cacheable-list」™ です。
独自の展開を開始する前に入手する方法についてのアイデアはありますか?
補遺:はい.. mongodb、またはその他の組み込み不可能なリソースはやり過ぎです。この特定のユースケースに興味がある場合は、こちらのクラスを参照してTimeline ください。基本的に、私は非常に大きなタイムライン (月間で数百万のペア) を持っていますが、私の試合は最後の時間に触れるだけで済みます.
あなたが書く：
mongodb、またはその他の組み込み不可能なリソースはやり過ぎです
非常に小さなものも含めて、組み込み可能なデータベース エンジンがあることをご存知ですか? あなたが知っていれば、私はあなたの正確な要件について確信が持てず、なぜそれらを使用しないのですか.
Hibernate +埋め込み可能なDB (SQLite など) では不十分だと確信していますか? あるいは、BerkeleyDB Java Edition、HSQLDB、またはその他の組み込みデータベースがオプションになる可能性があります。
オブジェクト自体に対してクエリを実行しない場合 (実際には実行していないように思えます)、シリアル化は複雑なオブジェクトのオブジェクト リレーショナル マッピングよりも簡単かもしれませんが、私は試したことがなく、どちらがうまくいくかわかりません。速くなる。しかし、選択したフレームワークが[T <: Serializable]. [T: MySerializable]そうでない場合は、独自の「型クラス」を作成した後に書くことができますMySerializable[T](たとえばOrdering[T]、Scala 標準ライブラリのように)。
ただし、このタスクには標準の Java シリアライゼーションを使用したくありません。「シリアル化可能なもの」は、これにシリアル化を使用することを示唆しているため、悪い要件に聞こえますが、「選択したフレームワークでシリアル化可能なもの」に緩和できると思います。シリアル化は時間と空間の点で非常に非効率的であり、単一のオブジェクトをシリアル化するようには設計されていません。代わりに、特別なヘッダーを備えたファイルを返します。いくつかの異なるシリアライゼーション フレームワークを使用することをお勧めします。比較については、こちらをご覧ください。
さらに、ファイルを本質的に逆方向に読み取っているように聞こえます。これは、SSD 以外のディスクでは、パフォーマンスの点で非常に悪いアクセス パターンです。セクターを読み取った後、前のセクターにアクセスするには、ほぼ完全なディスク ローテーションが必要です。 .
さらに、上記のコメントで Chris Shain が指摘したように、ページベースのソリューションを使用する必要があり、可変サイズのオブジェクトに対処する必要があります。
組み込み可能な DB の 1 つにステップアップしたくない場合は、メモリ マップされたファイルのスタックはどうですか?
この Java ライブラリには、必要なものが含まれている場合があります。標準の Java コレクションよりも効率的にエントリをメモリに格納することを目的としています。