Data Vault 2.0 では、ビジネス キーをハッシュし、このハッシュをテーブルの主キーとして使用します。また、リンク テーブルはハッシュ主キーを使用して関係を作成します。
私の問題は、基本的にランダムなハッシュに関するものです。統計はもちろん、ランダムに分散されたデータには使用できないため、クエリオプティマイザーは適切な推定を適用できません。
そのため、クエリ オプティマイザーは、頻繁に並べ替えたい場合に奇妙な計画を使用します (並べ替える行が 4 行しかないと考えているため)。SQL Server でデータ ボールトを扱うのは私が初めてではないので、これをどのように修正できますか?
クエリ オプティマイザーがインデックス シークまたは結合演算子を使用すると、行の見積もりが完全に失われ、ばかげた計画が選択されます。
そこから何かを得るには、(FORCE ORDER) などの結合ヒントとクエリ ヒントを使用してそれらをポンピングする必要があります。
これに対する一般的なアプローチは何ですか？
ハッシュ化すると、構造/順序を持つすべてのデータが完全にランダムになり、有用なデータベース統計が不可能になるというあなたの結論に固く同意します。
私は実際にSQLサーバーでいくつかの実験を行い、 Explain Plansによってサポートされている、あなたと同じ結論に達しました
そのため、連結されたビジネスキーをハッシュする代わりに主キーとして使用することを検討する必要があると確信しています。
ハッシュに与えられる引数は、次の領域にあります。
しかし、引数 1 の証拠をまだ見ていません。あなたが言及しているように、参加すると有用な統計が失われます! さらに、私が知っている自然なビジネス キーの多くは、実際には 32 文字よりもはるかに小さいものです...実際、数日前にこの件に関連する質問をしました...
次に、引数 2 へ: ほとんどのMPP NoSQL データベース(キー値、ドキュメント、列ファミリー) では、ハッシュではなく、適切なNATURAL (連結) キーをシャーディング キーとして実際に使用することをお勧めします。例: Cassandra に関するこのアドバイスを参照してください。
これが、私がData Vault 2 のハッシュ理論に同意しない理由です。これを裏付ける証拠は見たことがありません。これが、10 月に DMZone ベルリンで新しいEnsemble モデリング アプローチを提案する理由の 1 つです。