question

lylecox avatar image
lylecox asked

Non-sharded title data or query of player data?

We have a list of playFabIDs with a couple associated values that only a single server needs to read/write. It can be writing on a semi frequent basis, but only needs to read on startup. The list is cleared every week.


Title Internal Data does not work because if the server saves data then restarts it is not guaranteed to get the latest data for 15 minutes. It also goes against the documentations recomendation against using title data as a global variable.

Player Data is a possibility but it does not make sense to store the server information there which has different data size requirements than the rest of the players. It would affect pricing negatively if the server's data is notably larger than is required for a player.

Shared Group Data has smaller data limits than Player Data.

Using AddPlayerTag then querying the players and the data using GetLeaderboard doesn't work because GetLeaderboard returns a maximum of 100 results.


Is it possible to query players with a given tag and also return a couple fields stored on that player? Or would we then have to query the player data on each returned player, which could be 10's of thousands of additional requests. Or is there a good place we can store this data?

Player DataTitle Datadata
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
brendan avatar image
brendan answered

While you could create a Segement of players with a given Tag, that's not something you could query via an API - you would use that for analytics data, querying it via Snowflake.

Could you please describe from a high level what the gameplay feature is that you're trying to implement? We provide a number of data systems, but determining what's going to be best depends upon the actual requirements, which aren't clear from this post. How large is this data? How often will it be read, worst case? How often will it be written, worst case? What triggers reading or writing the data?

2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

lylecox avatar image lylecox commented ·

We add players to a drawing with varying amounts of tickets based on their participation throughout a week. At the time of the drawing we need to be able to retrieve the players involved and how many tickets they have for the drawing as well as a few other pieces of identifying information for the players.

Worst case it will be read a few times in an hour. We could batch writes so they aren't as frequent, but even with that we would be looking at every few seconds.

Reading is triggered by the server loading the data initially. Which could be stopped and started up again right away.

Writing is triggered by players earning a ticket, which could happen in the hundreds at any time. So batching is likely necessary here.

We may need to eventually support a list of 1 million players. If the data was put into a list and stored as stringified json that would be ~32MB. This could be much smaller if stored in a real data structure. The minimum we would need is a PlayFabId or a way of identifying which PlayFabId, and an integer for each player.

0 Likes 0 ·
brendan avatar image brendan lylecox commented ·

So, we have several types of data systems, but none that would provide for what you're after. What you want is a system that can update a single data store as a result of actions by all players. A system that allows for arbitrary writes with high consistency such as you describe would be very expensive to operate. What I would recommend is either:

a) Use leaderboards. So, each player updates a statistic of their own with their data on usage, and you just use the leaderboard query to get the top N players.

b) Use an external data store, like Redis or similar, in order to aggregate the information across all players.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.