CODEWITHSUNDEEP
firebasegoogle-cloud-platformgoogle-cloud-firestore
Maksym Moros
Maksym Moros

Reputation: 529

Firebase: avoiding database contention: instead of transaction, using update on a unique field in single doc

Been creeping towards facing the issue of 60w/doc/sec in my app. Did all the collection and document separation strategies I could think of. My unavoidable bottleneck are 'votes' on users posts, held in one document per post.

Uptil now I've been using transactions to populate a votes map with unique user identifiers.

My question is: instead of using transactions to set the UserID votes map, can I just use:

db.[databasePath].update({'votes.${UserID}': true});

Vote map structure:

votes = {
  'user1': false,
  'user2': true,
  'user3': false,
  ...
}

If I don't care what others are doing to the document, and I'm using a unique key in the map, can I trust this method to complete the update? Or is there a possibility that with many update calls coming in that some votes could be lost?

Cheers!

Upvotes: 0

Views: 195

Answers (1)

Renaud Tarnec
Renaud Tarnec

Reputation: 83093

This will not bypass the limit of 1 write per second per document. Even if you are using different keys in your votes object, you are still writing to the same document.

One solution would be to write one document per voting user in a sub collection of the main document (i.e. the one representing the subject of the vote). This way you write to different docs and you are note constrained by the 1 write per second limit anymore.

If you need to have the total number of votes (in addition to the nbr of votes per user), you could use a Cloud Function which writes to a distributed counter within a transaction. This CF would be triggered for any creation of a voting doc. You will need to create a distributed counter per main document.

Similarly, if you need to know the total votes per user (across main documents), just update another set of distributed counters.

Upvotes: 1

Related Questions