でブロブスペースを取り戻す私は行サイズの98％を取り上げる大きなBLOBが含まれていますテーブルを構築する必要があります。ただし、このBLOBは一時的に行内に保持され、別の場所に移動され、BLOB列はNULLに設定されます。 MySQLはこのスペースを再利用できますか、それともいつも行の一部になりますか？自動的に再利用できない場合は、このスペースを手動で取り戻すために使用できる別の方法（最適化テーブルなど）がありますか？そうでない場合は、この特定のデータセットを処理するための別の解決策を見つける必要があります。あなたは間違いなくRedisのを使用するかだけでも、ファイルシステム上のあなたのブロブを格納したほうが良いだろうようMySQLはInnoDBの
が鳴ります。これは実際に私が推奨するものです。データをファイルに保存し、ファイル名をテーブルに置きます。 s3への非同期アップロードが完了したら、nullに設定します。ラージオブジェクトを処理するために最適化されたファイルシステムを使用している場合、データベースへの挿入よりも常に高速になります。塊が保存されているどのように正確に
は、データの長さではなく、また、あなたが実際に使用しているのMySQLのバージョンだけでなく、依存しています。削除された行はいつでも再利用することができます。後続の挿入がスペースを再利用しない場合は、最適化テーブルを使用して回復できます。しかし、最適化テーブルはそのテーブルをロックします。だから、システムを2度遅くしています。
私は実際にBLOBをSANに保存するというアイデアが気に入っています。速度を一定に保つために、プロセスを2つのスレッドに分割します.1つは、mysqlデータを保存するスレッドと、blobをファイルシステムに保存するスレッド（実際にはSAN）です。それらは並行して動作するので、すべてをmysqlにすべて保存するだけの速さです。次に、ファイルをS3に移動させ、新しい場所をmysql監査レコードにマークするvacuumプロセスを実行します。私たちの予想される負荷の下でテストされた後でさえ、魅力のように動作するようです。 – AlexGad
あなたはMySQLの外にそれを保存することができます、のはRedisのか、別のキー/値ストアを言わせて？ –
データは、バッチ処理された非同期処理によって他のストレージ（S3）に移動されます。最初の書き込みはトランザクション目的でmysqlでなければなりません。トランザクション中にRedis（または耐久性メッセージキュー）などの別のストアに移動することもできますが、このプロセスは高速パスでなければなりませんので、他の可動部分を追加することは躊躇しています。そのため、BLOBをS3に移動した後にスペースを再利用できるかどうか/ということに焦点を当てています。再利用する方法がまったくない場合は、Redisがアーキテクチャの一部であるため、おそらく次のオプションになります。 – AlexGad