Rick Golba on ratkaisuinsinööri Perconassa.
MongoDB on kehittäjien suosikkitietokanta. NoSQL-tietokantavaihtoehtona se tarjoaa kehittäjille tietokantaympäristön, jolla on joustava skeemasuunnittelu, automaattinen vianmääritys ja kehittäjille tuttu syöttökieli, nimittäin JSON.
NoSQL-tietokantoja on monia erilaisia. Avainarvomyymälät tallentavat ja noutavat jokaisen kohteen sen nimellä (tunnetaan myös nimellä avain). Laaja sarakemyymälä on eräänlainen avainarvosäilö, joka käyttää sarakkeita ja rivejä (aivan kuten relaatiotietokanta), vain taulukon sarakkeiden ja rivien nimet voivat vaihdella. Kuvaajatietokannat käyttävät kaaviorakenteita tietoverkkojen tallentamiseen. Asiakirjapainotteiset tietokannat tallentavat tietoja asiakirjoina, mikä tarjoaa enemmän rakenteellista joustavuutta kuin muut tietokannat.
MongoDB on asiakirjapainotteinen tietokanta. Se on alustojen välinen tietokanta, joka pitää tietoja asiakirjoissa binäärikoodatussa JSON-muodossa (tunnetaan nimellä binaarinen JSON tai BSON). Binaarimuoto lisää sekä JSON: n nopeutta että joustavuutta ja lisää enemmän tietotyyppejä.
MongoDB: n replikaatiomekanismit auttavat tarjoamaan korkeaa käytettävyyttä, ja sen sirpalemekanismi mahdollistaa horisontaalisen skaalautuvuuden. Monet huipputason Internet-yritykset, kuten Facebook ja eBay, käyttävät MongoDB: tä tietokantaympäristössään.
Miksi seurata MongoDB: tä?
MongoDB-tietokantaympäristösi voi olla yksinkertainen tai monimutkainen, paikallinen tai jaettu, paikan päällä tai pilvipalvelussa. Jos haluat varmistaa suorituskykyisen ja käytettävissä olevan tietokannan, sinun tulee seurata ja seurata analytiikkaa, jotta voit:
- Määritä tietokannan nykyinen tila
- Tarkista suorituskykytiedot epänormaalin käyttäytymisen tunnistamiseksi
- Anna joitain diagnostiikkatietoja havaittujen ongelmien ratkaisemiseksi
- Korjaa pienet ongelmat, ennen kuin ne kasvavat suuremmiksi
- Pidä ympäristösi toiminnassa ja sujuvasti
- Varmista jatkuva saatavuus ja menestys
Valvomalla tietokantaympäristöä mitattavalla ja säännöllisellä tavalla varmistat, että voit havaita mahdolliset ristiriidat, outo käyttäytyminen tai ongelmat ennen kuin ne vaikuttavat suorituskykyyn. Oikea seuranta tarkoittaa, että voit nopeasti havaita hidastumisen, resurssirajoitukset tai muun poikkeavan käyttäytymisen ja korjata nämä ongelmat, ennen kuin sinulle törmää hitaiden verkkosivustojen ja sovellusten, käytettävissä olevan tiedon tai turhautuneiden asiakkaiden seuraukset.
Mitä meidän tulisi seurata?
MongoDB-ympäristössä voit seurata monia asioita, mutta muutama avainalue vie sinut nopeasti pois, jos jokin on vialla. Sinun tulisi analysoida seuraavia tietoja:
- Replikaation viive. Replikointiviive viittaa viiveisiin tietojen kopioinnissa ensisijaisesta solmusta toissijaiseen solmuun.
- Kopion tila. Replikatila on menetelmä seurantaan, jos toissijaiset solmut ovat kuolleet ja jos on valittu uusi ensisijainen solmu.
- Lukitustila. Lukitustila näyttää, mitkä tietolukot on asetettu, ja kuinka kauan ne ovat olleet paikallaan.
- Levyn käyttö. Levyn käyttö tarkoittaa levyn käyttöä.
- Muistin käyttö. Muistin käyttö viittaa siihen, kuinka paljon muistia käytetään ja kuinka sitä käytetään.
- Liitäntöjen määrä. Tietokannassa olevien yhteyksien määrä pyyntöjen palvelemiseksi mahdollisimman nopeasti.
Kaivetaan joitakin yksityiskohtia.
Replikaation viive
MongoDB käyttää replikointia vastaamaan saatavuuteen liittyviin haasteisiin ja tavoitteisiin. Replikointi on datan eteneminen ensisijaisesta solmusta useisiin toissijaisiin solmuihin, kun ensisijaisen solmun toiminnot muuttavat tietoja. Nämä solmut voivat sijaita yhdessä, eri maantieteellisissä sijainneissa tai virtuaalisesti.
Kaikilla tasoilla, tietojen replikoinnin tulisi tapahtua nopeasti ja ilman ongelmia. Monia asioita voi tapahtua, jotka estävät replikointiprosessin sujuvan suorittamisen. Jopa parhaimmissa olosuhteissa verkon fyysiset ominaisuudet rajoittavat sitä, kuinka nopeasti data replikoituu. Viivettä replikoinnin aloittamisen ja loppuun saattamisen välillä kutsutaan replikaation viiveeksi.
Sujuvasti toimivassa ensisijaisten ja toissijaisten solmujen joukossa (jäljempänä "kopiosarja") toissijaiset kopioivat nopeasti muutokset ensisijaiseen, replikoivat jokaisen operaation ryhmän oplogista niin nopeasti kuin ne tapahtuvat (tai mahdollisimman lähellä) . Tavoitteena on pitää replikaation viive lähellä nollaa. Tietojen lukemisen mistä tahansa solmusta tulisi olla johdonmukaista. Jos valittu ensisijainen solmu laskee tai muuten ei ole käytettävissä, toissijainen voi ottaa ensisijaisen roolin vaikuttamatta asiakkaan tietojen tarkkuuteen. Toistettujen tietojen tulisi olla yhdenmukaisia ensisijaisten tietojen kanssa ennen ensisijaisen laskua.
Replikaation viive on syy siihen, että ensisijaiset ja toissijaiset solmut poistuvat synkronoinnista. Jos toissijainen solmu valitaan ensisijaiseksi ja toisintoviive on korkea, toissijaisen version tiedot voivat olla vanhentuneita. Kohonnut replikaation viive voi tapahtua useista ei-pysyvistä tai määrittelemättömistä syistä ja korjata itsensä. Kuitenkin, jos replikaation viive pysyy korkeana tai alkaa kasvaa säännöllisesti, se on merkki systeemisestä tai ympäristöongelmasta. Kummassakin tapauksessa, mitä suurempi replikaation viive - ja mitä pidempään se pysyy korkealla - sitä enemmän tietosi ovat vaarassa olla vanhentuneita asiakkaille.
On vain yksi tapa analysoida tätä mittaria: seuraa sitä! Tämä on mittari, jota tulisi seurata 24x7x365, joten se on parasta tehdä automaation ja laukaisuvaroitusten avulla DBA: iden tai vastausjärjestelmän ylläpitäjien varoittamiseksi heti, kun se saavuttaa ei-toivotun kynnyksen. Tämän kynnyksen kokoonpano riippuu sovelluksesi replikointiviiveen toleranssista. Käytä oikeaa kynnystä käyttämällä työkalua, joka kuvaa viiveitä ajan suhteen, kuten Kompassi, MongoBooster, Studio 3T tai Perconan valvonta ja hallinta (PMM).
Kopion tila
Replikointi hoidetaan kopiosarjojen kautta. Replikasarja on joukko solmuja, joissa on valittu ensisijainen solmu ja useita toissijaisia solmuja. Ensisijainen solmu on ajantasaisimpien tietojen haltija, ja kyseiset tiedot replikoidaan toissijaisiin, kun muutoksia tehdään ensisijaiseen.
Normaalisti yksi replikaryhmän jäsen on ensisijainen ja kaikki muut jäsenet ovat toissijaisia. Määritetty tila muuttuu harvoin. Jos se tapahtuu, haluamme tietää siitä (yleensä välittömästi). Roolimuutos tapahtuu yleensä nopeasti ja yleensä saumattomasti, mutta on tärkeää ymmärtää tarkalleen miksi solmun tila muuttui, koska se olisi voinut johtua laitteisto- tai verkkovirheestä. Ensisijaisen ja toissijaisen tilan vaihtaminen (tunnetaan myös nimellä räpytys) ei ole normaalia, ja täydellisessä maailmassa sen pitäisi tapahtua vain tunnetuista syistä (esimerkiksi ympäristöhuollon aikana, kuten ohjelmiston tai laitteiston päivittäminen, tai tietyn tapahtuman aikana, kuten verkkokatkoksena).
Lukitustila
Tietokannat ovat erittäin samanaikaisia ja epävakaita ympäristöjä, joissa useat asiakkaat tekevät pyyntöjä ja aloittavat tapahtumia, jotka suoritetaan tiedoille. Nämä pyynnöt ja tapahtumat eivät tapahdu peräkkäin tai järkevässä järjestyksessä. Ristiriitoja voi esiintyä - esimerkiksi jos tapahtumat yrittävät päivittää samaa tietuetta tai asiakirjaa, jos lukupyyntö tulee tietojen päivityksen aikana jne. Tapa, jolla monet tietokannat huolehtivat siitä, että tietoihin pääsee järjestäytyneellä tavalla, on lukitus. ” Lukitus tapahtuu, kun tapahtuma estää tietokannan tietueen, asiakirjan, rivin, taulukon jne. Muuttamisen tai lukemisen, kunnes nykyinen tapahtuma on käsitelty.
MongoDB: ssä lukitus suoritetaan kokoelma- tai asiakirjatasolla estääkseen ristiriidat samanaikaisten tapahtumien välillä. Tietyt toiminnot voivat vaatia myös yleisen tietokannan lukituksen (esimerkiksi kokoelman pudottaessa). Jos lukitus tapahtuu liian usein, se vaikuttaa suorituskykyyn tekemällä tapahtumat (mukaan lukien lukut) odottamaan, että tietokannan lukitut osat ovat käytettävissä lukemista tai muokkaamista varten. Suuri lukitusprosentti on merkki muista tietokannan ongelmista: laitteistovika, huono skeeman suunnittelu, huonosti määritetyt indeksit, indeksien käyttämättä jättäminen jne.
On tärkeää seurata lukitusprosenttia. Sinun tulisi tietää, mikä on hyväksyttävä prosenttiosuus suorituskyvyn suhteen ja kuinka kauan prosenttiosuus voidaan säilyttää, ennen kuin se vaikuttaa suorituskykyyn. Jos suorituskyky heikkenee liikaa korkean lukitusprosentin vuoksi, se voi laukaista kopion tilan muutoksesta palvelimen vastaamattomuuden vuoksi.
Levyn käyttö
Jokaisen DBA: n tulisi tarkkailla tietokantapalvelimiensa käytettävissä olevaa levytilaa. Kun tietokanta käyttää isännän levytilaa, palvelin pysähtyy äkillisesti. Tietojen ennakoiva mitoitus ja lokitiedostokokojen seuranta ovat erinomaisia tekniikoita tietokantojen mitoituksessa.
Usein tietokantasi on ehkä kasvettava automaattisesti. Näissä tapauksissa sinun on taattava, että se ei kasva laitteistosta. Levytilan säännöllinen tarkistaminen voi auttaa estämään tietokantapalvelimen odottamattomat pysähtymät sekä etsimään huonoja suunnitteluongelmia (kuten kyselyt, jotka edellyttävät koko kokoelman tarkistusta).
Muistin käyttö
Kaikkien tietojen pitäminen RAM-muistissa nopeuttaa tietokannan vasteaikoja. Mutta mitä se tarkoittaa, ja mistä tiedät, kun jotain on RAM-muistissa?
Tapa, jolla tietokanta käyttää muistia, voi olla hieman epäselvä. Suuri osa palvelimen käyttämästä muistista on puskurivarastolle (data). Voi olla vaikeaa selvittää, mikä tietokanta käyttää suurinta osaa puskurivaraston muistista, ja vielä vaikeampaa selvittää, mitkä kokoelmat tai asiakirjat ovat tosiasiallisesti puskurivaraston muistissa. Näiden tietojen tiedosta on hyötyä, kun tietokanta kuormitetaan tasapainottamalla useita palvelimia (sirpaloitumisen kautta) tai tunnistettaessa tietoja, jotka ovat optimaalisia yhdistämistä varten yhdeksi palvelinilmentymäksi.
Työkalujen avulla voit selvittää, mitkä esiintymät käyttävät eniten muistia ja mihin tietoihin, voit auttaa sinua optimoimaan ympäristön.
Liitäntöjen määrä
Tietokantatapahtumat käynnistävät yleensä sovellukset ja prosessit "yhteyksien" kautta. Avoimien yhteyksien määrä voi vaikuttaa tietokannan suorituskykyyn. Teoriassa, kun tapahtuma on valmis, yhteys tulisi katkaista. Käytännössä monet yhteydet jäävät kuitenkin avoimiksi. On normaalia, että tietokanta pitää joitain yhteyksiä elossa tiettyjen tapahtumien helpottamiseksi, mutta jos liian monta jätetään avoimeksi, se voi rajoittaa yhteyspoolissa käytettävissä olevaa määrää.
Parhaana käytäntönä tietokannan tulisi pitää yhteydet auki mahdollisimman vähän aikaa, joka tarvitaan pyynnön täyttämiseen. Tämän ansiosta pieni joukko yhteyksiä voi palvella valtavaa määrää tapahtumapyyntöjä. Muussa tapauksessa sovellustapahtumapyynnöt ovat jumissa odottaessaan avointa yhteyttä. Sinun on seurattava tietokannan avoimien yhteyksien määrää varmistaaksesi, että niitä suljetaan ja että pooliin on jäänyt riittävä määrä yhteyksiä saapuvia pyyntöjä varten.
Työkalut toimitetaan MongoDB: n mukana
Nyt kun tiedämme, mitä meidän tulisi seurata, seuraava kysymys on miten? Onneksi MongoDB: ssä on joitain helppokäyttöisiä työkaluja palvelintilastojen seuraamiseen.
mongostaatti
Tämä apuohjelma tarjoaa maailmanlaajuiset tilastot muistin käytöstä, kopiosarjan tilasta ja muusta päivitettynä joka sekunti (oletusarvoisesti).
mongostaatti apuohjelma antaa sinulle yleiskuvan MongoDB-palvelinilmentymästäsi. Jos sinulla on yksi mongod-ilmentymä, se näyttää kyseisen yksittäisen instanssin tilastot. Jos sinulla on MongoDB-klusteriympäristö, se palauttaa "mongos" -ilmenteen tilastot. mongostaatti käytetään parhaiten yksittäisen tapahtuman katselemiseen tietyssä tapahtumassa (esimerkiksi mitä tapahtuu, kun tietty sovelluspyyntö saapuu). Voit käyttää tätä komentoa palvelimen perustilastojen seuraamiseen:
- prosessori
- Muisti
- Levyn IO
- Verkkoliikenne
Katso MongoDB-dokumentaatio mongostaatti käytön yksityiskohdista.
mongotop
Tämä apuohjelma tarjoaa kokoelmatason tilastotiedot luku- ja kirjoitustoiminnasta.
mongotop komento seuraa aikaa, joka tarvitaan luku- ja kirjoitusoperaatioiden suorittamiseen MongoDB-palvelinilmentymässä. Se tarjoaa tilastoja kokoelmaa kohti. mongotop palauttaa arvot oletusarvoisesti joka sekunti, mutta voit säätää aikataulua tarpeen mukaan.
Kaikki sekunnin mittarit ovat suhteessa palvelimesi kokoonpanoon sekä klusteriarkkitehtuuriin. Yksittäisten paikallisesti suoritettujen esiintymien kohdalla, ja oletusporttia käytettäessä sinun tarvitsee vain kirjoittaa mongotop komento. Jos käytät klusteroitua ympäristöä, jossa on useita mongodi- ja mongos-esiintymiä, sinun on annettava komento isäntänimi ja porttinumero.
Katso MongoDB-dokumentaatio mongotop käytön yksityiskohdista.
rs.status ()
Tämä komento antaa kopiosarjan tilan.
Voit käyttää rs.status () komento saada tietoja käynnissä olevasta kopiosarjasta. Tämä komento voidaan suorittaa minkä tahansa ryhmän minkä tahansa jäsenen konsolista, ja se palauttaa kopiosarjan tilan kyseisen jäsenen näkemällä tavalla.
Katso MongoDB-dokumentaatio rs.status () käytön yksityiskohdista.
