Do document updates, where the update from a client, has no difference with the Firestore server copy still cost in terms of number of writes?
Also would a cloud function that is listening for updates also be invoked?
According to the Cloud Firestore Pricing documentation, each set() or update() operation will count as a write. In this case, you will still be charged with the cost of 1 write when called with new changes or not.
Document updates all incur billing for a write. But Cloud Functions and realtime listeners will not be invoked if data doesn't actually change in the document. The only situation where I suspect a listener might be invoked is if the client itself attempts to make an update to the same document it's listening to, but I'm not sure about that.
Related
If I had a function that reads the same document from Firestore multiple times does each read count towards the read count?
Or does the SDK use the cached version and so only add a single count?
I forgot to add. This is a question about the Admin SDK in a cloud function.
The key thing to realize is that you're charged for every document that is read for you on (and usually downloaded from) the server. So if a document is read from the cache, that usually won't count as a charged document read. But if the client needs to check with the server whether its local copy is up to date (the average document-level get() call), that does lead to a document read charge.
The Admin SDKs don't have a persistent cache, so in general each read would have to reach out to the server - and thus count as a charged document read. But some of it depends on how you actually perform the read operation, so it'll be easier to help if you can show an MCVE for that.
If I create multiple onSnapshot listeners for the same document in different places in my code, will I be charged once (one document) or multiple times (for each listener).
Does it make sense to write a wrapper around Firestore that does this or is this built-in?
As per documentation:
Cloud Firestore allows you to listen to the results of a query and get
realtime updates when the query results change.
When you listen to the results of a query, you are charged for a read
each time a document in the result set is added or updated. You are
also charged for a read when a document is removed from the result set
because the document has changed. (In contrast, when a document is
deleted, you are not charged for a read.)
Also, if the listener is disconnected for more than 30 minutes (for
example, if the user goes offline), you will be charged for reads as
if you had issued a brand-new query.
What you decide to do afterwards will heavily depend on your use case and your application needs.
I recently realized that even if a Firestore query doesn't match any document, I will still be charged for 1 read.
In my case, there could be lots of queries for non-existing docs, and I want to avoid this cost.
In my case, the client already has (or can generate locally) the relevant document Id beforehand, but the client still doesn't know if this document exists or not.
So instead of querying and receiving the doc, I can do get(docId)
Question: Does the Firestore charge for replying error to a get() request of the non-existing document?
A get() call for a document that requires the server to read data is charged as a document read. Since the server needs to check whether the document exists, that is a charged read operation (as far as i know).
The documentation on Firestore pricing says:
Minimum charge for queries
There is a minimum charge of one document read for each query that you
perform, even if the query returns no results.
So it sounds like you will be charged. The important thing to realize is that the indexes the Firestore uses to manage your documents do take time and space to maintain, so if you make use of an index, it's reasonable to expect that it's going cost money because of resources consumed.
I am using swift and Firestore and in my application I have a snapshotlistener which retrieves data every time some documents are changed. As I expect this to happen many times a second, I would like to limit the snapshotlistener to retrieve data once every 2 seconds, say. Is this possible? I looked everywhere but could not find anything.
Cloud Firestore stores your data in multiple data centers, and only confirms the write operations once it's written to all of those. For this reason the maximum update frequency of a single document in Cloud Firestore is roughly once per second. So if your plan is to update a document many times per second, that won't work anyway.
There is no way to set a limit on how frequently Firestore broadcasts out updates to the underlying data. If the data gets updated, it is broadcast out to all active listeners.
The typical solution would be to limit how frequently you update the data. If nobody is going to see a significant chunk of the updates, you might as well not write them to the database. This sort of logic if often accomplished with a client side throttle/debounce (see 1, 2).
So I receive on my node server 80,000+ records at a time that need to be put into Mongo as updates. I am aware that mongoose doesn't support this functionality, so each one has be be updated individually.
When I do this however, even when a connection pool is set up to be say 100, it still overwhelms the connection pool and the result is that any other web or system traffic needing to do a database call cannot complete. Is there any way to have a model limit the amount of connection it uses, or any other good way to work around this? For now we are resource limited to having only a single db or node instance to handle front and back end items.
Any comments or suggestions to try welcome.
Thanks
You can perform bulk updates with Mongoose, using Model.bulkWrite().
The documentation doesn't specify how many documents you can update per batch, but the MongoDB documentation documenting the underlying mechanism seems to suggest that you might be able to send all 80K updates at once.