Custom _id for new user profile documents


I went through the topics here and did some research and I am aware of the fact that specifying an custom _id when indexing new document can slow down the performance. But I could not find how drastically it would behave in following case:

  1. In a mobile app, user will create and account that generated Profile document in the MongoDB database and this is also directly being indexed in elastic search
  2. on each update on his profile the document in ElasticSearch gets re-indexed

Now my two questions would be:

  1. as the document in the ElasticSearch is created only once the user sign-up, can I safely use a 10 character String generated in the app server as a custom _id?** I believe the frequency of creating new profiles would be slow enough even the user base would grow into millions.

  2. I found in other discussions that client.index({ }) and client.index({ }) for any following changes in that above created document would not make any performance difference. Is that correct? Update could safe some traffic if I would not have offline-first mobile app and would have to first fetch current state from database before saving new values.

Assuming the two questions are also a correct answers I should be fine with using strings like QDbCIeqVWt, dNHXPlSY1U, eqspyeRmUw for the custom _id field.

Or do I miss anything that could break in future while scaling everything up (sharding, ...)?

Thanks for inputs!

Everything should be fine.

I'd recommend using the same _id for elasticsearch as the one you are using in MongoDB.

1 Like

Thank you for confirmation, David! This simplifies the black-end logic noticeably, but I was not sure if I would build up some time bomb.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.