0

I'm building an app that will have to accept a surge of records in short bursts, like 100 000 in 5 minutes once every 24h. I've chosen Firestore in Datastore Mode as DB. I've figured how to make keys lexically different so the key space is wide and I won't bottle neck on that. I can prefeed the appropriate kind with dummy entities to ensure it can accept high insert traffic on the first day. The only remaining problem I have is that all records from a single surge need to have a property, say event_id, and it's gonna have the same value across all of them. I need to filter by that property later on (only equality filter), so it has to be indexed.

My concern is that this will cause hotspots in the index, but I'm not 100% sure. The docs mostly mention monotonically increasing values or narrow ranges to be a problem, not single values. Strictly speaking, however, mine is a case of a severely narrow range.

I was thinking of using a hierarchical structure, like Event/event-id/Records/my_entities_go_here, but I'm not sure if creating a new Event and submitting entities to (an initially empty) Event/event-id/Records isn't the same as writing to an empty Kind, which is slow in the begging.

Does anyone know a way around this?

RJC
  • 920
  • 11
mpnowacki
  • 33
  • 5
  • 1
    Maybe these answers ([1](https://stackoverflow.com/questions/68909801/firestore-short-numeric-ids) and [2](https://stackoverflow.com/questions/57324307/is-it-ok-to-add-timestamp-as-a-document-field-in-firestore-database)) will help, right? – Alex Mamo May 22 '22 at 09:00

0 Answers0