タグ付けされた質問 「hashing」

ETLプロセスの一環として、ステージングからの行をレポートデータベースと比較して、データが最後に読み込まれてから実際に変更された列があるかどうかを確認します。 この比較は、テーブルの一意のキーと、他のすべての列のある種のハッシュに基づいています。現在HASHBYTES、このSHA2_256アルゴリズムで使用しており、多数の並行ワーカースレッドがすべて呼び出している場合、大規模サーバーではスケーリングしないことがわかりましたHASHBYTES。 96コアサーバーでテストする場合、1秒あたりのハッシュで測定されるスループットは、16を超える同時スレッドを増加させません。同時MAXDOP 8クエリの数を1〜12に変更してテストします。テストでMAXDOP 1は、同じスケーラビリティのボトルネックが示されました。 回避策として、SQL CLRソリューションを試したいと思います。要件を述べるための私の試みは次のとおりです。 関数は並列クエリに参加できる必要があります 関数は決定的でなければなりません この関数は、NVARCHARまたはVARBINARY文字列の入力を受け取る必要があります（関連するすべての列は連結されます） 文字列の一般的な入力サイズは、長さが100〜20000文字です。20000は最大値ではありません ハッシュ衝突の可能性は、MD5アルゴリズムとほぼ同等かそれ以上でなければなりません。CHECKSUM衝突が多すぎるため、機能しません。 この機能は、大規模なサーバーで適切にスケーリングする必要があります（スレッド数が増加しても、スレッドあたりのスループットが大幅に低下することはありません） Application Reasons™の場合、レポートテーブルのハッシュの値を保存できないと仮定します。これは、トリガーまたは計算列をサポートしないCCIです（他の問題もありますが、これには入りたくありません）。 HASHBYTESSQL CLR関数を使用してシミュレートするスケーラブルな方法は何ですか？私の目標は、大規模なサーバーでできる限り多くのハッシュを毎秒取得することであると表現できるため、パフォーマンスも重要です。私はCLRがひどいので、これを達成する方法がわかりません。誰かに答える動機があれば、できるだけ早くこの質問に報奨金を追加する予定です。以下は、ユースケースを非常に大まかに示すクエリの例です。 DROP TABLE IF EXISTS #CHANGED_IDS; SELECT stg.ID INTO #CHANGED_IDS FROM ( SELECT ID, CAST( HASHBYTES ('SHA2_256', CAST(FK1 AS NVARCHAR(19)) + CAST(FK2 AS NVARCHAR(19)) + CAST(FK3 AS NVARCHAR(19)) + CAST(FK4 AS NVARCHAR(19)) + CAST(FK5 …

29 sql-server  sql-server-2016  etl  sql-clr  hashing 

比較のために、nvarcharデータのハッシュ値を作成する必要があります。T-SQLには複数のハッシュアルゴリズムがありますが、このシナリオで選択するのに最適なものはどれですか？ 2つの異なるnvarchar値のハッシュ値が重複するリスクが最小になるようにします。インターネットでの私の研究に基づいて、MD5が最高のようです。そうですか？MSDNは、利用可能なアルゴリズムについて（下記のリンク）を教えてくれますが、どの条件のどのアルゴリズムに関する説明はありませんか？ HASHBYTES（Transact-SQL） 2つのテーブルを2つのnvarchar（max）列で結合する必要があります。ご想像のとおり、クエリの実行には時間がかかります。各nvarchar（max）データのハッシュ値を保持し、ブロブであるnvarchar（max）値ではなく、ハッシュ値で結合を行う方が良いと考えました。問題は、どのハッシュアルゴリズムが一意性を提供するかです。そのため、1つ以上のnvarchar（max）に対して1つのハッシュ値を持つリスクに直面することはありません。

20 sql-server  sql-server-2008-r2  t-sql  hashing 

このタイプの構造をredisで作成したい：（基本的にはjsonデータ） { "id": "0001", "name":"widget ABC", "model": "model123", "service":"standard", "admin_password": 82616416, "r1": { "extid":"50000", "password":"test123", }, "r2": { "ext":"30000", "password":"test123", }, } これまでに試したこと： 私は「サブ」ハッシュなしでハッシュを作成しようとしましたが、これは基本的なことを確認するためです。これが、redis-cliから始めたものです。 HMSET widget:1 id 0001 name 'widget ABC' model 'model123' service standard admin_password 82616416 HMSET widget:2 id 0002 name 'widget ABC' model 'model123' service standard admin_password 12341234 …

12 nosql  redis  hashing 

チャットディスカッションで生じた質問： ハッシュ結合の救済が内部で一種のネストされたループに切り替わることを知っています。 SQL Serverはハッシュ集約救済のために何をしますか（それが発生する可能性がある場合）？

10 sql-server  execution-plan  aggregate  database-internals  hashing 

SQL Serverのカバーの下でExcept演算子がどのように機能するかの内部アルゴリズムは何ですか？内部的に各行のハッシュを取得して比較しますか？ David Lozinksiは、SQLの調査を実行しました。新しいレコードが存在しない場合に、新しいレコードを挿入する最も速い方法です。以下の結果に密接に関連しています。 前提：1つの列のみを比較するため、左結合が最も高速になると思いますが、すべての列を比較する必要があるため、例外として最も時間がかかります。 これらの結果により、今、私たちの考えは、自動的かつ内部的に各行のハッシュを取ることを除いてですか？私は実行計画を除いて見て、それはいくつかのハッシュを利用しています。 背景：私たちのチームは2つのヒープテーブルを比較していました。テーブルAテーブルBにない行がテーブルBに挿入されました。 （レガシーテキストファイルシステムの）ヒープテーブルには、主キー/ GUID /識別子はありません。一部のテーブルには重複行があったため、各行のハッシュを見つけ、重複を削除して、主キー識別子を作成しました。 1）最初に、（ハッシュ列）を除いて、exceptステートメントを実行しました select * from TableA Except Select * from TableB, 2）次に、HashRowIdの2つのテーブル間で左結合比較を実行しました select * FROM dbo.TableA A left join dbo.TableB B on A.RowHash = B.RowHash where B.Hash is null 驚いたことに、Except Statement Insertが最速でした。 結果は実際にDavid Lozinksiのテスト結果に近いマップ

10 sql-server  sql-server-2016  performance-tuning  hashing  except 

PostgreSQL 9.2 私は違いを理解しようとしているHash Semi JoinだけにHash Join。 2つのクエリを次に示します。 私 EXPLAIN ANALYZE SELECT * FROM orders WHERE customerid IN (SELECT customerid FROM customers WHERE state='MD'); Hash Semi Join (cost=740.34..994.61 rows=249 width=30) (actual time=2.684..4.520 rows=120 loops=1) Hash Cond: (orders.customerid = customers.customerid) -> Seq Scan on orders (cost=0.00..220.00 rows=12000 width=30) (actual time=0.004..0.743 rows=12000 loops=1) …

8 postgresql  join  hashing 

ハッシュインデックスをサポートするPostgresのすべてのバージョンについて、少なくともバージョン8.3までは、ハッシュインデックスがbtreeインデックスより「類似または遅い」または「良くない」という警告または注意があります。ドキュメントから： バージョン7.2： 注：ハッシュインデックスのユーティリティは限られているため、通常はハッシュインデックスよりもBツリーインデックスの方が適しています。=比較の場合でも、ハッシュインデックスが実際に Bツリーよりも速いという十分な証拠はありません。さらに、ハッシュインデックスにはより粗いロックが必要です。セクション9.7を参照してください。 バージョン7.3（および8.2まで）： 注：テストの結果、PostgreSQLのハッシュインデックスはBツリーインデックスと同じかそれより遅いことがわかりました。また、ハッシュインデックスのインデックスサイズとビルド時間ははるかに悪いです。また、同時実行性が高いと、ハッシュインデックスのパフォーマンスが低下します。これらの理由により、ハッシュインデックスの使用はお勧めしません。 バージョン8.3： 注：テストは実行しないように、PostgreSQLのハッシュインデックスを示したは良い B-treeインデックスよりも、およびハッシュインデックスのインデックスサイズと構築時間ははるかに悪いです。さらに、ハッシュインデックス操作は現在WALログに記録されていないため、データベースクラッシュ後にハッシュインデックスをREINDEXで再構築する必要がある場合があります。これらの理由により、ハッシュインデックスの使用は現在推奨されていません。 このバージョン8.0のスレッドでは、ハッシュインデックスが実際にbtreeよりも高速であるケースを発見したことはなかったと主張しています。 バージョン9.2でさえ、このブログの投稿（2016年3月14日）によると、実際のインデックスを作成する以外のパフォーマンス向上はほとんどありませんでした： AndréBarbosaによるPostgresのハッシュインデックス。 私の質問は、それはどのようにして可能ですか？ 定義により、ハッシュインデックスはO(1)操作であり、btreeはO(log n)操作です。ではO(1)、正しいブランチを見つけてから正しいレコードを見つけるよりも、ルックアップの速度が遅い（またはそれに似ている）のはどうしてでしょうか。 索引付け理論について、それを可能にすることは決してありません。

8 postgresql  index  btree  hashing