Partitions et distribution des données

*Ce contenu est traduit en utilisant l'IA (Beta) et peut contenir des erreurs. Pour consulter cette page en anglais, clique ici.

Avec la sortie de la structure de données MemoryStoreHashMap, Roblox a supprimé toutes les limites existantes pour les structures de données individuelles et les a remplacées par une seule limite de throttling "par partition" globale. La limite exacte fluctue en fonction de valeurs internes et de la manière dont le processus de partitionnement automatique distribue vos données, mais permet généralement une utilisation beaucoup plus élevée avant throttling, notamment pour les tables de hachage. Cette nouvelle limite permet une utilisation flexible des magasins mémoire à travers toutes les structures de données.

Partitions

L'API MemoryStores stocke des données sur des partitions, qui ne sont que des subdivisions de stockage. Chaque fois que vous écrivez un élément dans un magasin mémoire, cet élément est stocké sur exactement une partition. Les partitions sont entièrement gérées par l'API MemoryStores ; vous n'avez pas besoin de les gérer vous-même.

Attribution des partitions

Le stockage par partition est différent selon la structure de données sur laquelle un élément est stocké. Pour les cartes triées et les files d'attente, chaque structure de données est assignée à une seule partition.

Par exemple, considérons un jeu de carnaval avec une carte triée appelée PlayerScores et une file d'attente appelée PlayerLine de joueurs attendant de jouer au jeu :

Contrairement aux cartes triées et aux files d'attente, les tables de hachage se voient attribuer plusieurs partitions, et les données sont automatiquement réparties à travers ces partitions. Si vous deviez ajouter une table de hachage appelée Prizes, les partitions pourraient ressembler à ceci :

Notez comment la table de hachage existe sur toutes les partitions, et chaque partition a un sous-ensemble d'articles.

Limites

Avoir une limite par partition permet un débit plus élevé pour toutes les structures de données. Cela favorise également les tables de hachage, car elles sont réparties sur toutes les partitions.

Par exemple, considérons une limite par partition de 50 000 requêtes par minute (RPM) :

  • Dans le meilleur des cas, une carte triée et une file d'attente sont limitées à 50 000 RPM, car chacune réside sur une seule partition.
  • Les requêtes aux tables de hachage sont réparties sur les clés des éléments, qui sont elles-mêmes réparties sur les partitions, donc les tables de hachage peuvent avoir une limite effective beaucoup plus élevée avant le throttling, plusieurs fois celle des autres structures de données, en supposant que les requêtes soient réparties sur de nombreuses clés d'éléments.
  • Bien que les tables de hachage puissent atteindre un débit global plus élevé en répartissant les requêtes sur les partitions, les clés des éléments individuelles sont toujours limitées pour maintenir la stabilité du système. Si la plupart de votre trafic cible une seule clé d'élément, cette clé peut encore être throttled.
  • Pour évoluer efficacement et éviter ces limites par clé, implémentez un sharding de clés. Répartissez les lectures et les écritures de manière uniforme sur plusieurs clés d'éléments pour réduire les goulets d'étranglement et maintenir des performances fluides.

Pour cette raison, si vous n'avez pas besoin de tri ou de fonctionnalité "premier arrivé, premier servi", les tables de hachage sont généralement le meilleur choix pour une structure de données de magasin mémoire. Pour plus d'informations, voir les meilleures pratiques.

©2026 Société Roblox. Roblox, le logo Roblox et Powering Imagination font partie de nos marques déposées aux États-Unis et dans d'autres pays.