数億の小さなファイルを効率的に保存します。 セルフホスト型ソリューション

コミュニティの皆様、この記事では、数億の小さなファイルを効率的に保存および取得することに焦点を当てます。 現段階では、クラスタ ロックを含むロックを完全にサポートし、一見松葉杖がなくても見える POSIX 互換ファイル システム用の最終ソリューションが提案されています。

そこで、この目的のために独自のカスタム サーバーを作成しました。
このタスクを実装する過程で、私たちは主な問題を解決することができ、同時にクラスター ファイル システムが容赦なく消費していたディスク領域と RAM を節約することができました。 実際、このような数のファイルは、クラスタ化されたファイル システムにとって有害で​​す。

アイデアは次のとおりです。

簡単に言うと、小さなファイルはサーバー経由でアップロードされ、アーカイブに直接保存され、アーカイブから読み取られ、大きなファイルは並べて配置されます。 スキーム: 1 フォルダー = 1 アーカイブ。合計で、数億のファイルではなく、小さなファイルを含む数百万のアーカイブがあります。 これらすべては、スクリプトを使用したり、ファイルを tar/zip アーカイブに入れたりすることなく、完全に実装されます。

短くするように努めますが、投稿が長くなる場合は予めご了承ください。

すべては、従来のアーカイブやオブジェクト ストレージに特有の欠点を持たずに、HTTP プロトコル経由で受信したデータを直接アーカイブに保存できる適切なサーバーが世界中で見つからなかったという事実から始まりました。 そして、検索の理由は、10 台のサーバーからなるオリジン クラスターが大規模に成長し、すでに 250,000,000 億 XNUMX 個の小さなファイルが蓄積されており、その増加傾向が止まらなかったことです。

記事を読むのが好きではない人にとっては、ちょっとしたドキュメントの方が簡単です。

ここで и ここで.

同時に docker を使用する場合、念のため内部に nginx を使用するオプションのみが追加されました。

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

次へ：

ファイルが多数ある場合は、大量のリソースが必要となり、最悪の場合、一部のファイルが無駄になることです。 たとえば、クラスター化されたファイル システム (この場合は MooseFS) を使用する場合、ファイルは実際のサイズに関係なく、常に少なくとも 64 KB を占有します。 つまり、サイズが 3、10、または 30 KB のファイルの場合、ディスク上に 64 KB が必要になります。 ファイルが 2 億個ある場合、10 テラバイトから 1 テラバイトが失われます。 MooseFS には、各ファイルの XNUMX つのレプリカで XNUMX 億を超えないという制限があるため、新しいファイルを無制限に作成することはできません。

ファイルの数が増えると、メタデータ用に大量の RAM が必要になります。 大規模なメタデータ ダンプが頻繁に発生することも、SSD ドライブの消耗の原因となります。

wZDサーバー。 ディスク上で物事を整理します。

サーバーは Go で書かれています。 まず第一に、ファイルの数を減らす必要がありました。 どうやってするの？ アーカイブのためですが、私のファイルは単なる圧縮された画像であるため、この場合は圧縮なしです。 依然として欠点を取り除く必要があったため、BoltDB が役に立ちました。これはドキュメントに反映されています。

私の場合、合計で 10 億個のファイルではなく、1 万個のボルト アーカイブしか残っていませんでした。 現在のディレクトリのファイル構造を変更する機会があれば、ファイル数を約 XNUMX 万個まで減らすことができるでしょう。

すべての小さなファイルは、Bolt アーカイブにパックされ、ファイルが配置されているディレクトリの名前が自動的に取得され、すべての大きなファイルはアーカイブの隣に残ります。パックすることに意味はありません。これはカスタマイズ可能です。 小さいものはアーカイブされ、大きいものは変更されずに残ります。 サーバーは両方に対して透過的に動作します。

wZD サーバーのアーキテクチャと機能。

サーバーは、Linux、BSD、Solaris、および OSX オペレーティング システムで動作します。 Linux では AMD64 アーキテクチャのみをテストしましたが、ARM64、PPC64、MIPS64 でも動作するはずです。

主な特徴：

• マルチスレッド。
• マルチサーバー。耐障害性と負荷分散を提供します。
• ユーザーまたは開発者に対する最大限の透明性。
• サポートされている HTTP メソッド: GET、HEAD、PUT、および DELETE。
• クライアント側ヘッダーによる読み取りおよび書き込み動作の管理。
• 高度に構成可能な仮想ホストのサポート。
• 書き込み/読み取り時の CRC データ整合性をサポートします。
• メモリ消費を最小限に抑え、ネットワーク パフォーマンスを最適に調整するための半動的バッファ。
• データ圧縮の遅延。
• さらに、サービスを停止せずにファイルを移行するためのマルチスレッド アーカイバ wZA が提供されています。

実際の経験:

私はかなり長い間、ライブ データを使用してサーバーとアーカイバを開発およびテストしてきましたが、現在では、別個の SATA ドライブ上の 250,000,000 ディレクトリにある 15,000,000 個の小さなファイル (画像) を含むクラスタ上で正常に動作しています。 10 台のサーバーからなるクラスターは、CDN ネットワークの背後にインストールされたオリジン サーバーです。 これをサービスするには、2 つの Nginx サーバー + 2 つの wZD サーバーが使用されます。

このサーバーを使用することに決めた場合は、使用する前に、必要に応じてディレクトリ構造を計画することが賢明です。 すぐに予約しておきますが、サーバーは 1 Bolt アーカイブにすべてを詰め込むことを意図したものではありません。

性能試験：

ZIP ファイルのサイズが小さいほど、そのファイルに対する GET および PUT 操作の実行が速くなります。 HTTP クライアントによる通常のファイルとBolt アーカイブへの書き込み時間と読み取り時間の合計を比較してみましょう。 サイズ 32 KB、256 KB、1024 KB、4096 KB、および 32768 KB のファイルでの作業が比較されます。

Bolt アーカイブを使用する場合、各ファイルのデータ整合性がチェックされ (CRC が使用されます)、記録前と記録後にオンザフライの読み取りと再計算が発生します。これにより当然遅延が発生しますが、重要なのはデータのセキュリティです。

SATA ドライブでのテストでは明確な違いが示されないため、SSD ドライブでパフォーマンス テストを実施しました。

テスト結果に基づくグラフ:

ご覧のとおり、小さなファイルの場合、アーカイブされたファイルとアーカイブされていないファイルの間の読み取り時間と書き込み時間の差はわずかです。

サイズが 32 MB のファイルの読み取りと書き込みをテストすると、まったく異なる状況が得られます。

ファイルの読み取り間の時間差は 5 ～ 25 ミリ秒以内です。 録音すると状況はさらに悪化し、その差は約 150 ミリ秒になります。 ただし、この場合、大きなファイルをアップロードする必要はなく、アップロードすることにまったく意味がなく、アーカイブとは別に保存することができます。

*技術的には、このサーバーは NoSQL を必要とするタスクに使用できます。

wZD サーバーを操作する基本的な方法:

通常のファイルをロードする:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

ファイルをBoltアーカイブにアップロードします(アーカイブに含めることができる最大ファイルサイズを決定するサーバーパラメータfmaxsizeを超えていない場合、超えた場合、ファイルは通常どおりアーカイブの隣にアップロードされます):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

ファイルのダウンロード (ディスク上とアーカイブ内に同じ名前のファイルがある場合、ダウンロード時には、デフォルトでアーカイブされていないファイルが優先されます):

curl -o test.jpg http://localhost/test/test.jpg

Bolt アーカイブからファイルをダウンロードする (強制):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

他のメソッドの説明はドキュメントに記載されています。

wZD ドキュメント
wZA ドキュメント

サーバーは現在 HTTP プロトコルのみをサポートしており、HTTPS ではまだ動作しません。 POSTメソッドもサポートしていません(要否は未定)。

ソース コードを掘り下げた人は誰でもそこにバタースコッチを見つけるでしょう。誰もがそれを好むわけではありませんが、割り込みハンドラーを除いて、メイン コードを Web フレームワークの関数に結び付けていないので、将来的には、ほとんどすべてのコードを簡単に書き直すことができます。エンジン。

TODO：

• クラスターファイルシステムを持たない大規模システムでの使用を可能にする独自のレプリケーターとディストリビューター + geo の開発 (すべて大人向け)
• メタデータが完全に失われた場合の完全な逆回復の可能性（ディストリビュータを使用している場合）
• 永続的なネットワーク接続とさまざまなプログラミング言語のドライバーを使用できるネイティブ プロトコル
• NoSQL コンポーネントを使用するための高度な可能性
• Bolt アーカイブ内のファイルまたは値、および通常のファイルのさまざまなタイプの圧縮 (gzip、zstd、snappy)
• Bolt アーカイブ内のファイルまたは値と通常のファイルのさまざまなタイプの暗号化
• GPU を含むサーバー側のビデオ変換の遅延

私はすべてを持っています。このサーバーが誰かの役に立てば幸いです。BSD-3 ライセンス、二重著作権、もし私が働いている会社がなければ、サーバーは作成されなかったでしょう。 開発者は私だけです。 バグや機能のリクエストを見つけていただければ幸いです。

出所： habr.com