1

ファイルシステムに保存したい 1 億を超える文字列があります。文字列 (~255Chars utf8) とともに、2 つの日付とそのプロパティを定義するいくつかの整数値があります。

それらを CSV ファイルに入れることもできますが、それは巨大になります。いくつかの小さな CSV ファイルをサブディレクトリに配置して処理を高速化するか、単純に文字列ごとにファイルを作成してディレクトリ ツリーに保存することができます。

どのソリューションがより速く、より保守/開発しやすいかを知るにはどうすればよいですか? 自分の文字列がどれほどまばらであるかさえわかりません。おそらく、同じ文字で始まる 5,000 万個あるため、ツリーのバランスが取れていません。

今のところ、最初の 5 文字でディレクトリ構造を作成し、各ディレクトリに csv ファイルを配置することを考えています。例えば。文字列「I don't know what I'm doing」 -> 「Idontknowwhatimdoing」が入ります

/i/d/o/n/t/list.csv

もっと良いアイデアはありますか？私は Db を使用できません。Java を使用してファイルシステムを保存し、php を使用してファイルシステムを読み取ります。

4

1 に答える 1

1
  • インデックス付きのデータベースは、はるかに最適です。
  • 以下には、固定レコードサイズの注意事項があります。

文字列が各文字を定義するのに 1 バイトしか必要としない ASCII の場合 (一部の文字が 4 バイトにエンコードされる UTF8 に対して)、レコードごとに固定サイズのフラット ファイルを使用できます。文字列が本当にUTF8である必要がある場合は、可変サイズのエンコーディングではなく固定サイズのエンコーディングを選択するか、最大の文字列を見つけてそれを固定サイズとして使用します。

256 バイト (文字列) + 8 バイト (日付) + 8 バイト (日付) + 8 バイト (整数) + 8 バイト (整数) = レコードあたり 288 バイト

1 億 (エントリ) * 288 バイト (レコード サイズ) = 28.8 GB

そのような巨大なファイルにアクセスするということは、現在アクセスしているファイルの一部のみをメモリに配置することを OS が処理するメモリ マップド ファイルを使用する必要があることを意味します。

文字列がソートされていない場合は、それを行う必要があります。1 億の文字列のチャンク (おそらく 100 万のパーティション) を完全にソートし、それらの 100 のソートされたパーティションをマージして、最終的なソート済みリスト。

文字列を検索する方法は、バイナリ検索 ログ Nであり、1 億レコードの場合、約 27 回の IO 読み取りになります。

于 2015-12-18T17:07:25.307 に答える