以前学过sql，现在在学mongodb。看到objectID各种想把它改成和sql一样从1开始auto increment的id，我就全给update了。听说并不能这样做，还是要保留mongo原有的自动生成的obectID， 但是为什么？
原理を分析することで答えを得るのは実は簡単です。次のように、1 から 100 までの数字の束が手の中にあるとします。
男が来て番号を尋ねてきたら、番号を渡しても問題ありません。
2人が一緒に到着しましたが、2人ともあなたに番号を尋ねました。どうすればよいですか?ゆっくり一つずつ来て、次々に送り出して、ゆっくりでも十分です
同時に10人が来て番号を聞いたらどうしますか？100人だったらどうしますか？
同時リクエストとして来る人の数を想像してみてください。すぐに番号を割り当てることがボトルネックになることは難しくありません。したがって、ID が自己増加することは、RDBMS にとって実際には良いことではありません。しかし幸いなことに、従来のデータベースはスタンドアロンであり、データベース自体にロックを追加してメモリ内の競合を処理するだけであり、これは大きな問題ではありません。 MongoDB は分散データベースです。あなたは 1、私は 2、彼は 3 を相互に調整する必要があります。このロックはネットワークを通じて調整する必要があり、非常に非効率です。 分散の目的を考えてみましょう。その 1 つは同時実行性を向上させることです。そのため、分散環境では、ID の自動インクリメントと高い同時実行性は、必然的に効率に影響を及ぼします。しかも、自己増加IDは見た目が綺麗になる以外にあまりメリットがないので、やむなく断念しました。 (ObjectID は実際には、つまり挿入時間の順序で並べ替えることができることに注意してください)
https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field/#considerations
通常、MongoDB では、_id フィールドやその他のフィールドに自動インクリメント パターンを使用しません。これは、多数のドキュメントを含むデータベースに対応できないためです。通常、_id にはデフォルト値の ObjectId がより理想的です。
文档上の自己说、大量のドキュメントを含むデータベースには対応していません、大量のドキュメントを含むデータベースには対応していません
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
原理を分析することで答えを得るのは実は簡単です。次のように、1 から 100 までの数字の束が手の中にあるとします。
男が来て番号を尋ねてきたら、番号を渡しても問題ありません。
2人が一緒に到着しましたが、2人ともあなたに番号を尋ねました。どうすればよいですか?ゆっくり一つずつ来て、次々に送り出して、ゆっくりでも十分です
同時に10人が来て番号を聞いたらどうしますか？100人だったらどうしますか？
同時リクエストとして来る人の数を想像してみてください。すぐに番号を割り当てることがボトルネックになることは難しくありません。したがって、ID が自己増加することは、RDBMS にとって実際には良いことではありません。しかし幸いなことに、従来のデータベースはスタンドアロンであり、データベース自体にロックを追加してメモリ内の競合を処理するだけであり、これは大きな問題ではありません。 MongoDB は分散データベースです。あなたは 1、私は 2、彼は 3 を相互に調整する必要があります。このロックはネットワークを通じて調整する必要があり、非常に非効率です。
分散の目的を考えてみましょう。その 1 つは同時実行性を向上させることです。そのため、分散環境では、ID の自動インクリメントと高い同時実行性は、必然的に効率に影響を及ぼします。しかも、自己増加IDは見た目が綺麗になる以外にあまりメリットがないので、やむなく断念しました。 (ObjectID は実際には、つまり挿入時間の順序で並べ替えることができることに注意してください)
https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field/#considerations
文档上の自己说、大量のドキュメントを含むデータベースには対応していません、大量のドキュメントを含むデータベースには対応していません