10

最初に300万から400万のPDFファイルを生成し、80K/日の速度で継続するプロセスがあります。それぞれかなり小さい（50K）ですが、私が心配しているのは、簡単に検索できるように、生成しているファイルの総量をどのように管理するかです。いくつかの詳細：

  1. ファイルが生成されたら、他のいくつかの手順を実行する必要があります。また、いくつかのサーバーが参加するため、ファイルが生成されるのを監視する必要があります。
  2. 生成されると、ファイルは私が作成したルックアッププロセスを通じて利用できるようになります。基本的に、ファイルごとに一意の注文番号に基づいてそれらをプルする必要があります。
  3. いつでも既存の注文番号を再送信でき、生成されたファイルは元のコピーを上書きする必要があります。

当初、私はこれらのファイルをすべてNAS上の単一のディレクトリに書き込むことを計画していましたが、何百万ものファイルがあり、Windowsが100万のファイル検索を非常に適切に処理しない可能性があるため、これは良い考えではないかもしれません。私はいくつかのアドバイスを探しています：

  1. 単一のフォルダで大丈夫ですか？ファイルが一覧表示されることはありません。ファイルは、私がすでに決定したファイル名のSystem.IO.Fileを使用してのみ取得されます。
  2. フォルダーを作成する場合、System.IO.DirectoryWatcherを使用して、その数のファイルでも新しいファイルを監視できますか、それとも、その数のファイルで速度が低下し始めますか？
  3. 代わりに、SQL ServerデータベースにBLOBとして保存する必要がありますか？参照値でそれらを取得する必要があるので、おそらくこれはより理にかなっています。

考えてくれてありがとう！

4

12 に答える 12

6

質問に答えるには:

  1. それらを単一のフォルダーに保存しません。ある時点で、他の方法ではなく、ディスク上の実際のファイルを調べたいと思う可能性があります。
    代わりに、それらを別々のディレクトリに保存して、1000 のバッチに分割してみませんか? おそらくIDをキーとして使用しています。
  2. その多くのファイルがおそらく DirectorWatcher をフラッディングするため、一部が失われます。私は過去にこれを使用しましたが、特定の時点 (数百) を過ぎると、ファイルが失われ始めることがわかりました。おそらく、着信ファイルに別のディレクトリを使用し、これを頻繁に処理します。これにより、オリジナルを更新するプロセスがトリガーされます。
  3. ドキュメントをデータベースに保存するつもりはありませんが、メタデータは間違いなくデータベースに保存します。
于 2009-08-10T21:59:37.857 に答える
6

ファイルを複数のフォルダーに簡単に整理することができます。ビジネス ロジックや 1 日ごとの順序でこれを行う必要はありません。これは、そのような順序付けが「塊状」 (1 つのフォルダーに多くのヒットがあり、他のフォルダーにはほとんどない) 場合に特に便利です。

これを行う最も簡単な方法は、ファイル名の一意のハッシュを作成することです。これにより、次のような結果が得られる可能性があります。

sf394fgr90rtfofrpo98tx.pdf

次に、これを 2 文字のブロックに分割すると、次のようになります。

sf/39/4f/gr/90/rt/fo/fr/po/98/tx.pdf

ご覧のとおり、簡単にナビゲートできる深いディレクトリ ツリーが提供されます。

優れたハッシュ関数を使用すると、これは非常に均等に分散され、ディレクトリごとに 1296 エントリを超えることはありません。競合が発生した場合 (これは非常にまれです)、末尾に数字を追加してください: tx.pdf、tx_1.pdf、tx_2.pdf。繰り返しになりますが、このような大きなハッシュでの衝突は非常にまれであるため、これが原因で生じる種類の凝集は問題になりません。

ドキュメントはデジタル署名されているとおっしゃいましたので、必要なハッシュは署名文字列の形ですぐそこにあるはずです。

于 2009-08-10T22:53:40.587 に答える
3

ファイルを特定のサブフォルダーにグループ化し、ビジネス ロジックの方法でそれら (サブフォルダー) を整理しようとします。おそらく、特定の日に作成されたすべてのファイルでしょうか? 毎日6時間の間？または、ファイルの数ごとに、最大数 1000 と言います。（おそらく理想的な数がそこにあり、うまくいけば誰かがそれを投稿します。）

ファイルが古くなって削除されることはありますか? もしそうなら、ソートとファイルは削除可能なチャンクです。そうでない場合は、ハードウェア ベンダーになることはできますか?

ファイルをデータベースに保存することについては、どちらの側にも議論があります。

  • 一方では、DB からファイルをプルするのが面倒なので、セキュリティが強化されます。一方で、パフォーマンスが低下する可能性があります。これは、DB からファイルをプルするのがより厄介だからです。
  • DB では、フォルダーごと、セクターごと、NAS クラスターごとにいくつのファイルがあるかを気にする必要はありません。反対に、データを管理/確認するのは難しくなります。1 つのテーブルに膨大な量のブロブが存在するためです。(前述のビジネス ロジックに基づいてテーブルをパーティション分割することができます。これにより、削除またはアーカイブの実行が無限に簡単になります。テーブルのパーティション分割には 1000 パーティションの制限があるため、それ、またはパーティション分割されたビューかもしれません。)
  • SQL Server 2008 には FileStream データ型があります。よくわからないので調べてみるといいかもしれません。

心配する最後のポイントは、データを「整列」させておくことです。DB がファイルへのパス/名前とともにファイルに関する情報を格納し、ファイルが移動された場合、完全に混乱する可能性があります。

于 2009-08-10T22:12:09.280 に答える
2

テストする必要があります。これらのソリューションはすべて、基盤となるファイルシステムに依存しています。巨大なディレクトリを扱えるファイルシステムもあれば、扱えないファイルシステムもあります。一部のファイル システムはディレクトリのインデックスを作成しますが、一部のファイル システムはインデックスを作成しません (これら 2 つのポイントは必ずしも関連しているわけではありません)。

物事をディレクトリのツリーに分割すると、パフォーマンスが向上する合理的な可能性があります。これは、最終的に、個々のディレクトリに全体的なエントリがほとんどない傾向があるためです。ファイルの線形ディレクトリ検索を行っている「愚かな」ファイルシステムでさえ、数百のエントリを合理的にすばやく検索できるため、これはほとんどのファイルシステムで機能します。

ファイルシステムがディレクトリのインデックスを作成している場合 (たとえば、btree のように、または単に内部的にソートすることは、このコンテキストでは事実上同じことです)、ディレクトリのサイズはそれほど重要ではありませんが、一部のツールは文句を言うことがあります (Windows エクスプローラ ウィンドウの読み込み何が起こるかを知っている4Mファイルで）。

そこで、あなたが計画しているオペレーティング システムとファイル システムのオプションを調査し、テストして、どれが最適かを判断します。

于 2009-08-10T23:10:21.940 に答える
2

1)これは、私が通常説教することとはまったく逆になりますが、ファイルは非常に小さいため、SQL データベースに保存することをお勧めします。また、SQL Server を使用すると、必要なファイルをすばやく簡単に見つけることができます。通常、このような大きなディレクトリを列挙することに関連するクレイジーなディスクの破棄は必要ありません。また、ファイルをSQLに保存すると（私は一般的に反対ですが）、バックアップ/復元プロセスが大幅に簡素化されます。

2)それらをすべてディレクトリに保存し、Windows インデックス サービス ( shivers ) でインデックスを作成するか、ファイル名とフル パスを含む独自のインデックスを SQL Server に作成します。それらを別々のディレクトリに保存し、それぞれ数万のファイルしかないことをお勧めします。おそらく、フォルダ名として注文年を使用できますか?

ファイルの保存方法に関係なく、ファイルを見つけるためにディレクトリをスキャンしないでください。何らかのインデックスが必要になることは間違いありません。

お役に立てれば！

于 2009-08-10T22:07:47.777 に答える
2

1) 単純なフォルダーは、別のインデックスを使用すると許容できるほど高速になる場合がありますが、サブディレクトリに配置するのは簡単なので、それを実行するだけで参照できます。
したがって、命名規則を理解する必要があります。私は通常、ID の均等な分散を取得するためにハッシュを提案しますが、多くのことを行っているため、既に取得している値を使用することはおそらく理にかなっています。注文番号がある場合、タイムスタンプもありますか? その場合は、注文番号の前にタイムスタンプを付けてください。

オーダー ID を使用している場合、http://en.wikipedia.org/wiki/Benford%27s_lawが発生する可能性があることに注意してください。

于 2009-08-10T22:35:55.270 に答える
1

PDFに変換された後にこれらすべてのファイルをDB（ブロブ）に保存することを検討しない理由 したがって、利点：

  1. OS I/O に直接対処する必要はなく、すべてを DB に任せる必要はないと思います。
  2. 命名をハッシュする必要はありません
  3. バックアップとメンテナンスが簡単
于 2009-08-10T23:27:14.090 に答える
1

サブディレクトリの論理的な順序を決定し、それらをフォルダー内の 512 個程度のファイルのブロックに格納します。

ファイルをデータベースに保存しないでください。データベースはデータ用であり、ファイル サーバーはファイル用です。ファイル サーバーに保存しますが、パスと取得情報はデータベースに保存します。

于 2009-08-10T22:09:05.123 に答える
1

データベースを使用してファイルを保存する場合、特に小さなファイルの場合、オーバーヘッドは小さいはずです。次のようなこともできます。

DELETE FROM BLOBTABLE WHERE NAME LIKE '<whatever>'

または、有効期限がある場合、またはファイルを更新したい場合は、次の方法でファイルを削除します。

DELETE FROM BLOBTABLE WHERE CREATIONDATE < ...
etc...
于 2011-08-24T17:37:59.413 に答える
0

質問：

これらのドキュメントを生成して PDF として保存する必要があるのはなぜですか?

生成できるのであれば、データをデータベースに保持し、必要なときにその場で生成しないのはなぜですか? つまり、とにかく検索に必要な実際のデータを検索でき、ファイルがディスク上にないということです。このようにして、何も再生成する必要なく、必要に応じて PDF テンプレートを更新することもできますか?

于 2009-08-10T22:07:34.343 に答える
0

ファイル データベースには 400 万を超えるフォルダーがあり、各フォルダーには多くのファイルがあります。

すべてのフォルダを 1 つのディレクトリに放り込むだけです。NTFS はこれを問題なく処理でき、移動する必要がある場合は robocopy などの高度なツールが役立ちます。

スキャンせずにファイルのインデックスを作成できることを確認してください。これを行うには、インデックスを mysql データベースに投げます。

そのため、ファイルを取得するために、いくつかのメタデータで mysql データベースを検索し、インデックスを取得します。次に、このインデックスを使用してファイルを直接読み取ります。これまでのところ、私にとってはうまくスケーリングされています。ただし、すべてをランダムアクセスに変換するため、ランダムな読み取り/書き込みになることに注意してください。これは HDD のパフォーマンスとしては不十分ですが、幸いなことに SSD は大いに役立ちます。

また、ファイルを mysql データベースに入れません。mysql を理解するクライアントがなければ、ネットワーク読み取りを行うことはできません。現在、ネットワーク URL を使用するだけで、任意のプログラムを使用してネットワーク経由で任意のファイルにアクセスできます。

于 2009-08-10T22:13:28.140 に答える
0

他の多くの人が言ったように、サブフォルダーを作成する必要がありますが、コードを介してデータを見つけることができる方法で行う必要があります。たとえば、日時が機能する場合は、それを使用します。あなたが言ったことを読むと、レポートには何らかの形の階層構造があるように見えます（毎日、毎週、毎日のXレポート、毎時のYレポートなど）レポートがいつ、なぜ生成されるかの構造を見て、構築します私のディレクトリはそのようになります。

于 2009-08-11T11:31:27.287 に答える