3

私は、テーブルの 1 つが非常に大きくなる可能性があり (ギガバイトのオーダー)、テーブル操作の大部分が書き込みである、MySQL データベースによってバックアップされた Web アプリを作成している最中です。テーブル列の 1 つは、非常に大きな文字列シーケンスを格納する必要があります。これまでのテストでは、サイズは 289 バイトに達しましたが、念のため、最大サイズを 1 kb に設計したいと考えています。現在、その列を MySQL MediumBlob フィールドとして InnoDB テーブルに格納しています。

同時に、BLOB と他の形式のストレージの相対的な長所と短所を確立するためにグーグル検索を行ってきました。世の中には情報があふれています。多すぎるかもしれません。私が収集したのは、InnoDB が BLOB の最初の数バイト (メモリが正しく機能する場合は 789) をテーブル行自体に格納し、残りを他の場所に格納することです。行に列ごとに複数の BLOB (私のテーブルにはありません) がある場合、「他の場所」は各 BLOB の異なる場所であるという考えも持っています。それとは別に、BLOB データへのアクセスは、行データへのアクセスよりも大幅に遅いという印象を受けました (これは理にかなっているように思えます)。

私の質問はまさにこれです-私のBLOBサイズとテーブルの潜在的な大きなサイズを考慮して、ブロブをまったく気にする必要がありますか? また、代わりに何らかの形式の行内ストレージを使用すると、テーブルが収容できる行の最大数に悪影響を与えませんか?

MySQL はきちんとしていて、私の開発環境のほとんどすべてを手放すことができます。しかし... それは現実の世界ではありません。

4

2 に答える 2

1

BLOB データが 250kb を超える場合、その価値はありません。あなたの場合、私はBLOB'nで気にしません。これを読む

于 2012-09-27T15:52:00.627 に答える
1

すでにここをご覧になっていると思いますが、InnoDB の制限に関しては覚えておかなければならないことがたくさんあるため、いくつかの詳細を見落としがちです。

あなたの質問の 1 つ (テーブルの最大サイズ) に対する簡単な答えは 64TBytes です。可変サイズ型を使用してそのストレージを別のファイルに移動すると、確かに行数の上限が変更されますが、64TBytes は非常に多くのスペースであるため、比率は非常に小さい可能性があります。

テーブル内に格納されている 1KByte 文字列型の列を持つことは、64TBytes に比べて非常に小さいため、実行可能なソリューションのように思えます。特に、クエリ速度に対して非常に厳しい要件がある場合。

また、InnoDB の 64TByte 制限は、使用している OS の最大ファイル サイズによって押し下げられる可能性があることに注意してください。テーブルのスペースを増やすために、いつでも複数のファイルをリンクすることができますが、少し面倒になり始めています。

于 2012-09-27T15:52:25.813 に答える