SELECTクロス属性に従ってユーザーの高速化を可能にするデータベース設計を決定しようとしています。私は2種類の属性を持っています:
- フル - それぞれにこれらがあります。例: 場所/性別/年齢など.
- スリム - タグ/インタレストなど。ほとんどのユーザーは、50,000 の可能なオプションのうち ~7 を持っています。これらは一様に配布されているわけではありません。たとえば、多くのユーザーが関心を持っていますが、関心を持っ
Musicているのは少数Funk Rockです。
データ セットは数千万人なので、JOINS は避けようとしています。
データの保存:
完全な属性ごとに、ユーザーごとに列を保持できますSELECT。スリムな属性については、別のテーブルを作成することを考えていました。この場合、各ユーザーには複数の行があり、各行は属性を表します。
スリムな属性の SELECT は、私が問題に直面しているところです。パフォーマンスの低下を避けるために SELECT でテーブルを結合していないと仮定すると、SELECT を 2 つの異なるユースケースに分割することを考えていました。
- 人気のあるスリム属性を検索すると、
Music最初にそれに一致する C*SearchAmount ユーザーがスリム属性テーブルから検索され、次に完全な属性テーブルに従ってそれらがフィルター処理されます。フィルター処理が多すぎる場合は、より大きな C でこれを再度行います。 - 珍しいスリム属性を探して、それを逆にします。
これを実装する前に、この問題を解決するための他の/より良い方法について聞きたかった.