web-dev-qa-db-ja.com

マルチスレッド/並列挿入とハッシュパーティションからのSQL Serverのラッチ

SQLサーバーテーブルで並列マルチスレッド挿入を実行しており、ラッチを減らしたいと考えています。

ハッシュパーティションを利用してラッチを減らすことの欠点は何ですか？基本的にこれらすべての分割されたパーティションテーブルに対してクエリを実行することにより、クエリの速度が低下しますか？

1秒あたり約120のテーブル挿入、金融システムがあります。

その他の注意事項：SQL 2016システムは、年間約50 GBのSSDハードドライブ容量を使用します。現在、50コアプロセッサと150 GBのRAMを搭載しています。

プラットフォームは構築されていないため、テストするベースラインはありません。しかし、私はテスト計画と戦略を開発する必要があります。

ハッシュ分割の例：http://www.madeiradata.com/how-to-solve-the-tail-insert-problem- 2 /

CREATE PARTITION FUNCTION pf_hash (TINYINT) 
AS RANGE LEFT FOR VALUES (0,1,2,3,4,5,6,7,8);

CREATE PARTITION SCHEME ps_hash 
AS PARTITION pf_hash ALL TO ([PRIMARY]);

CREATE TABLE dbo.UserEntries_RegularWithHash 
(   
Id BIGINT IDENTITY NOT NULL,
UserId INT NOT NULL ,
CreatedDate DATETIME2 NOT NULL,
HashId AS CAST(Id % 9 AS TINYINT) PERSISTED NOT NULL,
CONSTRAINT PK_UserEntries_RegularWithHash 
PRIMARY KEY CLUSTERED (Id,HashId)
) 
ON ps_hash(HashId);
sql-serverdatabase-designpartitioningconcurrencyhashing
1
user129291

パーティション分割列を指定しないクエリは、すべてのパーティションを操作する必要があります。これは特に、ハッシュ値がクエリで指定されていないため、計算されたハッシュ列を使用してパーティション分割されたテーブルの問題です。 HashId値を指定できますが、そうするのは自然なことではありません。例：

--touches all 10 partitions
SELECT *
FROM dbo.UserEntries_RegularWithHash
WHERE Id = @Id;

--touches 1 partition
SELECT *
FROM dbo.UserEntries_RegularWithHash
WHERE Id = @Id
AND HashId = CAST(@Id % 9 AS TINYINT);

増分キーを持つパーティション化されていないテーブルに対するラッチ競合は、通常、非常に高い挿入率でのみ発生します。

正常なマシンでは、1秒あたり120回の挿入でラッチの競合は発生しません。 David Browne-Microsoft 毎秒10,000挿入が推奨されるのは、ラッチの競合が懸念されるポイントです。行サイズやハードウェアなどの要因に依存するため、おそらくこれはSwagとしては良いものです。ラッチの競合を考慮する前に、1秒あたり数千の速度が必要になると思います。その時点で、インメモリOLTPテーブル、および/または一括/バッチ挿入を検討することができます。

早期の最適化がすべての悪の根源であると言われていると聞いています。この場合、ラッチの競合を回避するためだけにパーティション分割を導入することはありません。

6
Dan Guzman