2

私は SQL バックエンドをスケールアウトした経験はありませんが、これまで読んだ限りでは、書き込みのシャーディングと読み取りのキャッシュは、最も一般的な 2 つの方法のようです。適切なキャッシュ戦略を使用して結果整合性を最小限に抑える方法を学ぼうとしています。

テスト目的で、Azure SQL Database、Entity Framework & Elastic Sc​​ale ミドルウェア、および Redis を使用したいと考えています。

分散トランザクションを SQL Server と Redis の両方にコミットする方法はありますか?

そうでない場合、データベースの変更が発生したときに読み取りの鮮度を確保する効果的な方法は何ですか?

同じ API で SQL に書き込み、キャッシュを更新することはできましたが、何らかの理由でキャッシュへの書き込みが失敗する可能性があります。再試行ロジックを実装することもできますが、すべての試行が失敗した場合は、SQL トランザクションをロールバックするか、単純に古いキャッシュ データをクライアントに提供し、定期的にキャッシュを再構築してデータベースに追いつくことができます。もちろん、後者は、データ読み取りが一定期間一貫していないことを意味します。データを削除して SQL クラスターから読み取ることも別のオプションですが、クロスシャード クエリは非常にコストがかかる可能性があります。特に、複雑な結合が含まれており、コモディティ ハードウェア上に数千とは言わないまでも数百のデータベースがある場合はなおさらです。

4

2 に答える 2

1

シャーディングの最も重要な原則の 1 つは、「クロスシャード」クエリを回避しようとすることです。そうでなく、結合を行う必要がある場合、シャーディングは役に立たないと思います。読み取りキャッシュもありません。いくつかのプロジェクトでシャーディングを多用しています。そして、それはスケーラビリティに非常に役立ちますが、私が言ったように、私たちのサービスのごく一部は複数のシャードを必要とします. これは、サービスのニーズを考慮してシャード キーを選択したためです。そして、シャーディングの最も重要な決定は、適切なシャード キーを選択することだと思います。「完璧な」シャーディング キーを見つけることができれば、キャッシュをまったく使用せずにデータベースを直接使用できます。少なくともそれが私たちが今やっていることです。

于 2015-10-01T21:03:28.787 に答える