Clusterimplementaties zijn van groot belang om de hoge beschikbaarheid van gegevens te garanderen en deze te beschermen. MongoDB verbetert dit door replicatie en sharding, waarbij replicatie zorgt voor verticale schaling door redundantie op te heffen, terwijl sharding horizontale schaling opblaast.
Over het algemeen proberen beide benaderingen de werklast onder de leden te verdelen en zo de werklast te verminderen waaraan een enkel knooppunt zou kunnen worden onderworpen. De databaseprestaties kunnen dan worden gezien als snel bij het bedienen van gebruikers met doorvoerbewerkingen. Zonder een prime-clusterarchitectuur ziet u echter mogelijk niet hetzelfde niveau van resultaten, zelfs niet als u sharding en replicatie probeert.
Als de leden van de replicaset gelijk zijn, zal het moeilijk zijn voor de leden om te stemmen en voor een nieuwe voorverkiezing te kiezen als de bestaande op een bepaald moment faalt. In deze blog gaan we de standaard implementatie-architectuur bespreken die men kan gebruiken, maar dit kan variëren in overeenstemming met de applicatie-eisen.
MongoDB-implementatiestrategieën
De architectuur van replicasets is zeer bepalend voor de capaciteit en mogelijkheden van MongoDB.
Een replicaset met drie knooppunten is de standaard clusterimplementatie voor MongoDB in elke productieomgeving, omdat het gegevensredundantie en fouttolerantie biedt. Redundantie is vooral belangrijk bij databaseherstel na een ramp. Een replicaset met drie knooppunten kan de basisimplementatiearchitectuur zijn, maar dit kan variëren afhankelijk van de toepassingsspecificaties en -vereisten. Maak het echter niet te ingewikkeld, aangezien dit tot grotere configuratieproblemen kan leiden.
MongoDB Sharding-strategieën
Sharding vermindert de werklast waaraan de database moet werken voor een bepaalde query door het aantal documenten dat moet worden afgehandeld te verminderen. Het verhoogt daarom de horizontale schaling, waardoor de database verder kan groeien dan de hardwarelimieten van een enkele server. Afhankelijk van de vraag naar werkbelasting, kunnen knooppunten worden toegevoegd aan of verwijderd uit het cluster en MongoDB zal de gegevens op een optimale manier opnieuw in evenwicht brengen zonder tussenkomst van een operatie.
Enkele van de beste implementatiestrategieën voor een shard-cluster zijn:
Ervoor zorgen dat Shard-sleutels uniform worden verdeeld
De reden achter sharding is om de database horizontaal te schalen en het aantal doorvoerbewerkingen te verminderen waaraan een enkele instantie kan worden onderworpen. Als u de shard-sleutels niet uniform verdeelt, krijgt u mogelijk een klein aantal shards. Met weinig shards kunnen bewerkingen worden beperkt door de capaciteit van een enkele shard, waardoor lees- en schrijfbewerkingen traag worden.
Brokken moeten vooraf worden gesplitst en eerst worden gedistribueerd
Shards bevatten gegevensbrokken die zijn gegroepeerd volgens bepaalde criteria voor de shardsleutel. Wanneer u een nieuwe shardverzameling maakt, moet u, voordat u deze met gegevens laadt, lege chunks maken en deze gelijkmatig over alle shards verdelen. Wanneer u MongoDB met gegevens gaat vullen, is het gemakkelijk om de belasting over de betrokken shards te verdelen. De optie numInitialChunks kan worden gebruikt om deze automatisch te doen als u op hash gebaseerde sharding gebruikt. De integerwaarde moet echter kleiner zijn dan 8192 per shard.
Aantal scherven
Twee shards zijn vaak vereist als het minimumaantal om significantie van sharding te bereiken. Een enkele shard is alleen nuttig als u de basis wilt leggen voor het inschakelen van sharding in de toekomst en niet nodig hebt tijdens de implementatietijd.
Liever op bereik gebaseerde sharding boven op hash gebaseerde sharding
Op bereik gebaseerde sharding is gunstig omdat het meer shards oplevert, waardoor bewerkingen kunnen worden gerouteerd naar de minste shards die nodig zijn en vaker naar een enkele shard. In de praktijk kan dit moeilijk zijn, tenzij u een goed begrip hebt van de betrokken gegevens en querypatronen. Gehashte sharding verbetert de uniforme verdeling van de verwerkingscapaciteit ten koste van inferieure, op bereik gebaseerde bewerkingen.
Scatter-Gather-query's gebruiken voor alleen grote aggregatiequery's
Query's die niet kunnen worden gerouteerd op basis van een shardsleutel, moeten voor evaluatie naar alle shards worden verzonden en aangezien ze meerdere shards voor elk verzoek omvatten, worden ze niet lineair geschaald naarmate er meer shards worden toegevoegd, wat leidt tot overhead dat verslechtert de prestaties van de database. Deze bewerking staat bekend als scatter-gather en kan alleen worden vermeden als u de Shard-sleutel in uw query opneemt.
De aanpak is alleen nuttig bij grote aggregatiequery's waarbij elke query parallel op alle shards kan worden uitgevoerd.
MongoDB-replicatiestrategieën
Replicatie verbetert de verticale schaling in MongoDB, zodat de werklast wordt verdeeld over de betrokken leden. In de productieomgeving zijn dit enkele van de overwegingen die men moet maken voor een optimale clusterarchitectuur.
Aantal knooppunten
Het maximum aantal nodes dat een replicaset kan hebben, is 50 met zeven stemgerechtigde leden. Elk lid na de 7e wordt als niet-stemgerechtigd beschouwd. Een goede cluster zou daarom 7 stemgerechtigde leden moeten hebben om het verkiezingsproces gemakkelijk te maken.
Inzet een oneven aantal stemgerechtigde leden en als je maar minder dan 7 maar even aantal leden hebt, dan moet je een arbiter inzetten als een ander stemgerechtigd lid. Arbiters slaan geen kopie van de gegevens op en hebben daarom minder middelen nodig om te beheren. Bovendien kun je ze onderwerpen aan een omgeving waar je de andere leden niet aan zou kunnen onderwerpen.
Overwegingen bij fouttolerantie
Soms kunnen sommige leden niet meer beschikbaar zijn als gevolg van factoren zoals stroomuitval of netwerkstoringen en verbroken verbindingen. Het aantal leden dat in de set blijft en in staat is om een primaire te kiezen, creëert een situatie die bekend staat als fouttolerantie. Het is daarom het verschil tussen het totale aantal leden van de replicaset en de meerderheid van de stemgerechtigde leden die nodig zijn om een voorverkiezing te kiezen. Het ontbreken van een primaire dicteert dat schrijfbewerkingen niet kunnen worden uitgevoerd.
De onderstaande tabel toont een voorbeeldrelatie tussen de drie.
Totaal aantal leden van de replicaset
Meerderheid vereist om nieuwe primaire te kiezen
Fouttolerantie
3
2
1
4
3
1
5
3
2
6
4
2
7
5
2
De relatie is niet zo direct in die zin dat als je meer leden aan de set toevoegt, er niet wordt gegeven dat de fouttolerantie zal toenemen, zoals blijkt uit de tabel. Extra leden bieden ondersteuning voor speciale functies zoals back-ups en rapportage.
Capaciteitsplanning en taakverdeling voor zware leesbewerkingen
U moet een reservecapaciteit hebben voor uw implementatie door nieuwe leden toe te voegen voordat de huidige vraag de capaciteit van de bestaande set verzadigt.
Voor zeer veel leesverkeer verdeelt u de leessnelheid over de secundaire leden en wanneer het cluster groeit, voegt u leden toe of verplaatst u deze naar alternatieve datacenters om redundantie te bereiken en de beschikbaarheid van gegevens te vergroten.
Je kunt ook doelbewerkingen met tagsets gebruiken om leesbewerkingen op specifieke leden te richten of schrijfzorg wijzigen om bevestiging van specifieke leden te vragen.
Knooppunten moeten geografisch worden gedistribueerd
Datacenters kunnen ook uitvallen door een of andere catastrofe. Daarom wordt geadviseerd om ten minste één of twee leden in een apart datacenter te houden voor gegevensbeschermingsdoeleinden. Gebruik indien mogelijk een oneven aantal datacenters en selecteer een distributie die de kans maximaliseert dat, zelfs bij verlies van een datacenter, de resterende leden van de replicaset een meerderheid kunnen vormen of op zijn minst een kopie van de gegevens kunnen leveren.
Gebruik logboeken voor onverwachte fouten
Standaard is dit ingeschakeld in MongoDB. U moet ervoor zorgen dat deze optie is ingeschakeld om gegevensverlies te beschermen in het geval van serviceonderbrekingen, zoals plotseling opnieuw opstarten en stroomstoringen.
Implementatiepatronen
Er zijn hoofdzakelijk twee implementatiebenaderingen, namelijk:
- Replicasets van drie leden die de minimaal aanbevolen architectuur voor een replicaset bieden.
- Replicaset verdeeld over twee of meer datacenters ter bescherming tegen faciliteitspecifieke storingen zoals stroomuitval.
De patronen zijn echter afhankelijk van de applicatievereisten, maar indien mogelijk kunt u functies van deze twee combineren in uw implementatiearchitectuur.
Hostnamen en naamgeving van replicasets
Gebruik een logische DNS-hostnaam in plaats van een IP-adres bij het configureren van replicasetleden of shard-clusterleden. Dit is om de pijn te vermijden die gepaard gaat met configuratiewijzigingen die u moet maken als gevolg van gewijzigde IP-adressen.
In het geval van naamgeving van replicasets, gebruikt u verschillende namen voor de sets, aangezien sommige stuurprogramma's replicasetverbindingen groeperen op replicasetnaam.
Conclusie
De architectuurlay-out voor een replicaset bepaalt de capaciteit en mogelijkheden van uw implementatie. Gegevensbescherming en systeemprestaties zijn de belangrijkste overwegingen bij het opzetten van de architectuur. Men moet rekening houden met vitale factoren zoals fouttolerantie, aantal replicasetleden, optimale shardingsleutel en implementatiepatronen voor hoge beschikbaarheid en gegevensbescherming. Geografische distributie van de replicasetknooppunten kan veel van deze factoren aanpakken door te zorgen voor redundantie en fouttolerantie te bieden als een van de datacenters afwezig is.