database - データベースのテキスト フィールドのデータ冗長性を減らす方法

Question

OLAP システムを使用しています。一部のテーブルにはテキスト フィールドがあります。テキストの長さは数バイトから KB まで可能ですが、1 行の他の固定サイズ フィールドのサイズは約 100 バイトにすぎません。

一部のテーブルには数十億の行があり、テキスト フィールドの値は非常に繰り返し可能です。この種の冗長性を減らしてストレージ スペースを節約し、クエリのパフォーマンスを失わないようにするにはどうすればよいですか?

Answer 1

冗長性は、データベース作業における専門用語です。「繰り返す」という意味ではありません。「無駄に繰り返す」という意味です。不必要な繰り返しはないでしょう。ユーザーに正しい意味を伝えるために、各値はそれぞれの行に必要です。

場合によっては、既存の値を人間が読める短いコードに置き換えることができます。コードを短くするとテーブルが狭くなり、データベース内のページあたりの行数が増え、I/O が高速になります。たとえば、米国では、州名の代わりに 2 文字の郵便番号を使用することがよくあります。これはほとんど常に機能します。(つまり、人間はそれ以上処理せずに出力を読み取ることができ、クエリは少なくとも少し速く実行されます。)

場合によっては、既存の値を代理キーに置き換えて、追加の結合のコストがディスク I/O の高速化によって上回ることを期待できます。この戦術がうまくいかない場合もあります。テストを行い、元のスキーマに戻す準備をする必要があります。

Answer 2

レポート DB の URL が原因で、以前に問題が発生しました。URL をホスト名/ポート、パス、およびクエリ文字列の 3 つの部分に分割することは、試してみる価値があるかもしれません。URL フラグメント テーブル (おそらく複数) と、URL への FK を含む URL テーブルになる可能性があります。フラグメント テーブル。クエリ文字列を個別に保存する価値がない場合があります。その場合、URL テーブルにはホスト名とパスの FK があり、クエリ文字列が保存されます。

もう 1 つのアイデアは、クエリ文字列の不要な部分を切り取ることです。この決定は、アプリケーションごとに行う必要がありますが、大きな違いを生む可能性があります。URL からセッション ID を削除すると、状況が劇的に改善されます (また、おそらく切り取ることができます)。 Google アナリティクス パラメータ。

また、必要な場合にのみ URL テーブルにアクセスし、少なくともホスト名にインデックスがあることを確認してください。