Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

mongodb: should i always use the 'safe' option on updates

when dealing with mongodb, when should i use the {safe: true} on queries?

Right now I use the 'safe' option just to check if my queries were inserted or updated successfully. However, I feel this might be over kill.

Should i assume that 99% of the time, my queries (assuming they are properly written) will be inserted/updated, not have to worry about checking if they successfully inputted?

thoughts?

like image 924
dez Avatar asked Feb 11 '11 22:02

dez


People also ask

How does updates work in MongoDB?

The update() method updates the values in the existing document in the collections of MongoDB. When you update your document the value of the _id field remains unchanged. By default, the db. collection.

Is MongoDB safe?

Secure From the Start With MongoDB Atlas, your data is protected with preconfigured security features for authentication, authorization, encryption, and more.

How do I use FindAndModify in MongoDB?

MongoDB – FindAndModify() Method. The findAndModify() method modifies and return a single document that matches the given criteria. By default, this method returns a pre-modification document. To return the document with the modifications made on the update, use the new option and set its value to true.

How can indexes speed up queries in MongoDB?

Performance. Because the index contains all fields required by the query, MongoDB can both match the query conditions and return the results using only the index. Querying only the index can be much faster than querying documents outside of the index.


2 Answers

Assuming when you say queries you actually mean writes/inserts (the wording of your question makes me think this) then the Write Concern (safe, none, fsync, etc) can be used to get more speed and less safety when that is acceptable, and less speed and more safety when that is necessary.

As an example, a hypothetical Facebook-style application could use an unsafe write for "Likes" while it would use a very safe write for password changes. The logic behind this is that there will be many thousand "Like"-style updates happening a second, and it doesn't matter if one is lost, whereas password updates happen less regularly but it is essential that they succeed.

Therefore, try to tailor your Write Concern choice to the kind of update you are doing, based upon your speed and data integrity requirements.

like image 56
Rich Avatar answered Nov 15 '22 20:11

Rich


Here is another use case where unsafe writes are an appropriate choice: You are making a large number of writes in very short order. In this case you might perform a number of writes, and then call get last error to see if any of them failed.

collection.setWriteConcern(WriteConcern.NORMAL)
collection.getDB().resetError()
List<
for (Something data : importData) {
    collection.insert(makeDBObject(data))
}
collection.getDB().getLastError(WriteConcern.REPLICAS_SAFE).throwOnError()

If this block succeeds without an exception, then all of the data was inserted successfully. If there was an exception, then one or more of the write operations failed, and you will need to retry them (or check for a unique index violation, etc). In real life, you might call getLastError every 10 writes or so, to avoid having to resubmit lots of requests.

This pattern is very nice for performance when performing bulk inserts of large amounts of data.

like image 31
Sean Reilly Avatar answered Nov 15 '22 22:11

Sean Reilly