Dat fûn ik koartlyn (se sizze fanwege lisinsje feroarings). Dit krige my oan it tinken, om't ik de lêste jierren in ton artikels haw sjoen oer hoe ferskriklik MongoDB is en hoe't gjinien it oait moat brûke. Mar yn dizze tiid is MongoDB in folle mear folwoeksen produkt wurden. Wat is bard? Is alle haat echt te tankjen oan flaters yn 'e iere marketing fan in nije DBMS? Of brûke minsken gewoan MongoDB op 'e ferkearde plakken?
As jo fiele dat ik MongoDB ferdigenje, lês asjebleaft oan 'e ein fan it artikel.
Nije trend
Ik wurkje al mear jierren yn 'e software-yndustry dan ik kin sizze, mar ik bin noch mar bleatsteld oan in lyts part fan 'e trends dy't ús yndustry hawwe troffen. Ik haw tsjûge fan de opkomst fan 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... de list is einleaze. Alle jierren ferskine nije trends. Guon ferdwine fluch, wylst oaren de manier wêrop software wurdt ûntwikkele yn prinsipe feroarje.
Elke nije trend soarget foar in algemiene opwining: minsken springe oan board, of sjogge it lûd dat wurdt generearre troch oaren en folgje it publyk. Dit proses wurdt kodifisearre troch Gartner yn . Hoewol kontroversjeel, beskriuwt dizze tiidline rûchwei wat der bart mei technologyen foardat se úteinlik nuttich wurde.
Mar sa no en dan ferskynt in nije ynnovaasje (of hat in twadde komst, lykas yn dit gefal) dreaun troch mar ien spesifike ymplemintaasje. Yn it gefal fan NoSQL waard de hype swier oandreaun troch it ûntstean en meteoryske opkomst fan MongoDB. MongoDB begon dizze trend net: feitlik begon grutte ynternetbedriuwen problemen te hawwen mei it ferwurkjen fan grutte hoemannichten gegevens, wat late ta it weromkommen fan net-relasjonele databases. De algemiene beweging begon mei projekten lykas Google's Bigtable en Facebook's Cassandra, mar it wie MongoDB dy't de bekendste en tagonklikste NoSQL-database-ymplemintaasje waard wêr't de measte ûntwikkelders tagong ta hiene.
Opmerking: Jo kinne tinke dat ik dokumintdatabases betize mei kolomdatabases, kaai- / weardewinkels, of ien fan 'e ferskate oare soarten gegevenswinkels dy't falle ûnder de algemiene NoSQL-definysje. En do hast gelyk. Mar yn dy tiid hearske gaos. Elkenien is obsedearre mei NoSQL, it is elkenien wurden absolút nedich, hoewol't in protte net sjogge de ferskillen yn ferskillende technologyen. Foar in protte is MongoDB wurden synonym NoSQL.
En de ûntwikkelders sprongen derop. It idee fan in skemaleaze databank dy't magysk skalen om elk probleem op te lossen wie frijwat ferliedlik. Om 2014, it like dat oeral dat in jier lyn brûkte in relaasje databank lykas MySQL, Postgres of SQL Server begûn te ynsette MongoDB databases. As jo frege wêrom, kinne jo in antwurd krije fan it banale "dit is de skaal fan it web" nei it mear trochtochte "myn gegevens binne heul los strukturearre en passe goed yn in database sûnder skema."
It is wichtich om te betinken dat MongoDB, en dokumintdatabases yn 't algemien, in oantal problemen oplosse mei tradisjonele relationele databases:
- Strikt skema: Mei in relasjonele databank, as jo dynamysk oanmakke gegevens hawwe, binne jo twongen om of in boskje willekeurige "ferskate" kolommen mei gegevens te meitsjen, blêden fan gegevens deryn te skowen, of konfiguraasje te brûken ... dit alles hat wichtige neidielen.
- Swierrichheid skaalfergrutting: As d'r safolle gegevens binne dat it net op ien server past, biedt MongoDB meganismen om it te skaaljen oer meardere masines.
- Komplekse circuit modifikaasjes: gjin migraasjes! Yn in relationele databank kin it feroarjen fan de databankstruktuer in enoarm probleem wêze (benammen as d'r in protte gegevens binne). MongoDB koe it proses sterk ferienfâldigje. En it makke it sa maklik dat jo it sirkwy gewoan bywurkje kinne as jo trochgean en heul snel trochgean.
- Opname prestaasjes: MongoDB-prestaasjes wiene goed, benammen as goed ynsteld. Sels de out-of-the-box-konfiguraasje fan MongoDB, wêrfoar't it faak bekritisearre waard, liet wat yndrukwekkende prestaasjesnûmers sjen.
Alle risiko's binne op jo
De potinsjele foardielen fan MongoDB wiene enoarm, foaral foar bepaalde klassen fan problemen. As jo de boppesteande list lêze sûnder de kontekst te begripen en sûnder ûnderfining, kinne jo de yndruk krije dat MongoDB wirklik in revolúsjonêre DBMS is. It ienige probleem wie dat de hjirboppe neamde foardielen kamen mei in oantal warskôgings, wêrfan guon hjirûnder steane.
Om earlik te wêzen, gjinien by 10gen/MongoDB Inc. sil net sizze dat it folgjende net wier is, dit binne gewoan kompromissen.
- Ferlern transaksjes: Transaksjes binne in kearnfunksje fan in protte relasjonele databases (net allegear, mar de measte). Transaksje betsjut dat jo meardere operaasjes atomysk kinne útfiere en kinne derfoar soargje dat de gegevens konsekwint bliuwe. Fansels, mei in NoSQL-database, kin transaksjonaliteit binnen ien dokumint wêze, of jo kinne twa-faze-commits brûke om transaksje-semantyk te krijen. Mar jo moatte dizze funksjonaliteit sels implementearje ... wat in drege en tiidslinende taak kin wêze. Faak realisearje jo net dat d'r in probleem is oant jo sjogge dat de gegevens yn 'e databank yn ûnjildige steaten einigje, om't de atomiteit fan operaasjes net garandearre wurde kin. Opmerking: In protte minsken fertelden my dat MongoDB 4.0 ferline jier transaksjes yntrodusearre, mar mei wat beheiningen. De takeaway fan it artikel bliuwt itselde: evaluearje hoe goed de technology foldocht oan jo behoeften.
- Ferlies fan relaasje yntegriteit (bûtenlânske kaaien): As jo gegevens relaasjes hawwe, dan moatte jo se tapasse yn 'e applikaasje. In databank hawwe dy't dizze relaasjes respektearret, sil in protte wurk fan 'e applikaasje nimme en dus jo programmeurs.
- Gebrek oan fermogen om gegevensstruktuer oan te passen: Strikte skema's kinne soms in grut probleem wêze, mar se binne ek in krêftich meganisme foar goede datastrukturearring as se ferstannich brûkt wurde. Dokumintdatabases lykas MongoDB jouwe ongelooflijke skemafleksibiliteit, mar dizze fleksibiliteit ferwideret de ferantwurdlikens foar it skjinhâlden fan de gegevens. As jo der net foar soargje, sille jo úteinlik in protte koade yn jo applikaasje skriuwe om rekken te hâlden mei gegevens dy't net wurde opslein yn 'e foarm dy't jo ferwachtsje. Lykas wy faaks sizze by ús bedriuw Simple Thread ... sil de applikaasje ienris wurde herskreaun, mar de gegevens sille foar altyd libje. Opmerking: MongoDB stipet skema-kontrôle: it is nuttich, mar jout net deselde garânsjes as yn in relasjonele databank. Earst fan alles, it tafoegjen of feroarjen fan in skemakontrôle hat gjin ynfloed op besteande gegevens yn 'e kolleksje. It is oan jo om te soargjen dat jo de gegevens bywurkje neffens it nije skema. Beslute sels oft dit genôch is foar jo behoeften.
- Native query taal / ferlies fan ark-ekosysteem: De komst fan SQL wie in absolute revolúsje en neat is sûnt doe feroare. It is in ûnbidich krêftige taal, mar ek frij kompleks. De needsaak om databankfragen te konstruearjen yn in nije taal besteande út JSON-fragminten wurdt beskôge as in grutte stap efterút troch minsken dy't ûnderfining hawwe mei wurkjen mei SQL. D'r is in hiel universum fan ark dat ynteraksje mei SQL-databases, fan IDE's oant rapportaazjeark. Ferhúzje nei in databank dy't SQL net stipet betsjut dat jo de measte fan dizze ark net kinne brûke of jo moatte de gegevens oersette yn SQL om se te brûken, wat dreger kin wêze dan jo tinke.
In protte ûntwikkelders dy't har wenden nei MongoDB, begrepen de ôfwikselingen net echt, en dûken faak earst yn 'e ynstallaasje as har primêre gegevenswinkel. Dêrnei wie it faaks ûnbidich lestich om werom te kommen.
Wat koe der oars dien wurde?
Net elkenien sprong mei de kop en sloech de boaiem. Mar in protte projekten hawwe MongoDB ynstalleare op plakken wêr't it gewoan net paste - en se sille der in protte jierren mei moatte libje. As dizze organisaasjes wat tiid hiene trochbrocht en metodysk troch har technologyske karren tocht, soene in protte oare karren makke hawwe.
Hoe kinne jo de juste technology kieze? Der binne ferskate pogingen west om in systematysk ramt te meitsjen foar technologybeoardieling, lykas и , mar it liket my ta dat dit ûnnedige kompleksiteit is.
In protte technologyen kinne yntelligint wurde beoardiele troch mar twa basisfragen te stellen. It probleem is minsken te finen dy't har ferantwurde kinne beäntwurdzje, de tiid nimme om de antwurden te finen en sûnder bias.
As jo gjin probleem hawwe, hawwe jo gjin nij ark nedich. Dot.
Fraach 1: Hokker problemen besykje ik op te lossen?
As jo gjin probleem hawwe, hawwe jo gjin nij ark nedich. Dot. It is net nedich om nei in oplossing te sykjen en dan in probleem út te finen. Behalven as jo in probleem hawwe tsjinkaam dat de nije technology signifikant better oplost dan jo besteande technology, is d'r hjir neat te besprekken. As jo beskôgje om dizze technology te brûken om't jo oaren hawwe sjoen dat se brûke, tink dan oer hokker problemen se hawwe en freegje as jo dizze problemen hawwe. It is maklik om in technology te akseptearjen, om't oaren it brûke, de útdaging is te begripen oft jo deselde problemen hawwe.
Fraach 2: Wat mis ik?
Dit is perfoarst in dreger fraach, om't jo moatte grave yn en hawwe in goed begryp fan sawol de âlde en nije technology. Soms kinne jo in nije net echt begripe oant jo der wat mei boud hawwe of ien hawwe mei dy ûnderfining.
As jo gjin beide hawwe, dan makket it sin om te tinken oer de minimale mooglike ynvestearring om de wearde fan dit ynstrumint te bepalen. En as jo ienris de ynvestearring meitsje, hoe lestich sil it wêze om it beslút werom te kearen?
Minsken ferneatigje altyd alles
As jo besykje dizze fragen sa ûnpartidich mooglik te beantwurdzjen, tink dan oan ien ding: jo sille de minsklike natuer moatte fjochtsje. D'r binne in oantal kognitive foaroardielen dy't moatte wurde oerwûn om technology effektyf te evaluearjen. Hjir binne mar in pear:
- - elkenien wit fan him, mar it is noch altyd lestich om him te fjochtsjen. Soargje derfoar dat de technology wirklik oerienkomt mei jo eigentlike behoeften.
- - In protte ûntwikkelders hawwe de neiging om technologyen te ûnderskatten wêrmei't se in lange tiid hawwe wurke en de foardielen fan nije technology te oerskatte. It binne net allinich programmeurs, elkenien is gefoelich foar dizze kognitive bias.
- - Wy binne oanstriid om te sjen wat der is en ferlieze út it each wat der mist. Dit kin liede ta gaos yn kombinaasje mei it nije effekt, om't jo nije technology net allinich ynherent oerwurdearje, mar ek har tekoarten negearje.
Objektive beoardieling is net maklik, mar it begripen fan 'e ûnderlizzende kognitive foaroardielen sil jo helpe om mear rasjonele besluten te meitsjen.
Gearfetting
Wannear't in ynnovaasje ferskynt, moatte twa fragen mei grutte soarch beantwurde wurde:
- Lost dit ark in echt probleem op?
- Begripe wy de ôfwikselingen goed?
As jo dizze twa fragen net mei fertrouwen kinne beantwurdzje, nim dan in pear stappen werom en tink.
Dat wie MongoDB sels de juste kar? Fansels ja; Lykas by de measte technyske technologyen, hinget dit ôf fan in protte faktoaren. Under dejingen dy't dizze twa fragen beantwurde, hawwe in protte profitearre fan MongoDB en trochgean mei te dwaan. Foar dyjingen dy't dat net diene, hoopje ik dat jo in weardefolle en net te pynlike les hawwe leard oer it bewegen troch de hype-syklus.
Disclaimer
Ik wol dúdlik meitsje dat ik gjin leafde noch in haatrelaasje haw mei MongoDB. Wy hawwe gewoan net it soarte problemen hân dy't MongoDB it bêste is om op te lossen. Ik wit dat 10gen / MongoDB Inc. wie yn 't earstoan heul fet, sette ûnfeilige standerts en befoardere MongoDB oeral (benammen by hackathons) as in universele oplossing foar wurkjen mei alle gegevens. It wie wierskynlik in min beslút. Mar it befêstiget de hjir beskreaune oanpak: dizze problemen kinne heul snel wurde ûntdutsen, sels mei in oerflakkige beoardieling fan 'e technology.
Boarne: www.habr.com