MongoDB Sharding: คำแนะนำเชิงปฏิบัติทีละขั้นตอน

การแบ่งกลุ่มเป็นกระบวนการของการแบ่งชุดข้อมูลขนาดใหญ่ออกเป็นชุดข้อมูลขนาดเล็กกว่าในหลายอินสแตนซ์ MongoDB ในสภาพแวดล้อมแบบกระจาย

Sharding คืออะไร?

การแบ่งกลุ่มย่อย MongoDB มอบโซลูชันที่ปรับขนาดได้เพื่อจัดเก็บข้อมูลจำนวนมากระหว่างเซิร์ฟเวอร์จำนวนมาก แทนที่จะเก็บไว้ในเซิร์ฟเวอร์เดียว

ในทางปฏิบัติ เป็นไปไม่ได้ที่จะจัดเก็บข้อมูลที่เพิ่มขึ้นแบบทวีคูณในเครื่องเดียว การสืบค้นข้อมูลจำนวนมากที่จัดเก็บไว้ในเซิร์ฟเวอร์เครื่องเดียวอาจนำไปสู่การใช้ทรัพยากรสูง และอาจไม่ได้ให้อัตราการอ่านและเขียนที่น่าพอใจ

โดยทั่วไป มีวิธีการปรับสเกลสองประเภทที่มีอยู่เพื่อดำเนินการกับข้อมูลที่เพิ่มขึ้นกับระบบ:

Vertical Scaling ทำงานร่วมกับการเพิ่มประสิทธิภาพเซิร์ฟเวอร์เดี่ยวโดยการเพิ่มโปรเซสเซอร์ที่มีประสิทธิภาพมากขึ้น อัพเกรด RAM หรือเพิ่มพื้นที่ดิสก์ให้กับระบบ แต่มีนัยที่เป็นไปได้ของการใช้มาตราส่วนแนวตั้งในกรณีการใช้งานจริงกับเทคโนโลยีและการกำหนดค่าฮาร์ดแวร์ที่มีอยู่

Horizontal Scaling ทำงานร่วมกับการเพิ่มเซิร์ฟเวอร์และกระจายโหลดบนเซิร์ฟเวอร์หลายเครื่อง เนื่องจากแต่ละเครื่องจะจัดการชุดย่อยของชุดข้อมูลทั้งหมด จึงให้โซลูชันที่มีประสิทธิภาพและคุ้มค่ามากกว่าการปรับใช้ฮาร์ดแวร์ระดับไฮเอนด์ แต่ต้องการการบำรุงรักษาเพิ่มเติมสำหรับโครงสร้างพื้นฐานที่ซับซ้อนด้วยเซิร์ฟเวอร์จำนวนมาก

การแบ่งกลุ่มย่อย Mongo DB ทำงานกับเทคนิคการปรับขนาดแนวนอน

ส่วนประกอบการแบ่งส่วน

เพื่อให้เกิดการแบ่งกลุ่มย่อยใน MongoDB จำเป็นต้องมีองค์ประกอบต่อไปนี้:

Shard เป็นอินสแตนซ์ Mongo เพื่อจัดการชุดย่อยของข้อมูลดั้งเดิม ต้องใช้ชาร์ดในชุดเรพพลิกา

Mongos เป็นอินสแตนซ์ Mongo และทำหน้าที่เป็นส่วนต่อประสานระหว่างแอปพลิเคชันไคลเอนต์และคลัสเตอร์ที่แยกส่วน มันทำงานเป็นเราเตอร์แบบสอบถามไปยังชาร์ด

Config Server เป็นอินสแตนซ์ Mongo ที่เก็บข้อมูลเมตาดาต้าและรายละเอียดการกำหนดค่าของคลัสเตอร์ MongoDB ต้องการให้เซิร์ฟเวอร์กำหนดค่าปรับใช้เป็นชุดแบบจำลอง

การแบ่งสถาปัตยกรรม

คลัสเตอร์ MongoDB ประกอบด้วยชุดแบบจำลองจำนวนหนึ่ง

ชุดแบบจำลองแต่ละชุดประกอบด้วยอินสแตนซ์ Mongo อย่างน้อย 3 รายการขึ้นไป คลัสเตอร์ชาร์ดอาจประกอบด้วยอินสแตนซ์ชาร์ด mongo หลายอินสแตนซ์ และอินสแตนซ์ชาร์ดแต่ละรายการจะทำงานภายในชุดแบบจำลองชาร์ด แอปพลิเคชันโต้ตอบกับ Mongos ซึ่งจะสื่อสารกับชาร์ด ดังนั้นใน Sharding แอปพลิเคชันจะไม่โต้ตอบโดยตรงกับโหนดชาร์ด เราเตอร์แบบสอบถามกระจายชุดย่อยของข้อมูลระหว่างโหนดชาร์ดตามคีย์ชาร์ด

การใช้งานชาร์ด

ทำตามขั้นตอนด้านล่างสำหรับการชาร์ด

ขั้นตอนที่ 1

  • เริ่มเซิร์ฟเวอร์การกำหนดค่าในชุดเรพพลิกาและเปิดใช้งานการจำลองแบบระหว่างกัน

mongod –configsvr –port 27019 –replSet rs0 –dbpath C:datadata1 –bind_ip localhost

mongod –configsvr –port 27018 –replSet rs0 –dbpath C:datadata2 –bind_ip localhost

mongod –configsvr –port 27017 –replSet rs0 –dbpath C:datadata3 –bind_ip localhost

ขั้นตอนที่ 2

  • เริ่มต้นการตั้งค่าเรพพลิกาบนหนึ่งในเซิร์ฟเวอร์การกำหนดค่า

rs.initiate ( { _id : “rs0”, configsvr: true, สมาชิก: [   { _id: 0, host: “IP:27017” },   { _id: 1, host: “IP:27018” },   { _id: 2, host: “IP:27019” }    ] })

rs.initiate( { _id : "rs0",  configsvr: true,  members: [   { _id: 0, host: "IP:27017" },   { _id: 1, host: "IP:27018" },   { _id: 2, host: "IP:27019" }    ] })
{
        "ok" : 1,
        "$gleStats" : {
                "lastOpTime" : Timestamp(1593569257, 1),
                "electionId" : ObjectId("000000000000000000000000")
        },
        "lastCommittedOpTime" : Timestamp(0, 0),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593569257, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1593569257, 1)
}

ขั้นตอนที่ 3

  • เริ่มการชาร์ดเซิร์ฟเวอร์ในชุดเรพพลิกาและเปิดใช้งานการจำลองแบบระหว่างกัน

mongod –shardsvr –port 27020 –replSet rs1 –dbpath C:datadata4 –bind_ip localhost

mongod –shardsvr –port 27021 –replSet rs1 –dbpath C:datadata5 –bind_ip localhost

mongod –shardsvr –port 27022 –replSet rs1 –dbpath C:datadata6 –bind_ip localhost

MongoDB เริ่มต้นเซิร์ฟเวอร์การแบ่งส่วนข้อมูลแรกเป็นเซิร์ฟเวอร์หลัก เพื่อย้ายเซิร์ฟเวอร์การแบ่งส่วนข้อมูลหลักใช้ ย้ายหลัก กระบวนการ.

ขั้นตอนที่ 4

  • เริ่มต้นการตั้งค่าเรพลิกาบนหนึ่งในเซิร์ฟเวอร์ที่มีการแบ่งส่วนข้อมูล

rs.initiate ( { _id : “rs0” สมาชิก: [   { _id: 0, host: “IP:27020” },   { _id: 1, host: “IP:27021” },   { _id: 2, host: “IP:27022” }    ] })

rs.initiate( { _id : "rs0",  members: [   { _id: 0, host: "IP:27020" },   { _id: 1, host: "IP:27021" },   { _id: 2, host: "IP:27022" }    ] })
{
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593569748, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1593569748, 1)
}

ขั้นตอนที่ 5

  • เริ่มต้นมะม่วงสำหรับกระจุกฝอย
  วิธีส่งบันทึกถึงตัวคุณเองใน Slack

mongos –พอร์ต 40000 –configdb rs0/localhost:27019,localhost:27018, localhost:27017

ขั้นตอนที่ 6

  • เชื่อมต่อเซิร์ฟเวอร์เส้นทาง mongo

มองโก – พอร์ต 40000

  • ตอนนี้ เพิ่มเซิร์ฟเวอร์การแบ่งส่วนข้อมูล

sh.addShard( “rs1/localhost:27020,localhost:27021,localhost:27022”)

sh.addShard( "rs1/localhost:27020,localhost:27021,localhost:27022")
{
        "shardAdded" : "rs1",
        "ok" : 1,
        "operationTime" : Timestamp(1593570212, 2),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593570212, 2),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

ขั้นตอนที่ 7

  • บน mongo shell เปิดใช้งานการแบ่งส่วนข้อมูลบน DB และคอลเลกชัน
  • เปิดใช้งานการแบ่งกลุ่มข้อมูลบน DB

sh.enableSharding (“geekFlareDB”)

sh.enableSharding("geekFlareDB")
{
        "ok" : 1,
        "operationTime" : Timestamp(1591630612, 1),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1591630612, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

ขั้นตอนที่ 8

  • ในการชาร์ดคีย์ชาร์ดคอลเลกชั่น (จะอธิบายภายหลังในบทความนี้) เป็นสิ่งจำเป็น

ไวยากรณ์: sh.shardCollection(“dbName.collectionName”, { “key” : 1 } )

sh.shardCollection("geekFlareDB.geekFlareCollection", { "key" : 1 } )
{
        "collectionsharded" : "geekFlareDB.geekFlareCollection",
        "collectionUUID" : UUID("0d024925-e46c-472a-bf1a-13a8967e97c1"),
        "ok" : 1,
        "operationTime" : Timestamp(1593570389, 3),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593570389, 3),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

หมายเหตุ หากไม่มีคอลเล็กชัน ให้สร้างดังนี้

db.createCollection("geekFlareCollection")
{
        "ok" : 1,
        "operationTime" : Timestamp(1593570344, 4),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593570344, 5),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

ขั้นตอนที่ 9

แทรกข้อมูลลงในคอลเลกชัน บันทึก Mongo จะเริ่มเติบโต และบ่งชี้ว่าเครื่องบาลานซ์กำลังทำงานและพยายามปรับสมดุลข้อมูลระหว่างชาร์ด

ขั้นตอนที่ 10

ขั้นตอนสุดท้ายคือการตรวจสอบสถานะของการแบ่งกลุ่ม สามารถตรวจสอบสถานะได้โดยการรันคำสั่งด้านล่างบนโหนดเส้นทาง Mongos

สถานะการแบ่งส่วน

ตรวจสอบสถานะการแบ่งส่วนโดยรันคำสั่งด้านล่างบนโหนดเส้นทาง mongo

sh.status()

mongos> sh.status()
--- Sharding Status ---
  sharding version: {
        "_id" : 1,
        "minCompatibleVersion" : 5,
        "currentVersion" : 6,
        "clusterId" : ObjectId("5ede66c22c3262378c706d21")
  }
  shards:
        {  "_id" : "rs1",  "host" : "rs1/localhost:27020,localhost:27021,localhost:27022",  "state" : 1 }
  active mongoses:
        "4.2.7" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  no
        Failed balancer rounds in last 5 attempts:  5
        Last reported error:  Could not find host matching read preference { mode: "primary" } for set rs1
        Time of Reported error:  Tue Jun 09 2020 15:25:03 GMT+0530 (India Standard Time)
        Migration Results for the last 24 hours:
                No recent migrations
  databases:
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
                config.system.sessions
                        shard key: { "_id" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                rs1     1024
                        too many chunks to print, use verbose if you want to force print
        {  "_id" : "geekFlareDB",  "primary" : "rs1",  "partitioned" : true,  "version" : {  "uuid" : UUID("a770da01-1900-401e-9f34-35ce595a5d54"),  "lastMod" : 1 } }
                geekFlareDB.geekFlareCol
                        shard key: { "key" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                rs1     1
                        { "key" : { "$minKey" : 1 } } -->> { "key" : { "$maxKey" : 1 } } on : rs1 Timestamp(1, 0)
                geekFlareDB.geekFlareCollection
                        shard key: { "product" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                rs1     1
                        { "product" : { "$minKey" : 1 } } -->> { "product" : { "$maxKey" : 1 } } on : rs1 Timestamp(1, 0)
        {  "_id" : "test",  "primary" : "rs1",  "partitioned" : false,  "version" : {  "uuid" : UUID("fbc00f03-b5b5-4d13-9d09-259d7fdb7289"),  "lastMod" : 1 } }

mongos>

การกระจายข้อมูล

เราเตอร์ Mongos กระจายโหลดระหว่างชาร์ดตามคีย์ชาร์ด และกระจายข้อมูลอย่างสม่ำเสมอ บาลานเซอร์เริ่มดำเนินการ

  วิธีสลับอุปกรณ์เอาต์พุตเสียงบน Mac

องค์ประกอบสำคัญในการกระจายข้อมูลระหว่างชาร์ดคือ

  • บาลานเซอร์มีบทบาทในการปรับสมดุลชุดย่อยของข้อมูลระหว่างโหนดที่แยกส่วน Balancer ทำงานเมื่อเซิร์ฟเวอร์ Mongos เริ่มแจกจ่ายโหลดระหว่างชาร์ด เมื่อเริ่มต้นแล้ว Balancer จะกระจายข้อมูลอย่างเท่าเทียมกันมากขึ้น ในการตรวจสอบสถานะของตัวบาลานซ์ให้รัน sh.status() หรือ sh.getBalancerState() หรือsh.isBalancerRunning()
mongos> sh.isBalancerRunning()
true
mongos>

หรือ

mongos> sh.getBalancerState()
true
mongos>

หลังจากแทรกข้อมูลแล้ว เราอาจสังเกตเห็นกิจกรรมบางอย่างใน Mongos daemon ที่ระบุว่ากำลังย้ายส่วนข้อมูลบางส่วนสำหรับชาร์ดเฉพาะ และอื่นๆ กล่าวคือ ตัวบาลานเซอร์จะทำงานเพื่อพยายามปรับสมดุลข้อมูลทั่วทั้งชาร์ด รันบาลานเซอร์อาจนำไปสู่ปัญหาด้านประสิทธิภาพ ดังนั้นจึงแนะนำให้รันบาลานเซอร์ภายในระยะหนึ่ง หน้าต่างบาลานเซอร์.

mongos> sh.status()
--- Sharding Status ---
  sharding version: {
        "_id" : 1,
        "minCompatibleVersion" : 5,
        "currentVersion" : 6,
        "clusterId" : ObjectId("5efbeff98a8bbb2d27231674")
  }
  shards:
        {  "_id" : "rs1",  "host" : "rs1/127.0.0.1:27020,127.0.0.1:27021,127.0.0.1:27022",  "state" : 1 }
        {  "_id" : "rs2",  "host" : "rs2/127.0.0.1:27023,127.0.0.1:27024,127.0.0.1:27025",  "state" : 1 }
  active mongoses:
        "4.2.7" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  yes
        Failed balancer rounds in last 5 attempts:  5
        Last reported error:  Could not find host matching read preference { mode: "primary" } for set rs2
        Time of Reported error:  Wed Jul 01 2020 14:39:59 GMT+0530 (India Standard Time)
        Migration Results for the last 24 hours:
                1024 : Success
  databases:
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
                config.system.sessions
                        shard key: { "_id" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                rs2     1024
                        too many chunks to print, use verbose if you want to force print
        {  "_id" : "geekFlareDB",  "primary" : "rs2",  "partitioned" : true,  "version" : {  "uuid" : UUID("a8b8dc5c-85b0-4481-bda1-00e53f6f35cd"),  "lastMod" : 1 } }
                geekFlareDB.geekFlareCollection
                        shard key: { "key" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                rs2     1
                        { "key" : { "$minKey" : 1 } } -->> { "key" : { "$maxKey" : 1 } } on : rs2 Timestamp(1, 0)
        {  "_id" : "test",  "primary" : "rs2",  "partitioned" : false,  "version" : {  "uuid" : UUID("a28d7504-1596-460e-9e09-0bdc6450028f"),  "lastMod" : 1 } }

mongos>
  • คีย์ชาร์ดกำหนดตรรกะในการแจกจ่ายเอกสารของการรวบรวมชาร์ดระหว่างชาร์ด คีย์ชาร์ดสามารถเป็นฟิลด์ที่จัดทำดัชนีหรือฟิลด์ผสมที่จัดทำดัชนี ซึ่งจำเป็นต้องมีอยู่ในเอกสารทั้งหมดของคอลเล็กชันที่จะแทรก ข้อมูลจะถูกแบ่งเป็นส่วนๆ และแต่ละส่วนจะเชื่อมโยงกับชาร์ดคีย์ตามช่วง บนพื้นฐานของเราเตอร์แบบสอบถามช่วงจะตัดสินใจว่าชาร์ดใดจะเก็บก้อน

Shard Key สามารถเลือกได้โดยพิจารณาจากคุณสมบัติ 5 ประการ :

  • คาร์ดินัลลิตี้
  • เขียนแจกจ่าย
  • อ่านการกระจาย
  • อ่านการกำหนดเป้าหมาย
  • อ่านท้องที่

คีย์ชาร์ดในอุดมคติทำให้ MongoDB กระจายโหลดไปยังชาร์ดทั้งหมดเท่าๆ กัน การเลือกชาร์ดคีย์ที่ดีมีความสำคัญอย่างยิ่ง

ภาพ: MongoDB

การถอดโหนดชาร์ด

ก่อนลบชาร์ดออกจากคลัสเตอร์ ผู้ใช้ต้องแน่ใจว่าการย้ายข้อมูลไปยังชาร์ดที่เหลืออย่างปลอดภัย MongoDB ดูแลการระบายข้อมูลอย่างปลอดภัยไปยังโหนดชาร์ดอื่นก่อนที่จะลบโหนดชาร์ดที่ต้องการ

เรียกใช้คำสั่งด้านล่างเพื่อลบชาร์ดที่ต้องการ

ขั้นตอนที่ 1

อันดับแรก เราต้องกำหนดชื่อโฮสต์ของชาร์ดที่จะลบ คำสั่งด้านล่างจะแสดงรายการชาร์ดทั้งหมดที่อยู่ในคลัสเตอร์พร้อมกับสถานะของชาร์ด

db.adminCommand ({ listShards: 1 } )

mongos> db.adminCommand( { listShards: 1 } )
{
        "shards" : [
                {
                        "_id" : "rs1",
                        "host" : "rs1/127.0.0.1:27020,127.0.0.1:27021,127.0.0.1:27022",
                        "state" : 1
                },
                {
                        "_id" : "rs2",
                        "host" : "rs2/127.0.0.1:27023,127.0.0.1:27024,127.0.0.1:27025",
                        "state" : 1
                }
        ],
        "ok" : 1,
        "operationTime" : Timestamp(1593572866, 15),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593572866, 15),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

ขั้นตอนที่ 2

ออกคำสั่งด้านล่างเพื่อลบชาร์ดที่ต้องการออกจากคลัสเตอร์ เมื่อออกแล้ว บาลานเซอร์จะดูแลการกำจัดชิ้นส่วนออกจากโหนดชาร์ดที่ระบายออก จากนั้นจึงปรับสมดุลการกระจายของชิ้นส่วนที่เหลือระหว่างโหนดชาร์ดที่เหลือ

db.adminCommand ({ removeShard: “shardedReplicaNodes” } )

mongos> db.adminCommand( { removeShard: "rs1/127.0.0.1:27020,127.0.0.1:27021,127.0.0.1:27022" } )
{
        "msg" : "draining started successfully",
        "state" : "started",
        "shard" : "rs1",
        "note" : "you need to drop or movePrimary these databases",
        "dbsToMove" : [ ],
        "ok" : 1,
        "operationTime" : Timestamp(1593572385, 2),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593572385, 2),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

ขั้นตอนที่ 3

หากต้องการตรวจสอบสถานะของส่วนแบ่งการระบายออก ให้ออกคำสั่งเดิมอีกครั้ง

db.adminCommand ({ removeShard: “rs1/127.0.0.1:27020,127.0.0.1:27021,127.0.0.1:27022” } )

เราต้องรอจนกว่าการระบายข้อมูลจะเสร็จสมบูรณ์ msg และ state จะแสดงว่าการระบายข้อมูลเสร็จสิ้นหรือไม่ ดังนี้

"msg" : "draining ongoing",
"state" : "ongoing",

นอกจากนี้เรายังสามารถตรวจสอบสถานะด้วยคำสั่ง sh.status() เมื่อนำโหนดชาร์ดออกแล้วจะไม่ปรากฏในเอาต์พุต แต่ถ้าการระบายน้ำยังคงดำเนินต่อไป โหนดที่แบ่งส่วนจะมาพร้อมกับสถานะการระบายน้ำเป็นจริง

ขั้นตอนที่ 4

ตรวจสอบสถานะการระบายน้ำต่อไปด้วยคำสั่งเดียวกันด้านบน จนกว่าส่วนแบ่งข้อมูลที่ต้องการจะถูกลบออกอย่างสมบูรณ์
เมื่อเสร็จสิ้น ผลลัพธ์ของคำสั่งจะแสดงข้อความและสถานะว่าเสร็จสมบูรณ์

"msg" : "removeshard completed successfully",
"state" : "completed",
"shard" : "rs1",
"ok" : 1,

ขั้นตอนที่ 5

สุดท้าย เราต้องตรวจสอบชาร์ดที่เหลืออยู่ในคลัสเตอร์ หากต้องการตรวจสอบสถานะ ให้ป้อน sh.status() หรือ db.adminCommand( { listShards: 1 } )

mongos> db.adminCommand( { listShards: 1 } )
{
        "shards" : [
                {
                        "_id" : "rs2",
                        "host" : "rs2/127.0.0.1:27023,127.0.0.1:27024,127.0.0.1:27025",
                        "state" : 1
                }
        ],
        "ok" : 1,
        "operationTime" : Timestamp(1593575215, 3),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1593575215, 3),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

ในที่นี้ เราจะเห็นว่าชาร์ดที่ลบออกไม่มีอยู่ในรายการชาร์ดอีกต่อไป

ประโยชน์ของการแบ่งส่วนมากกว่าการจำลองแบบ

  • ในการจำลองแบบ โหนดหลักจะจัดการการดำเนินการเขียนทั้งหมด ในขณะที่เซิร์ฟเวอร์สำรองจำเป็นต้องรักษาสำเนาสำรองหรือให้บริการการดำเนินการแบบอ่านอย่างเดียว แต่ในการชาร์ดพร้อมกับชุดเรพพลิกา โหลดจะถูกกระจายไปตามจำนวนเซิร์ฟเวอร์
  • ชุดเรพพลิกาเดียวถูกจำกัดไว้ที่ 12 โหนด แต่ไม่มีการจำกัดจำนวนชาร์ด
  • การจำลองแบบต้องใช้ฮาร์ดแวร์ระดับไฮเอนด์หรือการปรับขนาดแนวดิ่งสำหรับการจัดการชุดข้อมูลขนาดใหญ่ ซึ่งแพงเกินไปเมื่อเทียบกับการเพิ่มเซิร์ฟเวอร์เพิ่มเติมในการชาร์ด
  • ในการจำลองแบบ ประสิทธิภาพการอ่านสามารถปรับปรุงได้โดยการเพิ่มเซิร์ฟเวอร์รอง/เซิร์ฟเวอร์รอง ในขณะที่การแบ่งกลุ่มข้อมูล ประสิทธิภาพการอ่านและการเขียนจะเพิ่มขึ้นโดยการเพิ่มโหนดชาร์ดมากขึ้น

ขีด จำกัด การแบ่งส่วน

  • คลัสเตอร์แบบแบ่งส่วนไม่สนับสนุนการสร้างดัชนีที่ไม่ซ้ำกันในชาร์ดต่างๆ จนกว่าดัชนีที่ไม่ซ้ำกันจะขึ้นต้นด้วยคีย์ชาร์ดแบบเต็ม
  • การดำเนินการอัปเดตทั้งหมดสำหรับคอลเลกชันที่แบ่งใช้บนเอกสารหนึ่งหรือหลายฉบับต้องมีคีย์ที่แบ่งใช้หรือฟิลด์ _id ในแบบสอบถาม
  • คอลเล็กชันสามารถชาร์ดได้หากขนาดไม่เกินเกณฑ์ที่ระบุ เกณฑ์นี้สามารถประมาณได้โดยพิจารณาจากขนาดเฉลี่ยของคีย์ชาร์ดทั้งหมดและขนาดที่กำหนดค่าของชิ้นส่วน
  • การแบ่งกลุ่มประกอบด้วยขีดจำกัดการปฏิบัติงานเกี่ยวกับขนาดคอลเลกชันสูงสุดหรือจำนวนการแยก
  • การเลือกชาร์ดคีย์ที่ไม่ถูกต้องเพื่อนำไปสู่ประสิทธิภาพ

บทสรุป

MongoDB นำเสนอการแบ่งส่วนข้อมูลในตัวเพื่อใช้ฐานข้อมูลขนาดใหญ่โดยไม่กระทบต่อประสิทธิภาพ ฉันหวังว่าข้อมูลข้างต้นจะช่วยคุณในการตั้งค่าการแบ่งกลุ่มย่อย MongoDB ต่อไป คุณอาจต้องการทำความคุ้นเคยกับคำสั่ง MongoDB ที่ใช้กันทั่วไป

เรื่องล่าสุด

x