Operational considerations for Firestore Writer
This topic summarizes runtime considerations for Firestore Writer, including recovery behavior, performance, and known limitations.
Recovery
Firestore Writer supports recovery in two modes:
At-least-once processing (A1P): the default behavior when the Checkpoint Collection property is not specified. After recovery, the target may contain some duplicate events, but none will be missing.
Exactly-once processing (E1P): when the Checkpoint Collection property is specified, Striim stores the target checkpoint in the specified collection and guarantees that after recovery there will be no duplicate or missing events.
Performance
Parallel threads: target parallelism is available for initial load only.
Batch policy: tune the Batch Policy event count and interval to balance latency against the number of write requests sent to Firestore.
Overload handling: Firestore returns an Aborted (112) error when the database is overloaded or an operation conflicts with another. Firestore Writer retries these errors according to the Overload Retry Policy property; if you see frequent Aborted errors, increase the retry interval or reduce the write rate.
Limitations
Firestore Writer writes only to Firestore Enterprise edition databases with MongoDB compatibility. All limitations described in Behavior differences in Google's Firestore documentation apply.
Firestore Writer writes to a single database. Unlike MongoDB, each Firestore resource is created with a single database, so an application cannot write to multiple databases through one Firestore Writer target.
Firestore Writer does not create collections automatically. Create the target collections in Firestore before starting the application.
Specifying NO_OP_EXCEPTION as an Ignorable Exception Code has no effect for no-op deletes (deletes of documents that do not exist), because Firestore acknowledges no-op deletes rather than raising an exception.