Help understanding Deno Deploy's KV usage limits and how to best optimize my DB
Hi, I was hoping to get some help understanding how to best optimize my game's Deno KV usage. I saw on the Deno Deploy's pricing page that database usage is metered in terms of KV read/write units per month. This would lead me to believe I should optimize for as few transactions as possible, but beside that it says (1KiB)/(4KiB). Is this referring to the max size of a single read / write? Or is this the max amount of information that can be transferred to / from the DB during that a month window, in which case I would also optimize for smaller transactions when possible.
One of the areas this comes up in my game that I think would be helpful for me to understand is the deck. In my game each player has a set of cards that are each completely unique and can be modified individually (adding effects to specific cards etc.). I see two possible solutions to storing this:
1. Store one massive object that represents a players deck, with all the data about each specific card nested within it. This allows the entire deck to be fetched and set as one object reducing the number of transactions. However to draw or modify a card in the deck the entire deck needs to be fetched.
2. Store the deck as a set of keys, and store each card individually with it's own key. This would result in much less data being transferred, as specific information about cards that are not used would not be loaded. However this would result in more transactions, as even just drawing a card would require at least one read to get the list of keys, and another to get the specific card.
My initial interpretation of the Deno KV pricing would lead me to believe it would be best to go with option one, but if there's a limit on the amount of data I can read / write per month option two would make more sense. Also option one just feels so wrong to me so I'm having trouble believing it's the more optimal solution. Also this game is turn based so latency does not really matter.
Thank you!
One of the areas this comes up in my game that I think would be helpful for me to understand is the deck. In my game each player has a set of cards that are each completely unique and can be modified individually (adding effects to specific cards etc.). I see two possible solutions to storing this:
1. Store one massive object that represents a players deck, with all the data about each specific card nested within it. This allows the entire deck to be fetched and set as one object reducing the number of transactions. However to draw or modify a card in the deck the entire deck needs to be fetched.
2. Store the deck as a set of keys, and store each card individually with it's own key. This would result in much less data being transferred, as specific information about cards that are not used would not be loaded. However this would result in more transactions, as even just drawing a card would require at least one read to get the list of keys, and another to get the specific card.
My initial interpretation of the Deno KV pricing would lead me to believe it would be best to go with option one, but if there's a limit on the amount of data I can read / write per month option two would make more sense. Also option one just feels so wrong to me so I'm having trouble believing it's the more optimal solution. Also this game is turn based so latency does not really matter.
Thank you!
