ChatGPT解决这个技术问题 Extra ChatGPT

Mongoose indexing in production code

Per the Mongoose documentation for MongooseJS and MongoDB/Node.js :

When your application starts up, Mongoose automatically calls ensureIndex for each defined index in your schema. While nice for development, it is recommended this behavior be disabled in production since index creation can cause a significant performance impact. Disable the behavior by setting the autoIndex option of your schema to false.

This appears to instruct removal of auto-indexing from mongoose prior to deploying to optimize Mongoose from instructing Mongo to go and churn through all indexes on application startup, which seems to make sense.

What is the proper way to handle indexing in production code? Maybe an external script should generate indexes? Or maybe ensureIndex is unnecessary if a single application is the sole reader/writer to a collection because it will continue an index every time a DB write occurs?

Edit: To supplement, MongoDB provides good documentation for the how to do indexing, but not why or when explicit indexing directives should be done. It seems to me that indexes should be kept up to date by writer applications automatically on collections with existing indexes and that ensureIndex is really more of a one-time thing (done when a new index is being applied), in which case Mongoose's autoIndex should be a no-op under a normal server restart.

It is always good to do indexing with a separate script that does not get executed on every deployment. It is more from a maintenance point of view. Otherwise, some developers will someday add some index for a collection that already has millions of records and then it might incur a major business loss.

J
JohnnyHK

I've never understood why the Mongoose documentation so broadly recommends disabling autoIndex in production. Once the index has been added, subsequent ensureIndex calls will simply see that the index already exists and then return. So it only has an effect on performance when you're first creating the index, and at that time the collections are often empty so creating an index would be quick anyway.

My suggestion is to leave autoIndex enabled unless you have a specific situation where it's giving you trouble; like if you want to add a new index to an existing collection that has millions of docs and you want more control over when it's created.


I have a question to add...What if I set it false? Than will the indexes be created when i insert the data or do I need to explicitly create it. I am sorry if this is a novice question but it would be really helpful if you answered.
@SaranshMohapatra When autoIndex is false, you need to call ensureIndexes on your model to create its indexes.
Than will I have to call it every time or just once defining the model?
@SaranshMohapatra when you define (compile) your model. I do that when I first start the app. Now the hard think is to decide to drop all indexes and recreate them, in case you schema changes.
@JohnnyHK do you still agree with your answer now that it's almost 2016?
C
Community

Although I agree with the accepted answer, its worth noting that according to the MongoDB manual, this isn't the recommended way of adding indexes on a production server:

If your application includes ensureIndex() operations, and an index doesn’t exist for other operational concerns, building the index can have a severe impact on the performance of the database. To avoid performance issues, make sure that your application checks for the indexes at start up using the getIndexes() method or the equivalent method for your driver and terminates if the proper indexes do not exist. Always build indexes in production instances using separate application code, during designated maintenance windows.

Of course, it really depends on how your application is structured and deployed. If you are deploying to Heroku, for example, and you aren't using Heroku's preboot feature, then it is likely your application is not serving requests at all during startup, and so it's probably safe to create an index at that time.

In addition to this, from the accepted answer:

So it only has an effect on performance when you're first creating the index, and at that time the collections are often empty so creating an index would be quick anyway.

If you've managed to get your data model and queries nailed on first time around, this is fine, and often the case. However, if you are adding new functionality to your app, with a new DB query on a property without an index, you'll often find yourself adding an index to a collection containing many existing documents.

This is the time when you need to be careful about adding indexes, and carefully consider the performance implications of doing so. For example, you could create the index in the background:

db.ensureIndex({ name: 1 }, { background: true });

Ok, so all you have to do is NOT start your server until all the ensureIndex callbacks have fired for each collection.
@AlexMills how do you ensure that?
async.each(Object.keys(models), function (key, cb) { models[key].ensureIndexes(cb) }, cb)
There is no ensureIndex anymore. There is createIndex instead. Am I right?
background is now deprecated. Mongodb will ignore it from 4.2. Mongodb will now do the index building using a specialized build which is asynchronously except during the start and end of the build process as specified in the docs docs.mongodb.com/manual/reference/method/…
M
Masih Jahangiri

use this block code to handle production mode:

const autoIndex = process.env.NODE_ENV !== 'production';
mongoose.connect('mongodb://localhost/collection', { autoIndex });

Wrong answer. If you do so, your production server will never have any indexes!

关注公众号,不定期副业成功案例分享
Follow WeChat

Success story sharing

Want to stay one step ahead of the latest teleworks?

Subscribe Now