February 27, 2010 at 20:02Performance upsert in MongoDB
In nosql-based MongoDB is an analogue mysql'nogo the INSERT ... the DUPLICATE the ON the KEY the UPDATE - upsert'y (UPdate or inSERT).
How fast does mongodb do?
The question is not idle, since with upsert'ah two operations are performed - reading and writing. The presence of indexes speeds up reading, but slows down writing. Which of them accelerates harder, and which slower steeper?
I considered the case when there is an array in the document and the active record goes there. Example - blog comments:
Each comment is an object of type:
The graph shows the performance of the operation (the last parameter enables the upsert mode) depending on the size of the array and the presence of an index on .
The same case, but the post title is always randomly generated. The point is frequent posting of new articles through upsert.
It can be seen that with a small number of records (small base), an index is not needed. But with the growth of the database and the increase in the number of extents, the index starts to help a lot and gives a stable recording speed.
My verdict for upsert is as follows: you can use it when you can’t say exactly what more - change documents or add new ones, or their ratio is about 50/50. In my environment, a “head-on” record goes at a speed of 10K documents per second.
To experimenters: pay attention to the size of the document, how many extents it takes (nscanned). With an increase in the number of extents, there will be a picture as in the first graph, but it will be more abrupt to degrade.
How fast does mongodb do?
The question is not idle, since with upsert'ah two operations are performed - reading and writing. The presence of indexes speeds up reading, but slows down writing. Which of them accelerates harder, and which slower steeper?
upd: добавлен еще один графикFocus on UPdate
results
Comments
I considered the case when there is an array in the document and the active record goes there. Example - blog comments:
db.blog.insert ({
title: "new post",
content: "Hello world!
",
comments: []
});
Each comment is an object of type:
NEW_COMMENT = {
content: "Thanks! Great article! Peshi is4o!",
author: "vasily@example.com"
}
The graph shows the performance of the operation (the last parameter enables the upsert mode) depending on the size of the array and the presence of an index on .
db.blog.update({title: "new post"}, {"$push": {comments: NEW_COMMENT}}, true)blog.commentsblog.titleFocus on inSERT
results
Comments
The same case, but the post title is always randomly generated. The point is frequent posting of new articles through upsert.
It can be seen that with a small number of records (small base), an index is not needed. But with the growth of the database and the increase in the number of extents, the index starts to help a lot and gives a stable recording speed.
Summary
My verdict for upsert is as follows: you can use it when you can’t say exactly what more - change documents or add new ones, or their ratio is about 50/50. In my environment, a “head-on” record goes at a speed of 10K documents per second.
To experimenters: pay attention to the size of the document, how many extents it takes (nscanned). With an increase in the number of extents, there will be a picture as in the first graph, but it will be more abrupt to degrade.