web-dev-qa-db-ja.com

VARCHARキーまたはINTの使用

Yelpデータセット に基づいて、MySQLでデータウェアハウスを構築しています。

データセット内のほとんどのキーは文字列として与えられます：

_user_id                 review_id               business_id
hzw-qTUVpmLAKjdkoUNh8A  Awq_6cyNjK1-qPZAwnXjjQ  7p6tHUA1Pknh0DVWqz86lA
mldKxVI59o3LhK3ITG6mnA  96YkAuJzlT54qZZWNebFUg  7p6tHUA1Pknh0DVWqz86lA
SaedHW9i7k4lHR8tgwtMgQ  OfZRG7RgKA118zDtj6yo-g  7p6tHUA1Pknh0DVWqz86lA
_

それらを自己生成キーに転送するか（自動インクリメント整数）、そのままにするか（VARCHAR(22)）にします。

主キー/外部キーのデータタイプの選択における考慮事項は何ですか？

ありがとう

mysqlforeign-keyprimary-keydatatypesdata-warehouse
1
Dimgold

詳細な情報なしでは、質問に対する明確な答えはありません。ただし、選択は基本的に以下に基づく必要があります。

  1. データの読み込みの容易さ：キーをそのままにしておくと、同等のINTEGER idを作成する手間を大幅に節約できます（すべてのペアの間に等価テーブルが必要です。そして、 ETLプロセス を使用してデータをインポートするときにこの変換テーブルを使用します）。すべてのキーの長さが22文字の場合、char(22)の代わりにvarchar(22)を使用する方が良いでしょう。 1。 （AUTO_INCREMENTに対して）

  2. Size：データセットのサイズが非常に大きい場合、変換を行うと、テーブルの行とインデックスの両方でかなりのスペースを節約できます。いくつかのvarchar(22)と追加の列を持つ多くのインデックスがある場合、インデックスサイズの制限に達することができます 2。インデックス（およびテーブル）が小さいほど、システムのクエリのパフォーマンスは向上します。 （プロAUTO_INCREMENT）

  3. 新しいキー：データセットに行を追加したい場合、メカニズムよりも_AUTO_INCREMENT_キーの方が簡単ですvarchar(22)の一意のIDを生成します。 （プロAUTO_INCREMENT）

特定のニーズに応じて、長所と短所のバランスを取り、選択します。

Yelpデータセット の性質を考えると、おそらくsize効率のために、INTを使用します。 _business_id_、_review_id_、_user_id_および_photo_id_を翻訳する必要があります。別のcollectionsをアップロードする前に、JSONからCSVに変換し、配列を正規化されたサブテーブルに変換する必要がある場合は、1つの追加のステップを実行する必要があります。難しい。

メモ：

  1. コンテンツが固定サイズの場合、CHARを使用するとパフォーマンスが向上します。

    from： VARCHARとCHARの違いは何ですか？

  2. インデックスキーの最大長は、ページサイズが8KBの場合は1536バイト、ページサイズが4KBの場合は768バイトです。

    from 14.8.1.7 InnoDBテーブルの制限

注意事項： PostgreSQL および MADLib の使用を検討してください。この組み合わせにより、この種の課題に役立つツールがいくつか得られると思います。

1
joanolo

hugeデータセット、UUID、MD5、またはその他の「ランダム」文字列の場合、パフォーマンスはひどいです。または、少なくともインデックスが大きすぎてRAMにキャッシュできない場合。

これは、「次の」キーが、最近見たすべてのキーに関連した、またはそれに近いビットである可能性が低いためです。つまり、「キャッシュ」は役に立たなくなります。データがキャッシュの20倍の大きさである場合、95％（1-1/20）の時間でディスクがヒットします。

しかし、あなたはこれらの醜い細断に行き詰まっています。新しいID FROM_BASE64(CONCAT('7p6tHUA1Pknh0DVWqz86lA', '=='))を作成せずに、それらを少し詰めて、BINARY(16)列に入れることができます。まあそれは22バイトだけを16に縮小します。

文字列からauto_incrementを作成する場合、より長いrandom文字列をより短い文字列に交換するだけです。キャッシュの問題はまだ存在しますが、いくつかは未然に防ぐことができます。

と一緒に暮らすことをお勧めします

CHAR(22) CHARACTER SET ascii COLLATE ascii_bin
0
Rick James