現在、キャッシュの目的で、1時間に約1,000個の小さなファイル（10k）を書き込みおよび削除するシステムを実行しています。近い将来、この数は約10,000〜20,000ファイルに増加し、1時間ごとに書き込みと削除が行われます。
書き込まれているすべてのファイルについて、1時間後にファイルが削除されると、mysqlDBに新しい行が追加および削除されます。
私の質問：
これは、オペレーティングシステム、ファイルシステム、およびファイルシステムキャッシュの構成に大きく依存します。また、これは、データベースが書き込み/削除されたファイルと同じディスクに保存されているかどうかによって異なります。
通常、ファイルの作成やファイルの削除など、ファイルシステムの構造に影響を与える操作には、同期ディスクIOが必要であるため、オペレーティングシステムは、電源障害後にこれらの変更を失うことはありません。ただし、一部のオペレーティングシステムとファイルシステムは、このためのより緩和されたポリシーをサポートしている場合があります。たとえば、FreeBSDのUFSファイルシステムには、これを行う優れた「ソフトアップデート」オプションがあります。おそらくetx3/Linusにも同様の機能があるはずです。
専用サーバーに移動したら、複数のHDDを接続し、データベースが1つのディスクに保存され、大量のファイル操作が別のディスクで実行されるようにするのが妥当だと思います。この場合、DBのパフォーマンスは影響を受けません。
いくつかの計算を行い、ストレージに必要なスループットを見積もる必要があります。最悪のシナリオでは、20000ファイルx 10K = 1時間あたり200MBであり、これは非常に低い要件です。最近のファイルシステムでは、ファイルの削除にかかる時間はごくわずかです。
私の意見では、特にアプリケーションがファイルを順番に作成および削除する場合は、心配する必要はありません。
最新のオペレーティングシステムは、パフォーマンスを向上させ、ディスクアクセスを減らすために、ファイルシステムの一部をメモリにキャッシュすることも考慮してください（これは、特に複数の削除に当てはまります）。
データベースは大きくなりますが、エンジンはそのために最適化されているため、気にする必要はありません。
唯一の欠点は、ファイルシステムがディスクの断片化にさらされている場合、多くの小さなファイルを処理するとディスクの断片化が発生する可能性があることです。
パフォーマンスを向上させるために、これらのファイルに別の物理ストレージを使用することを検討する必要があります（たとえば、別のディスクドライブまたはディスクアレイ）。これにより、他の干渉なしに全帯域幅転送を利用できるようになります。