100万行のテキスト ファイル サクサク動く？

質問

バックアップ、復元ソフトを作りながらC＃を勉強してます。
復元するために、HDD内のファイルの情報（パス）を記録しておく必要があります。（あると思っている。違うのかもしれない。）

そうするとHDD内の100万個のデータに対し、100万行のテキストファイルを作ることになります。

普段こんな膨大な行数のファイルを扱ったことはありませんが、オープンやクローズ、編集などサクサク動くものなのでしょうか？

回答No.5

superside0 · ベストアンサー

100万行（たぶん100Mバイトぐらい？)あっても、
シーケンシャルに読んだり書いたりするだけのことなら問題ないと思います。

ただ、バックアップしたファイルを　１ファイル１行で
パス/サイズ/タイムスタンプ/オーナー/パーミッション　を記録しておいて
次回のバックアップ時に実際に見つかったファイルが
このリストファイル中にあるかを探して、それと比較することで
新規・削除・更新・変化なしを判断するという使い方になると思います。

ということは、バックアップ処理時にバックアップ元から見つかった１ファイルごとに　
前回に記録しておいた100万行ものファイルを１行ずつ読み込みながら、
マッチするファイルを捜査していたのでは、非常に時間がかかってしまうことになるでしょう。
なので、テープメディアに増分や差分バックアップするのツールを作るのであれば
SQLiteといったINDEXで検索できるDBを使うとか、
アプリに内蔵できるBerkeleyDBのライブラリを使うとか
自力で高速検索できるように二分木検索等の仕組みを作るとか
そういうことが、最終的には必要になってくると思います。

しかし、テープメディアへの増分や差分バックアップという手法を使うのなら
上記のような工夫は必要でしょうけど
HDDやUSBメモリーといったファイルシステムが使えるストレージへのへのバックアップであれば、
バックアップ先のディレクトリ構造そのものがDBとして使えるので
リストファイル自体が不要になると思いますよ。
（バックアップ先のファイルシステム対してパス指定するだけで、
　すぐにそのファイルのサイズやタイムスタンプ等の属性は取り出せるので）

お礼

回答ありがとうございます。

回答No.6

Ultra-Hetare

＞＞100万行のテキストファイル

と言う考え方が、無意味です。

HDDへのアクセス（ディスクI/O）をいかに少なくするかが
重要です。

ディスクからメモリまたはメモリからディスクへのコピペ回数が
少なければ少ないほど、プログラムは早く動きます。
（潤沢なメモリがあることは前提ですが）

一行に何バイトあるのか知りませんが、
たったの100万行では現時点のPCでは
屁のようなものでしょう。

なので、バッファの大きさとかコピペの手法さえ
工夫すれば造作もないことです。

※改行文字も文字なのでPCにとって行数は意味ないですが、
　それを意味づけるコードなどは書かないことです。
　一行一文字で10億行などを改行を意識して書くと遅くなると思います。

お礼

回答ありがとうございます。

Powered by GRATICA

回答No.4

dell_OK

バックアップと復元の部分はあとまわしにして、まずはそのテキストファイルを作るところまでをやってみることです。
それをどのように扱う予定かわかりませんが、もし画面に表示するのでしたらそうしてみてください。
気にされているタイミングもそうですが、他にもそれぞれの処理にどれくらい時間がかかるのかわかると思います。
サクサク動くかどうかよりも、そのようなソフトを作るのはとても勉強になると思います。
サクサク動かないなら作らない、と言うのであれば別ですが、そうでなければ、サクサク動くようにはどうしたらいいかを考えたりするのも勉強になると思います。

お礼

回答ありがとうございます。

回答No.3

sknbsknb2

直接の回答ではないですが、全ファイルの情報を1テキストファイルで管理する必要はないのでは。
1つのフォルダ内のフォルダ/ファイルの情報ということにすればずっと行数が少なくてすみますよ。

お礼

回答ありがとうございます。

回答No.2

AsarKingChang

>100万行のテキストファイル1個をプログラム上で扱うことは、大変なことではないうことですね。

ファイルポインタってのがあり、
今開いているファイル１つの、「どの位置」って情報があり、
その位置に「追加」するだけ！って感じで、
毎回、100万行の一番下はどこ～？とか探してるわけじゃないので。
それ自体は、体感では、わからないような速度ですよ。
（実際には、ある程度まとめてDISKに書き出されるので、書いた時点では、速度低下はほぼしません）
読み込みも同じように、
「行」＝末尾に、\r\nまたは\nなどの「改行コード」を持った物を
1行として、取り込むのですが、これも、
今のファイルポインタからそれが来るまでのほんの少しだけを
読み込むので、これも、別に10万行だろうが100万行だろうが
速度は同じなんです。
上の理屈で、例えばファイルのパスを含め最大ｎ文字としたら、
ｎ文字＋１文字（デメリタ＝\0）で長さを決めてしまって、
それを、１つのデータとして扱う事で、
１０個目のファイルは？（ｎ文字+１文字）*１０個目！
と一瞬で行を特定することもできるようにもできます。
この場合、ファイルはバイナリーモードになりますが。

むしろ、その中からファイルを「探す！」ってのが
大変だとは思うので、そこは＾＾がんばです！

ってことで、書かれてることだけを回答するなら、
一度に全部を見てるわけじゃないので、
遅くなるわけでもなく、普通に動きますよ！
となりますね。

お礼

回答ありがとうございます。
とにかく普通に動くことが分かってよかったです。

回答No.1

AsarKingChang

>オープンやクローズ
なぜ、オープン、クローズするかがわかりません。
「100万行のテキストファイル」が1個ですよね？
でしたら、1個のファイルを開いたら開きっぱなしなので、
別に、100万行のファイルを開くわけじゃないと思いますが。

>編集など
別エディター等での編集は重いでしょうね。
ただプログラムで後方結合するのは別に早いですよ。

>サクサク動くものなのでしょうか？
一度に使うデータは「ある一行」でしかないと思うので、
それ自体は遅いと感じることはないと思います。

が、それを後から「検索して～」ってやりたいなら、
アルゴリズムは大変でしょうね。
ハッシュにするか、インデックスにするか。。
色々、遊べそうですね～

お礼

回答ありがとうございました。

>別に、100万行のファイルを開くわけじゃないと思いますが。
⇒これは100万個の間違いでしょうか？

当方、この質問に関することは知識不足で分かりませんが、100万行のテキストファイル1個をプログラム上で扱うことは、大変なことではないうことですね。