MongoDB Sharding: Trin-for-trin praktisk vejledning

Af
Tweet
Share
Share
Pin

Sharding er en proces med at opdele den store skala af datasæt i en del af mindre datasæt på tværs af flere MongoDB-instanser i et distribueret miljø.

Hvad er Sharding?

MongoDB sharding giver os en skalerbar løsning til at gemme en stor mængde data blandt antallet af servere i stedet for at gemme på en enkelt server.

Rent praktisk er det ikke muligt at lagre eksponentielt voksende data på en enkelt maskine. At forespørge på en enorm mængde data, der er gemt på en enkelt server, kan føre til høj ressourceudnyttelse og giver muligvis ikke tilfredsstillende læse- og skrivegennemstrømning.

Grundlæggende er der to typer skaleringsmetoder, der eksisterer for at udføre voksende data med systemet:

Vertical Scaling arbejder med at forbedre en enkelt serverydelse ved at tilføje mere kraftfulde processorer, opgradere RAM eller tilføje mere diskplads til systemet. Men der er de mulige implikationer af at anvende vertikal skalering i praktiske tilfælde med eksisterende teknologi og hardwarekonfigurationer.

Horisontal skalering arbejder med at tilføje flere servere og fordele belastningen på flere servere. Da hver maskine vil håndtere delmængden af ​​hele datasættet, giver den bedre effektivitet og omkostningseffektiv løsning i stedet for at implementere den avancerede hardware. Men det kræver yderligere vedligeholdelse af kompleks infrastruktur med et stort antal servere.

Mongo DB skæring arbejder på den horisontale skaleringsteknik.

Sharing komponenter

For at opnå sharding i MongoDB kræves følgende komponenter:

Shard er en Mongo-instans til at håndtere en delmængde af originale data. Shards skal installeres i replikasættet.

Mongos er en Mongo-instans og fungerer som en grænseflade mellem en klientapplikation og en sharded cluster. Det fungerer som en forespørgselsrouter til shards.

Config Server er en Mongo-instans, som gemmer metadataoplysninger og konfigurationsdetaljer for klyngen. MongoDB kræver, at konfigurationsserveren installeres som et replikasæt.

Sharding arkitektur

MongoDB-klyngen består af en række replikasæt.

Hvert replikasæt består af minimum 3 eller flere mongo-forekomster. En sharded cluster kan bestå af flere mongo shards-instanser, og hver shard-instans fungerer inden for et shard-replikasæt. Applikationen interagerer med Mongos, som igen kommunikerer med skår. Derfor interagerer applikationer aldrig direkte med shard-noder i Sharding. Forespørgselsrouteren distribuerer delmængderne af data mellem shards-noder baseret på shard-nøglen.

Sharding implementering

Følg nedenstående trin for skæring

Trin 1

  • Start konfigurationsserveren i replikasættet og aktiver replikering mellem dem.

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

Trin 2

  • Initialiser replikasæt på en af ​​konfigurationsserverne.

rs.initiate( { _id : “rs0”, configsvr: sand, medlemmer: [   { _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)
}

Trin 3

  • Begynd at sønderdele servere i replikasættet og aktiver replikering mellem dem.
  Sådan downloader du NVIDIA-drivere uden GeForce-oplevelse

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 initialiserer den første sharding-server som primær, for at flytte den primære sharding-serverbrug flyttePrimær metode.

Trin 4

  • Initialiser replikasæt på en af ​​de shardede servere.

rs.initiate( { _id : “rs0”, medlemmer: [   { _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)
}

Trin 5

  • Start mangoerne til den sønderdelte klynge

mongos –port 40000 –configdb rs0/localhost:27019,localhost:27018, localhost:27017

Trin 6

  • Tilslut mongo-ruteserveren

mongo –port 40000

  • Tilføj nu sharding-servere.

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)
                }
        }
}

Trin 7

  • På mongo shell aktivere sharding på DB og samlinger.
  • Aktiver sharding på 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)
                }
        }
}

Trin 8

  • For at sønderdele kræves indsamlingsshard-nøglen (beskrevet senere i denne artikel).

Syntaks: 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)
                }
        }
}

Bemærk, hvis samlingen ikke eksisterer, skal du oprette som følger.

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

Trin 9

Indsæt data i samlingen. Mongo-logfiler vil begynde at vokse, og indikerer, at en balancer er i aktion og forsøger at balancere dataene mellem shards.

Trin 10

Det sidste trin er at kontrollere status for sønderdelingen. Status kan kontrolleres ved at køre nedenstående kommando på Mongos-ruteknuden.

Delingsstatus

Tjek sharding-status ved at køre under kommandoen på mongo-ruteknuden.

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>

Data distribution

Mongos-routeren fordeler belastningen mellem shards baseret på shard-nøglen og for jævnt at fordele data; balancer kommer i aktion.

  Sådan aktiverer eller deaktiverer du det nye Chrome-design

Nøglekomponenten til at distribuere data mellem shards er

  • En balancer spiller en rolle i at afbalancere delmængden af ​​data blandt de sharded noder. Balancer kører, når Mongos-serveren begynder at fordele belastninger mellem shards. Når den først var startet, fordelte Balancer data mere jævnt. For at kontrollere balancerens tilstand, kør sh.status() eller sh.getBalancerState() ellersh.isBalancerRunning().
mongos> sh.isBalancerRunning()
true
mongos>

ELLER

mongos> sh.getBalancerState()
true
mongos>

Efter at have indsat dataene, kunne vi bemærke noget aktivitet i Mongos-dæmonen, der angiver, at den flytter nogle bidder til de specifikke shards og så videre, dvs. balanceren vil være i aktion og forsøge at balancere dataene på tværs af shards. At køre balancer kan føre til præstationsproblemer; derfor foreslås det at køre balanceren inden for en vis balancer vindue.

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 bestemmer logikken for at distribuere dokumenter af sharded samling blandt shards. Shard-nøgle kan være et indekseret felt eller et indekseret sammensat felt, som skal være til stede i alle dokumenter i den samling, der skal indsættes. Data vil blive opdelt i bidder, og hver chunk vil blive knyttet til den områdebaserede shard-nøgle. På grundlag af rækkeviddeforespørgslen vil routeren beslutte, hvilken shard der skal gemme klumpen.

Shard Key kan vælges ved at overveje fem egenskaber:

  • Kardinalitet
  • Skriv distribution
  • Læs distribution
  • Læs målretning
  • Læs lokalitet

En ideel shard-nøgle gør, at MongoDB fordeler belastningen jævnt mellem alle shard. At vælge en god shard nøgle er ekstremt vigtigt.

Billede: MongoDB

Fjernelse af shard-noden

Før du fjerner shards fra klyngen, skal brugeren sikre sikker migrering af data til resterende shards. MongoDB sørger for sikkert at dræne data til andre shards noder før fjernelse af den nødvendige shard node.

Kør nedenstående kommando for at fjerne det nødvendige shard.

Trin 1

Først skal vi bestemme værtsnavnet på det shard, der skal fjernes. Nedenstående kommando vil liste alle shards til stede i klyngen sammen med shardens tilstand.

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)
                }
        }
}

Trin 2

Udfør nedenstående kommando for at fjerne det nødvendige shard fra klyngen. Når den er udstedt, sørger balanceren for at fjerne bidder fra drænende shard-knude og balancerer derefter fordelingen af ​​resterende chunks blandt resten shards-knudepunkter.

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)
                }
        }
}

Trin 3

For at kontrollere status for det drænende skår skal du afgive den samme kommando igen.

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

Vi er nødt til at vente, indtil dræningen af ​​dataene er afsluttet. msg og state felter vil vise, om dræning af data er gennemført eller ej, som følger

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

Vi kan også tjekke status med kommandoen sh.status(). Når den først er fjernet, vil den sønderdelte node ikke blive afspejlet i outputtet. Men hvis dræning vil være i gang, vil den sønderdelte node komme med dræningsstatus som sand.

Trin 4

Bliv ved med at kontrollere status for dræning med samme kommando ovenfor, indtil det nødvendige skår er fjernet helt.
Når den er fuldført, vil outputtet af kommandoen afspejle meddelelsen og tilstanden som fuldført.

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

Trin 5

Til sidst skal vi tjekke de resterende skår i klyngen. For at kontrollere status skal du indtaste sh.status() eller 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)
                }
        }
}

Her kan vi se, at det fjernede skår ikke længere er til stede på listen over skår.

Fordele ved Sharding frem for replikering

  • Ved replikering håndterer den primære node alle skriveoperationer, hvorimod sekundære servere er forpligtet til at vedligeholde sikkerhedskopier eller betjene skrivebeskyttede operationer. Men ved sharding sammen med replikasæt bliver belastningen fordelt på antallet af servere.
  • Et enkelt replikasæt er begrænset til 12 noder, men der er ingen begrænsning på antallet af shards.
  • Replikering kræver avanceret hardware eller vertikal skalering til håndtering af store datasæt, hvilket er for dyrt sammenlignet med tilføjelse af yderligere servere i sharding.
  • Ved replikering kan læseydeevnen forbedres ved at tilføje flere slave/sekundære servere, hvorimod både læse- og skriveydeevnen ved sharding vil blive forbedret ved at tilføje flere shards-noder.

Skæringsbegrænsning

  • Sharded-klyngen understøtter ikke unik indeksering på tværs af shards, før det unikke indeks er præfikset med fuld shard-nøgle.
  • Alle opdateringshandlinger for sharded-indsamling enten på et eller flere dokumenter skal indeholde sharded-nøglen eller _id-feltet i forespørgslen.
  • Samlinger kan sønderdeles, hvis deres størrelse ikke overstiger den angivne grænse. Denne tærskel kan estimeres på basis af den gennemsnitlige størrelse af alle shard-nøgler og konfigureret størrelse af bidder.
  • Skæring består af operationelle grænser for maks. samlingsstørrelse eller antal opdelinger.
  • At vælge de forkerte shard-nøgler for at føre til præstationsimplikationer.

Konklusion

MongoDB tilbyder indbygget sharding for at implementere en stor database uden at kompromittere ydeevnen. Jeg håber, at ovenstående hjælper dig med at opsætte MongoDB-sharding. Dernæst vil du måske blive fortrolig med nogle af de almindeligt anvendte MongoDB-kommandoer.