// ==========================================
// Case A: Evaluating the Cardinality of the customer_id field
// ==========================================
// Note: Executing this command on a large table triggers a full table scan. Verify it in a test environment and exercise caution when operating in the production environment.
db.t_orders.aggregate([
    { $group: { _id: "$customer_id" } },
    { $count: "cardinality" }
], { allowDiskUse: true }) // It is recommended to add allowDiskUse to prevent out-of-memory errors.

// Execution result: { "cardinality": 2500000 } 
// Conclusion evaluation: A high-cardinality field, which exhibits excellent data dispersion, is suitable as a shard key.


// ==========================================
// Case B: Evaluating the Cardinality of the status field
// ==========================================
// Note: Executing this command on a large table triggers a full table scan. Verify it in a test environment and exercise caution when operating in the production environment.
db.t_orders.aggregate([
    { $group: { _id: "$status" } },
    { $count: "cardinality" }
])

// Execution result: { "cardinality": 6 } 
// Conclusion evaluation: A field with extremely low Cardinality is highly likely to cause Jumbo Chunks and data skew. It is prohibited from being used alone as a shard key!

Timeline ─────────────────────────────────────────────────────►

        Chunk 1        Chunk 2        Chunk 3        Chunk 4
      [2024-01-01]   [2024-02-01]   [2024-03-01]   [2024-04-01]
         ↑              ↑              ↑              ↑
        Cold Data         Cold Data         Cold Data     ←── All writes are concentrated here (hotspot)

// Poor Design: Using range sharding on incrementing keys inevitably leads to write hotspots on a single node. 
sh.shardCollection("mydb.t_orders", { _id: 1 }) 
sh.shardCollection("mydb.t_orders", { createTime: 1 })  

// Standard Practice: For scenarios with frequent point queries, use Hash sharding to forcibly scatter data. 
sh.shardCollection("mydb.t_orders", { _id: "hashed" })  

// Standard Practice: For scenarios with frequent range queries, use Hash sharding to achieve load balancing. 
sh.shardCollection("mydb.t_orders", { orderNo: "hashed" })

 // Shard key: { user_id: 1 }
 
 // Targeted Query: When the condition includes the shard key, the query is routed directly to the target shard.
 db.t_messages.find({ user_id: "U001", create_time: { $gt: ISODate("2024-01-01") } })
 
 // Broadcast Query: When the condition does not include the shard key, the query is broadcast to all shards.
 db.t_messages.find({ create_time: { $gt: ISODate("2024-01-01") } })

// Pattern 1: Prefix for targeting + Suffix for scattering
// Applicable when: Queries are always filtered by a certain field, but that field does not have sufficiently high cardinality.
sh.shardCollection("db.t_orders", { customer_id: 1, order_id: "hashed" })

// Pattern 2: Time range + Random scattering
// Applicable when: Time range queries are required, but writes need to be evenly distributed.
sh.shardCollection("db.t_logs", { month: 1,  order_id: "hashed" })
// The month field uses the "2024-01" format, with one range per month. Data is hashed and scattered within each month.

                    ┌─────────────┐
                    │ Application │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │   mongos    │  ◄── Access must go through mongos.
                    └──────┬──────┘
           ┌───────────────┼───────────────┐
           │               │               │
    ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
    │   Shard 1   │ │   Shard 2   │ │   Shard 3   │
    │  (Replica Set)   │ │  (Replica Set)   │ │  (Replica Set)   │
    └─────────────┘ └─────────────┘ └─────────────┘
          ↑               ↑               ↑
          └───────────────┴───────────────┘
                   ❌ Do not connect directly.

 # Correct: Connect through mongos.
 mongodb://mongouser:password@10.0.0.1:27017,10.0.0.2:27017/admin
 
 # Error: Direct connection to shard nodes.
 mongodb://mongouser:password@shard1-node1:27018/admin

 # Correct: The connection string contains all mongos addresses.
 uri = "mongodb://user:pass@mongos1:27017,mongos2:27017,mongos3:27017/admin"
 
 # Error: Only a single mongos is configured.
 uri = "mongodb://user:pass@mongos1:27017/admin"

 // Set the Balancer running time window (2:00 AM - 6:00 AM)
 use config
 db.settings.updateOne(
     { _id: "balancer" },
     {
         $set: {
             activeWindow: {
                 start: "02:00",
                 stop: "06:00"
             }
         }
     },
     { upsert: true }
 )
 
 
 // Temporarily stop the Balancer during major promotions
 sh.stopBalancer()
 
 // Verify that the Balancer is stopped.
 sh.isBalancerRunning()  // This should return false.
 
 // Start the Balancer after the major promotion ends.
 sh.startBalancer()

  
// Disable the Balancer for a specific collection (other collections are not affected)
sh.disableBalancing("mydb.t_orders")

// Enable the Balancer for a specific collection
sh.enableBalancing("mydb.t_orders")

// Check whether the Balancer is enabled for a specific collection
db.getSiblingDB("config").collections.findOne({_id: "mydb.t_orders"}).noBalance
// A return value of true indicates that it is disabled, while a return value of false or no return value indicates that it is enabled.


 // Find all Jumbo Chunks
 use config
 db.chunks.find({ jumbo: true }).forEach(function(chunk) {
     print("Jumbo Chunk: " + chunk.ns + " [" +
           tojson(chunk.min) + " -> " + tojson(chunk.max) + "]")
 })
 
 // Count the number of chunks per shard (to check whether the distribution is balanced)
 db.chunks.aggregate([
     { $match: { ns: "mydb.mycollection" } },
     { $group: { _id: "$shard", count: { $sum: 1 } } },
     { $sort: { count: -1 } }
 ])

 // Shard key: { user_id: 1 }
 
 // Error: The shard key is not included in the unique index.
 db.t_users.createIndex({ email: 1 }, { unique: true })
 // Error: can't shard collection with unique index on { email: 1 }
 
 // Correct: The unique index includes the shard key.
 db.t_users.createIndex({ user_id: 1, email: 1 }, { unique: true })
 
 // Correct: The _id index is inherently unique (within each shard).
 // Note: The _id of a sharded collection is unique only within a shard and may be duplicated across shards.

 // Hashed sharding pre-split: Specify the number of chunks to pre-create.
 sh.shardCollection(
     "mydb.t_orders",
     { order_id: "hashed" },
     false,  // unique
     { numInitialChunks: 64 }  // Pre-create 64 chunks.
 )
 // Chunks are automatically and evenly distributed across shards.
 
 // Range sharding pre-split: Manually define Chunk boundaries.
 sh.shardCollection("mydb.t_logs", { month: 1, _id: 1 })
 
 // Manually define Chunk boundaries.
 sh.splitAt("mydb.t_logs", { month: "2024-01", _id: MinKey })
 sh.splitAt("mydb.t_logs", { month: "2024-02", _id: MinKey })
 sh.splitAt("mydb.t_logs", { month: "2024-03", _id: MinKey })
 
 // Manually migrate chunks to a specified shard (optional, as the Balancer also performs automatic balancing).
 sh.moveChunk("mydb.t_logs", { month: "2024-01", _id: MinKey }, "shard1")
 sh.moveChunk("mydb.t_logs", { month: "2024-02", _id: MinKey }, "shard2")

sh.stopBalancer()
// Verify whether the status has been successfully disabled.
sh.getBalancerState() // This is expected to return false.

sh.startBalancer()