Class.MemoryStoreデータ構造のリリースに伴い、Roblox は個々のデータ構造のすべての既存の制限を削除し、単一の「per-Partition」制限に置き換えました。この制限は内部の値と自動パーティョンプロセスがデータを分配する方法に基づいて変更されますが、
パーティション
MemoryStores API は、ストレージの子分の パーティション にデータを保存します。MemoryStores API は、ストレージの子分のパーティションにデータを保存します。アイテムをメモリストアに書き込むたびに、そのアイテムはそのパーティションに正確に保存されます。パーティションは、MemoryStores API によって完全に管理されます。自分でパーティシ
パーティションの割り当て
パーティションストレージは、アイテムが保存されているデータ構造によって異なります。ソートされたマップとキューには、各データ構造にパーティションが割り当てられます。
たとえば、PlayerScores という名前のソートされたマップと、PlayerLine という名前の待っているプレイヤーの数でカーニバルゲームを考えてみてください：
ソートされたマップとキューとは異なり、ハッシュマップは複数のパーティションに分割され、データはこれらのパーティション間で自動的に分配されます。「Prizes」というハッシュマップを追加すると、パーティションは次のように表示される場合があります。
ハッシュマップがすべてのパーティションに存在する方法、および各パーティションにはいくつかのアイテムのサブセットがあることに注意してください。
制限
パーティション限定を設定すると、データ構造のすべてのパーツに高い通信量が提供できます。また、ハッシュマップも好ましいです、因みに彼らはすべてのパーティションに分配されます。
たとえば、150,000件のリクエストを1分あたり15,000件 (RPM) のパーティション限度を考慮してください：
- 最高の場合、ソートされたマップとキューは、150,000 RPM に制限されます。それぞれ単一のパーティションに住んでいるためです。
- マップをハッシュするリクエストは、パーティションごとに拡張されるアイテムキーに分散されるため、ハッシュマップは、制限を迅速に絶妨するために、他のデータ構造の多くの場合、減速するためにはるかに高い効果の上限があります。
この理由で、ソートまたは「最初に入力して最後に出力する」機能は必要ない場合、ハッシュマップは通常メモリストアデータ構造の最適な選択です。詳細は、「ベストプラクティス」を参照してください。