Huomasin sen hiljattain (esimerkiksi lisenssimuutosten vuoksi). Se sai minut ajattelemaan, että olen muutaman viime vuoden aikana nähnyt joukon artikkeleita siitä, kuinka kauheaa MongoDB on ja ettei kenenkään pitäisi koskaan käyttää sitä. Mutta tänä aikana MongoDB:stä on tullut paljon kypsempi tuote. Mitä tapahtui? Johtuuko kaikki viha todella virheistä uuden DBMS:n markkinoinnin alussa? Vai käyttävätkö ihmiset vain MongoDB:tä väärässä paikassa?
Jos sinusta yhtäkkiä tuntuu, että puolustan MongoDB:tä, lue artikkelin lopussa.
Uusi trendi
Olen ollut ohjelmistoalalla enemmän vuosia kuin on reilua sanoa, mutta silti olen ollut vain osa alaamme osuvia trendejä. Olen nähnyt 4GL:n, AOP:n, Agilen, SOA:n, Web 2.0:n, AJAX:n, blockchainin nousun… luettelo on loputon. Joka vuosi tulee uusia trendejä. Jotkut hiipuvat nopeasti, kun taas toiset muuttavat perusteellisesti ohjelmistojen kehitystapaa.
Jokaisen uuden trendin ympärille syntyy tietty yleinen jännitys: ihmiset joko hyppäävät itse veneeseen tai näkevät muiden tuottaman melun - ja seuraavat väkijoukkoja. Gartner on kodifioinut tämän prosessin . Vaikka tämä kaavio onkin kiistanalainen, se kuvaa karkeasti mitä teknologioille tapahtuu ennen kuin niistä tulee lopulta hyödyllisiä.
Mutta aika ajoin tulee (tai tulee toinen tuleminen, kuten tässä tapauksessa) uusi innovaatio, jota ajaa vain yksi sen tietty toteutus. NoSQL:n tapauksessa hype johtui vahvasti MongoDB:n tulosta ja meteorisesta noususta. MongoDB ei aloittanut tätä kehitystä: itse asiassa suurilla Internet-yrityksillä alkoi olla ongelmia suurten tietomäärien käsittelyssä, mikä johti ei-relaatiotietokantojen palautumiseen. Yleinen liike alkoi projekteista, kuten Googlen Bigtable ja Facebookin Cassandra, mutta MongoDB:stä tuli tunnetuin ja saavutettavin NoSQL-tietokannan toteutus, johon useimmilla kehittäjillä oli pääsy.
Huomautus: Saatat ajatella, että sekoitan asiakirjatietokannat saraketietokantoihin, avain-/arvovarastoihin tai muihin moniin muihin tietovarastoihin, jotka kuuluvat NoSQL:n yleisen määritelmän piiriin. Ja olet oikeassa. Mutta tuolloin vallitsi kaaos. Kaikki ovat pakkomielle NoSQL:stä, siitä on tullut kaikkea ehdottoman välttämätön, vaikka monet eivät nähneet eroja eri teknologioissa. MongoDB:sta on tullut monille synonyymi NoSQL.
Ja kehittäjät hyppäsivät siihen. Ajatus kaavattomasta tietokannasta, joka skaalautuu taianomaisesti ratkaisemaan minkä tahansa ongelman, oli melko houkutteleva. Vuoden 2014 tienoilla näytti siltä, että kaikkialla relaatiotietokantoja, kuten MySQL, Postgres tai SQL Server, käytettiin vuosi sitten, MongoDB-tietokantoja otettiin käyttöön. Kun kysyttiin miksi, voit saada vastauksia banaalista "tämä on verkon mittakaava" ja harkitsevampaan "tietoni ovat hyvin löyhästi jäsenneltyjä ja sopivat hyvin tietokantaan ilman skeemaa".
On tärkeää muistaa, että MongoDB ja asiakirjatietokannat yleensä ratkaisevat useita perinteisten relaatiotietokantojen ongelmia:
- Tiukka kaava: jos sinulla on relaatiotietokanta, jos sinulla on dynaamisesti luotuja tietoja, sinun on joko luotava joukko satunnaisia "erilaisia" tietosarakkeita, työnnettävä datablobeja sinne tai käytettävä määritystä …kaikella tällä on merkittäviä haittoja.
- Skaalausvaikeudet: Jos dataa on niin paljon, että se ei mahdu yhdelle palvelimelle, MongoDB tarjosi mekanismeja, jotka mahdollistavat sen skaalaamisen useille koneille.
- Monimutkaiset piirimuutokset: ei siirtoja! Relaatiotietokannassa tietokannan rakenteen muuttaminen voi olla valtava ongelma (varsinkin kun dataa on paljon). MongoDB on pystynyt yksinkertaistamaan prosessia huomattavasti. Ja teki siitä niin helppoa, että voit päivittää kaavion liikkeellä ollessasi ja jatkaa todella nopeasti.
- Kirjoita suorituskyky: MongoDB:n suorituskyky oli hyvä, varsinkin oikein viritettynä. Jopa MongoDB:n käyttövalmis kokoonpano, josta sitä usein kritisoitiin, osoitti vaikuttavia suorituskykylukuja.
Kaikki riskit ovat sinun
MongoDB:n mahdolliset hyödyt olivat valtavia, etenkin tietyissä ongelmaluokissa. Jos luet yllä olevan luettelon ymmärtämättä kontekstia ja sinulla ei ole kokemusta, saatat saada vaikutelman, että MongoDB on todella vallankumouksellinen DBMS. Ainoa ongelma oli, että yllä lueteltuihin etuihin sisältyi useita varoituksia, joista osa on lueteltu alla.
Ollakseni rehellinen, kukaan 10gen/MongoDB Inc. ei sano, että seuraava ei ole totta, nämä ovat vain kompromisseja.
- Liiketoimien menetysV: Tapahtumat ovat monien relaatiotietokantojen (ei kaikkien, mutta useimpien) ydinominaisuus. Transaktio tarkoittaa, että voit suorittaa useita toimintoja atomaarisesti ja varmistaa, että tiedot pysyvät johdonmukaisina. Tietenkin NoSQL-tietokannan kanssa tapahtumat voivat olla yksittäisen asiakirjan sisällä, tai voit käyttää kaksivaiheisia sitoumuksia saadaksesi tapahtumasemantiikan. Mutta sinun on otettava tämä toiminto käyttöön itse... mikä voi olla vaikea ja aikaa vievä tehtävä. Usein et ymmärrä ongelmaa ennen kuin näet tietokannan tietojen joutuvan virheellisiin tiloihin, koska on mahdotonta taata toimintojen atomiteettia. Huomautus: Monet ovat kertoneet minulle, että tapahtumat otettiin käyttöön MongoDB 4.0:ssa viime vuonna, mutta tietyin rajoituksin. Artikkelin johtopäätös pysyy samana: arvioi, kuinka tekniikka sopii tarpeisiisi.
- Suhteellisen eheyden menetys (vieraat avaimet): jos tiedoillasi on suhteita, sinun on käytettävä niitä sovelluksessa. Näitä suhteita kunnioittava tietokanta vie paljon työtä sovellukselta ja siten ohjelmoijoiltasi.
- Kyvyttömyys soveltaa tietorakennetta: Tiukat skeemat voivat joskus olla suuri ongelma, mutta ne ovat myös tehokas mekanismi hyvään tiedon strukturointiin, jos niitä käytetään viisaasti. Asiakirjatietokannat, kuten MongoDB, tarjoavat uskomattoman joustavuutta skeemoille, mutta tämä joustavuus vie vastuun tietojen pitämisestä puhtaana. Jos et huolehdi niistä, kirjoitat sovellukseesi paljon koodia ottaaksesi huomioon tiedot, joita ei ole tallennettu odottamassasi muodossa. Kuten yrityksessämme Simple Thread usein sanotaan… sovellus kirjoitetaan joskus uudelleen, mutta tiedot elävät ikuisesti. Huomautus: MongoDB tukee skeeman validointia, mikä on hyödyllistä, mutta ei tarjoa samoja takeita kuin relaatiotietokanta. Ensinnäkin skeeman vahvistuksen lisääminen tai muuttaminen ei vaikuta kokoelmassa oleviin tietoihin. Sinun on varmistettava, että päivität tiedot uuden skeeman mukaan. Päätä itse, riittääkö tämä tarpeisiisi.
- Oma kyselykieli / työkaluekosysteemin menetys: SQL:n tulo oli ehdoton vallankumous, eikä mikään ole muuttunut sen jälkeen. Se on uskomattoman voimakas kieli, mutta myös melko monimutkainen. Tarve rakentaa tietokantakyselyitä uudella kielellä, joka koostuu JSON-fragmenteista, on SQL:stä kokemusta omaavien mielestä iso askel taaksepäin. SQL-tietokantojen kanssa vuorovaikutuksessa olevia työkaluja on IDE:stä raportointityökaluihin. Siirtyminen tietokantaan, joka ei tue SQL:ää, tarkoittaa, että et voi käyttää useimpia näistä työkaluista tai sinun on muutettava tiedot SQL:ksi voidaksesi käyttää niitä, mikä voi olla vaikeampaa kuin uskotkaan.
Monet MongoDB:n puoleen kääntyneet kehittäjät eivät todellakaan ymmärtäneet kompromisseja ja sukelsivat usein päätä edellä asettamaan sen ensisijaiseksi tietovarastokseen. Sen jälkeen oli usein uskomattoman vaikeaa palata takaisin.
Mitä olisi voitu tehdä toisin?
Kaikki eivät hypänneet pää edellä ja törmäsivät pohjaan. Mutta monet projektit ovat asentaneet MongoDB-pohjan sinne, missä se ei yksinkertaisesti sopinut - ja heidän on elettävä sen kanssa vielä monta vuotta. Jos nämä organisaatiot olisivat pohtineet järjestelmällisesti teknologiavalintojaan, monet olisivat tehneet toisenlaisen valinnan.
Kuinka valita oikea tekniikka? Teknologian arvioinnille on yritetty luoda systemaattinen viitekehys useita kertoja mm и , mutta minusta tämä on tarpeeton monimutkaisuus.
Monia teknologioita voidaan arvostaa älykkäästi esittämällä vain kaksi peruskysymystä. Ongelmana on löytää ihmisiä, jotka voivat vastata niihin vastuullisesti, ottaa aikaa vastausten löytämiseen ja ilman ennakkoluuloja.
Jos sinulla ei ole ongelmia, et tarvitse uutta työkalua. Piste.
Kysymys 1: Mitä ongelmia yritän ratkaista?
Jos sinulla ei ole ongelmia, et tarvitse uutta työkalua. Piste. Ei tarvitse etsiä ratkaisua ja sitten keksiä ongelma. Jos et kohtaa ongelmaa, jota uusi tekniikka ei ratkaise merkittävästi paremmin kuin nykyinen tekniikkasi, täällä ei ole mitään keskusteltavaa. Jos harkitset tämän tekniikan käyttämistä, koska olet nähnyt muiden käyttävän sitä, mieti heidän ongelmiaan ja kysy, onko sinulla näitä ongelmia. Tekniikkaa on helppo omaksua, koska muut käyttävät sitä. Vaikeus on tietää, onko sinulla samat ongelmat.
Kysymys 2: Mitä minulta puuttuu?
Tämä on varmasti vaikeampi kysymys, koska sinun täytyy kaivaa ja ymmärtää sekä vanhaa että uutta tekniikkaa hyvin. Joskus et voi oikein ymmärtää uutta, ennen kuin olet rakentanut sen avulla jotain tai sinulla on kollega, jolla on samanlainen kokemus.
Jos sinulla ei ole kumpaakaan, on järkevää miettiä mahdollista vähimmäisinvestointia tämän instrumentin arvon määrittämiseksi. Ja jos teet sijoituksen, kuinka vaikeaa päätöstä on peruuttaa?
Ihmiset pilaavat aina kaiken
Kun yrität vastata näihin kysymyksiin mahdollisimman puolueettomasti, muista yksi asia: sinun on taisteltava ihmisluontoa vastaan. On olemassa useita kognitiivisia harhoja, jotka on voitettava, jotta teknologiaa voidaan arvioida tehokkaasti. Tässä vain muutamia:
- Kaikki tietävät hänestä, mutta häntä vastaan on silti vaikea taistella. Varmista vain, että tekniikka todella sopii todellisiin tarpeisiisi.
- Monilla kehittäjillä on taipumus aliarvioida teknologiaa, jonka kanssa he ovat työskennelleet pitkään, ja yliarvioivat uuden tekniikan hyödyt. Ei vain ohjelmoijat, vaan kaikki ovat tämän kognitiivisen harhan alaisia.
- Meillä on tapana nähdä, mikä on, ja unohtaa sen, mikä ei ole. Tämä voi johtaa kaaokseen yhdistettynä uutuusvaikutukseen, koska et pelkästään yliarvosta uutta teknologiaa, vaan myös sivuutat sen puutteet..
Objektiivinen arviointi ei ole helppoa, mutta taustalla olevien kognitiivisten harhojen ymmärtäminen auttaa sinua tekemään järkevämpiä päätöksiä.
Yhteenveto
Kun innovaatio ilmestyy, kahteen kysymykseen on vastattava erittäin huolellisesti:
- Ratkaiseeko tämä työkalu todellisen ongelman?
- Olemmeko hyviä ymmärtämään kompromisseja?
Jos et pysty vastaamaan varmuudella näihin kahteen kysymykseen, ota muutama askel taaksepäin ja mieti.
Joten oliko la MongoDB yleensä oikea valinta? Tietysti kyllä; Kuten useimmat tekniset tekniikat, se riippuu monista tekijöistä. Näihin kahteen kysymykseen vastanneista monet ovat hyötyneet MongoDB:stä ja tekevät niin edelleen. Niille teistä, jotka eivät ole, toivon, että olette oppineet arvokkaan ja ei liian tuskallisen oppitunnin hype-syklin läpi siirtymisestä.
Vastuuvapauslauseke
Haluan selventää, että en rakasta enkä vihaa MongoDB:tä. Meillä ei vain ollut sellaisia ongelmia, jotka MongoDB soveltuisi parhaiten ratkaisemaan. Tiedän, että 10gen/MongoDB Inc. toimi aluksi erittäin rohkeasti asettamalla epävarmoja oletuksia ja mainostaen MongoDB:tä kaikkialla (etenkin hackathoneissa) yhden luukun ratkaisuna minkä tahansa tiedon kanssa työskentelyyn. Se oli luultavasti huono päätös. Mutta se vahvistaa tässä kuvatun lähestymistavan: nämä ongelmat voidaan havaita hyvin nopeasti jopa pinnallisesti arvioimalla tekniikkaa.
Lähde: will.com