为何MongoDB采用12字节字符串及UUID作为唯一标识而非增量值

Great question! Let's break this down clearly, since both choices tie directly to MongoDB's core design for distributed, scalable systems.

Why MongoDB's 12-byte ObjectId Beats Auto-Incrementing Values #

MongoDB's default unique identifier is the 12-byte ObjectId (often represented as a 24-character hex string). Here's why it's far better than auto-incrementing integers:

• Distributed Architecture Friendly: Auto-increment values require a centralized generator (like a dedicated counter collection with findAndModify locks). In a sharded MongoDB cluster, this becomes a single point of failure and a performance bottleneck—every node has to wait for the generator to issue the next ID. ObjectIds are generated locally by each node, no coordination needed, which fits perfectly with MongoDB's distributed nature.
• Built-in Timestamp: The first 4 bytes of an ObjectId are a Unix timestamp. This means you don't need a separate created_at field—you can extract the creation time directly from the ID using code like ObjectId("60d21b4667d0d8992e610c85").getTimestamp(). It saves storage and makes sorting by creation time trivial (ObjectIds are roughly time-ordered).
• No Predictability Risks: Auto-increment IDs are easy to guess, which can expose your data to scraping or enumeration attacks (e.g., someone could iterate /api/users/1, /api/users/2, etc.). ObjectIds include a random component (machine ID, process ID, and incrementing counter), making them nearly impossible to predict.
• Reduces Sharding Hotspots: If you use an auto-increment value as your shard key, all new writes will flood a single "hot" shard, since IDs keep increasing. ObjectIds, while time-ordered, include a machine ID—so writes from different nodes can spread across multiple shards, balancing load better.
• No Concurrency Bottlenecks: Generating auto-increment IDs requires locking the counter to avoid duplicates, which slows down writes under high concurrency. ObjectIds are generated locally, so no locks or waits are needed.

Why UUIDs Are a Solid Alternative to Auto-Increment Values #

While MongoDB defaults to ObjectId, it fully supports UUIDs as unique identifiers. Here's why teams might choose UUIDs over auto-increment values (and sometimes even over ObjectIds):

• True Cross-System Uniqueness: UUIDs are designed to be globally unique across any system, not just your MongoDB cluster. If you're integrating multiple services (e.g., a PostgreSQL database and a MongoDB collection), UUIDs ensure IDs won't collide between systems—something auto-increment values can't guarantee.
• Flexible Generation Options: UUIDs come in multiple versions:
  • Version 1 includes a timestamp and MAC address (similar to ObjectId, but with a larger footprint)
  • Version 4 is fully random, ideal for scenarios where you don't want any time-based pattern in IDs
    You can pick the version that fits your security or ordering needs.
• Even Better Sharding Distribution: A random UUID (v4) as a shard key will spread writes evenly across all shards, completely eliminating the hotspot issue that plagues auto-increment keys. The tradeoff is slightly more index fragmentation, but it's worth it for highly distributed workloads.
• Language/System Compatibility: Most programming languages and databases have built-in support for UUIDs. If you're migrating data or building a polyglot system, using UUIDs avoids the need to handle MongoDB-specific ObjectId formatting.

Why Auto-Increment Values Are a Bad Fit for MongoDB #

To wrap up, auto-increment values clash with MongoDB's core strengths:

• They create single points of failure in distributed setups
• They introduce concurrency bottlenecks under high load
• They expose security risks via predictable IDs
• They cause sharding hotspots that hurt scalability

Whether you use ObjectId or UUID, both are designed to solve these problems while aligning with MongoDB's scalable, distributed architecture.

内容的提问来源于stack exchange，提问作者Prem