web-dev-qa-db-ja.com

AWS kinesisストリームのパーティションキーの総数を決定するにはどうすればよいですか？

プロデューサーとコンシューマーのWebアプリケーションでは、Kinesisストリームシャードのパーティションキーを作成するための思考プロセスはどうあるべきですか。 16個のシャードを持つKinesisストリームがあるとすると、いくつのパーティションキーを作成する必要がありますか？それは本当に破片の数に依存していますか？

amazon-kinesis
13
shivba

パーティション（またはハッシュ）キー：1から340282366920938463463374607431768211455まで。〜34020 * 10 ^ 34としましょう。簡単にするために、10 ^ 34は省略します。

均一に分割された30個のシャードがある場合、それぞれが1134 * 10 ^ 34ハッシュキーをカバーする必要があります。カバレッジはこのようになります。

_Shard-00: 0 - 1134 Shard-01: 1135 - 2268 Shard-03: 2269 - 3402 Shard-04: 3403 - 4536 ... Shard-28: 30619 - 31752 Shard-29: 31753 - 32886 Shard-30: 32887 - 34020_

また、3つのコンシューマーアプリケーション（これらの30のシャードをリッスンする）がある場合、それぞれが10のシャード（最適なバランス）をリッスンする必要があります。

これは、ストリームでのマージおよび分割操作についても説明しています。

  • 2つのシャードをマージするには、隣接するハッシュキーをカバーする必要があります。 Shard-03とShard-29をマージすることはできません。
  • 任意のシャードを分割できます。 shard-00を途中で分割すると、ディストリビューションは次のようになります。

_Shard-31: 0 - 567 Shard-32: 568 - 1134 Shard-01: 1135 - 2268 Shard-03: 2269 - 3402 Shard-04: 3403 - 4536 ... Shard-28: 30619 - 31752 Shard-29: 31753 - 32886 Shard-30: 32887 - 34020_

Shard-00は新しいデータを受け入れなくなりますを参照してください。 （Shard-00と）同じパーティションキー範囲でKinesisストリームに配置される新しいレコードは、Shard-31またはShard-32の下に配置されます。

Kinesis（つまりプロデューサー側）にデータを送信するときは、「データがどのシャードに送られるか」について心配する必要はありません。シャードでデータを効果的にスケーリングおよび配布するには、乱数（またはuuid、またはミリ単位の現在のタイムスタンプ）を送信するのが最適です。単一のシャード内のレコードの順序について心配しない限り、put_record要求には乱数/絶えず変化するパーティションキーを選択するのが最善です。

Javaでは、「putRecordsRequestEntry.setPartitionKey(Long.toString(System.currentTimeMillis()))」または「putRecordRequest.setPartitionKey(Long.toString(System.currentTimeMillis()))」を使用できます。

29
az3

それは完全にユースケースに依存します。確認する必要があるのは、必要に応じてキーのデータを集約できるように、関連するすべてのデータが単一のシャードに送られることだけです。

その要件がない場合は、ランダムキーを使用しても問題ありません。

3
bhanu tadepalli