問題タブ [cardinality-estimation]

Flajolet et alによるHyperLogLog アルゴリズムは、ごく少量のメモリを使用してセットのカーディナリティを推定する巧妙な方法を説明しています。ただし、計算では元のセットのN個の要素すべてが考慮されます。元のNの小さなランダムサンプル（たとえば、10％）にしかアクセスできなかった場合はどうなりますか？HyperLogLogまたは同様のアルゴリズムをこの状況にどのように適応させることができるかについての研究はありますか？

これは本質的に、明確な価値の推定として説明されている問題であり、豊富な研究が存在することを認識しています（概要については、たとえばこの論文を参照してください）。ただし、私が知っている明確な値の推定に関する調査では、HyperLogLogで使用されているアプローチとは非常に異なる多くのアドホック推定量を使用しています。したがって、誰かがHyperLogLogを明確な値の見積もりの​​問題に適応させることをすでに考えているのではないかと思います。

このスケッチを理解しようとしていますが、理解できません。間違っている場合は修正してください。基本的に、テキスト データがあるとしましょう..単語..ハッシュ関数があります..単語を取得して整数ハッシュを作成し、そのハッシュをバイナリ ビット ベクトルに変換しますか?? 右..次に、左から見た最初の 1 を追跡します..そして、その 1 の位置 (たとえば、k)... このセットのカーディナリティは 2^k ですか?

http://ravi-bhide.blogspot.com/2011/04/flajolet-martin-algorithm.html

しかし... 一言だけ言っておきます。それのハッシュ関数は、それが生成するハッシュが2 ^ 5であるようなものであり、私は5つの(??)末尾の0があると推測しています?? 2^5 (??) カーディナリティを予測しますか? それは正しく聞こえませんか？何が足りないの

データ ウェアハウス データベースを使用していますが、SQL Server 2014 の新しいカーディナリティ エスティメーターの問題に直面しています。

データベース サーバーを SQL Server 2014 にアップグレードした後、クエリのパフォーマンスに大きな違いがあることがわかりました。一部のクエリの実行が大幅に遅くなります (SQL 2012 では 30 秒、SQL 2014 では 5 分)。実行計画を調査した後、SQL Server 2014 でのカーディナリティの見積もりがかなりずれており、その理由を見つけることができないことがわかりました。

SQL 2012 と SQL 2014 のクエリ実行プラン (左上の演算子) の例を次に示します。

いくつかの詳細:

• 私のクエリは、典型的なデータ ウェアハウスのファクト テーブル ロード クエリです。トランザクション テーブルにクエリを実行し、多数 (15 ～ 20) のディメンション テーブルを結合します (ディメンション テーブルから結合されるレコードは常に 0 または 1 です)。

• 統計が最新であることを確認するために、(FULLSCAN を使用して) すべてのテーブルの統計を更新しました。

• ディメンション テーブルのビジネス キーにはインデックスが付けられます (一意の非クラスター化インデックス)。このインデックスの一意性のために、古い基数推定器 (SQL 2012) は最大があると正しく想定しているように思えます。結合する 1 つのレコード (実行計画でレコードの推定数は変わりません)。

問題を最も単純な例に絞り込もうとしました - 2 つの結合を持つ SELECT:

SQL 2012 と SQL 2014 での演算子 1 と 2 のカーディナリティの見積もりは次のとおりです。

ご覧のとおり、SQL Server 2014 は見積もりを 30% 以上下回っています (10000 対 7653)。私はcaを持っているので。典型的なクエリで 15 ～ 20 の結合が行われると、最終的な見積もりは大きく外れます。

データベースを下位の互換性モード (110) にすると正常に動作しますが (SQL Server 2012 と同じ)、この動作の理由を知りたいです。SQL Server 2014 のカーディナリティ エスティメータの結果が間違っているのはなぜですか?

私たちの実稼働環境では、SQL server 2012 SP2+Windows Server 2008R2. 3 か月前に、すべてのサーバーを に移行しましたSQL Server 2014 SP1+Windows Server 2012 R1。新しい構成 (より多くの RAM、より多くの CPU、より多くのディスク容量) で新しいサーバーを作成し、データベースをバックアップします--> 新しいサーバーSQL Server 2012に復元します。SQL Server 2014復元後、互換性レベルを 110 から 120 + インデックスの再構築 + 統計の更新に変更しました。

しかし、現在、互換性レベル 120 の場合、いくつかのクエリの実行が非常に遅くなるという問題があります。互換性レベルを古い 110 に変更すると、非常に高速に実行されます。

この問題についてよく検索しましたが、何も見つかりませんでした。

hazelcast で基数サービスを取得する際に問題があります。次のコードでは、カーディナリティ エスティメータに訪問者を追加します。messageIDは一意です。このコードにより、5K のユニークな項目で満たされたテスト環境で。

別のクラスのviewsListの有効期限で、リスナー コードを記述します。前のコードでは、エントリ イベント キーは messageID でした。しかし、この関数を呼び出すと、訪問は0です。空の別のオブジェクトを取得しているようです。