Daar kwam ik onlangs achter (ze zeggen vanwege licentiewijzigingen). Dit zette me aan het denken, omdat ik de afgelopen jaren heel veel artikelen heb gezien over hoe verschrikkelijk MongoDB is en hoe niemand het ooit zou moeten gebruiken. Maar gedurende deze tijd is MongoDB een veel volwassener product geworden. Wat is er gebeurd? Is alle haat werkelijk te wijten aan fouten bij het op de markt brengen van een nieuw DBMS? Of gebruiken mensen MongoDB gewoon op de verkeerde plaatsen?
Als je het gevoel hebt dat ik MongoDB verdedig, lees dan alsjeblieft aan het einde van het artikel.
Nieuwe trend
Ik werk al meer jaren in de software-industrie dan ik kan zeggen, maar ik ben nog steeds slechts blootgesteld aan een klein deel van de trends die onze branche hebben getroffen. Ik ben getuige geweest van de opkomst van 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... de lijst is eindeloos. Elk jaar verschijnen er nieuwe trends. Sommige verdwijnen snel, terwijl andere de manier waarop software wordt ontwikkeld fundamenteel veranderen.
Elke nieuwe trend zorgt voor algemene opwinding: mensen springen aan boord, of zien het lawaai van anderen en volgen de menigte. Dit proces is gecodificeerd door Gartner in . Hoewel controversieel, beschrijft deze tijdlijn grofweg wat er met technologieën gebeurt voordat ze uiteindelijk bruikbaar worden.
Maar van tijd tot tijd verschijnt er een nieuwe innovatie (of komt er een tweede op komst, zoals in dit geval), gedreven door slechts één specifieke implementatie. In het geval van NoSQL werd de hype sterk gedreven door de opkomst en snelle opkomst van MongoDB. MongoDB heeft deze trend niet ingezet: in feite begonnen grote internetbedrijven problemen te krijgen met het verwerken van grote hoeveelheden gegevens, wat leidde tot de terugkeer van niet-relationele databases. De algemene beweging begon met projecten als Google's Bigtable en Facebook's Cassandra, maar het was MongoDB die de meest bekende en toegankelijke NoSQL-database-implementatie werd waartoe de meeste ontwikkelaars toegang hadden.
Opmerking: u denkt misschien dat ik documentdatabases verwar met kolomvormige databases, sleutel/waarde-opslagplaatsen of een van de vele andere soorten gegevensopslagplaatsen die onder de algemene NoSQL-definitie vallen. En je hebt gelijk. Maar op dat moment heerste er chaos. Iedereen is geobsedeerd door NoSQL, het is iedereen geworden absoluut noodzakelijk, hoewel velen de verschillen tussen de verschillende technologieën niet zagen. Voor velen is MongoDB een geworden synoniem met GeenSQL.
En de ontwikkelaars stortten zich erop. Het idee van een schemaloze database die op magische wijze kan worden geschaald om elk probleem op te lossen, was behoorlijk verleidelijk. Rond 2014 leek het erop dat overal waar een jaar geleden een relationele database zoals MySQL, Postgres of SQL Server werd gebruikt, MongoDB-databases werden ingezet. Op de vraag waarom, kun je een antwoord krijgen van het banale ‘dit is de schaal van het internet’ tot het meer doordachte ‘mijn gegevens zijn heel losjes gestructureerd en passen goed in een database zonder schema’.
Het is belangrijk om te onthouden dat MongoDB, en documentdatabases in het algemeen, een aantal problemen met traditionele relationele databases oplossen:
- Strenge regeling: Met een relationele database wordt u, als u dynamisch gegenereerde gegevens heeft, gedwongen om ofwel een aantal willekeurige "diverse" gegevenskolommen aan te maken, daar klodders gegevens in te stoppen, of configuratie te gebruiken ...dit alles heeft aanzienlijke nadelen.
- Moeilijkheden bij het schalen: Als er zoveel gegevens zijn dat deze niet op één server passen, bood MongoDB mechanismen aan waarmee deze over meerdere machines konden worden geschaald.
- Complexe circuitwijzigingen: geen migraties! In een relationele database kan het veranderen van de databasestructuur een groot probleem zijn (vooral als er veel gegevens zijn). MongoDB kon het proces aanzienlijk vereenvoudigen. En het maakte het zo gemakkelijk dat je het circuit gewoon onderweg kunt bijwerken en heel snel verder kunt gaan.
- Prestaties opnemen: MongoDB-prestaties waren goed, vooral als ze correct waren geconfigureerd. Zelfs de kant-en-klare configuratie van MongoDB, waarvoor deze vaak werd bekritiseerd, liet indrukwekkende prestatiecijfers zien.
Alle risico's zijn voor u
De potentiële voordelen van MongoDB waren enorm, vooral voor bepaalde soorten problemen. Als u de bovenstaande lijst leest zonder de context en zonder ervaring te begrijpen, krijgt u mogelijk de indruk dat MongoDB echt een revolutionair DBMS is. Het enige probleem was dat de hierboven genoemde voordelen een aantal kanttekeningen met zich meebrachten, waarvan er enkele hieronder worden vermeld.
Om eerlijk te zijn: niemand bij 10gen/MongoDB Inc. zal niet zeggen dat het volgende niet waar is; dit zijn slechts compromissen.
- Verloren transacties: Transacties zijn een kernkenmerk van veel relationele databases (niet alle, maar de meeste). Transactioneel betekent dat u meerdere bewerkingen atomair kunt uitvoeren en ervoor kunt zorgen dat de gegevens consistent blijven. Met een NoSQL-database kan de transactionaliteit uiteraard binnen één enkel document plaatsvinden, of u kunt commits in twee fasen gebruiken om transactionele semantiek te verkrijgen. Maar u zult deze functionaliteit zelf moeten implementeren... wat een moeilijke en tijdrovende klus kan zijn. Vaak beseft u pas dat er een probleem is als u ziet dat de gegevens in de database in een ongeldige status terechtkomen, omdat de atomiciteit van de bewerkingen niet kan worden gegarandeerd. Opmerking: veel mensen vertelden me dat MongoDB 4.0 vorig jaar transacties introduceerde, maar met enkele beperkingen. De conclusie van het artikel blijft hetzelfde: evalueer hoe goed de technologie aan uw behoeften voldoet.
- Verlies van relationele integriteit (vreemde sleutels): Als uw gegevens relaties hebben, moet u deze in de applicatie toepassen. Het hebben van een database die deze relaties respecteert, zal een groot deel van het werk van de applicatie en dus van uw programmeurs wegnemen.
- Gebrek aan vermogen om datastructuur toe te passen: Strenge schema's kunnen soms een groot probleem zijn, maar ze zijn ook een krachtig mechanisme voor een goede gegevensstructurering als ze verstandig worden gebruikt. Documentdatabases zoals MongoDB bieden ongelooflijke schemaflexibiliteit, maar deze flexibiliteit neemt de verantwoordelijkheid voor het schoonhouden van de gegevens weg. Als u er niet voor zorgt, schrijft u uiteindelijk veel code in uw toepassing om rekening te houden met gegevens die niet zijn opgeslagen in de vorm die u verwacht. Zoals we vaak zeggen bij ons bedrijf Simple Thread... zal de applicatie ooit herschreven worden, maar de gegevens zullen voor altijd blijven bestaan. Opmerking: MongoDB ondersteunt schemacontrole: het is nuttig, maar biedt niet dezelfde garanties als in een relationele database. Allereerst heeft het toevoegen of wijzigen van een schemacontrole geen invloed op bestaande gegevens in de collectie. Het is aan u om ervoor te zorgen dat u de gegevens bijwerkt volgens het nieuwe schema. Bepaal zelf of dit voldoende is voor uw behoeften.
- Native querytaal / verlies van tool-ecosysteem: De komst van SQL was een absolute revolutie en sindsdien is er niets veranderd. Het is een ongelooflijk krachtige taal, maar ook behoorlijk complex. De noodzaak om databasequery's te construeren in een nieuwe taal bestaande uit JSON-fragmenten wordt door mensen die ervaring hebben met het werken met SQL als een grote stap achteruit beschouwd. Er is een heel universum aan tools die samenwerken met SQL-databases, van IDE's tot rapportagetools. Als u overschakelt naar een database die SQL niet ondersteunt, betekent dit dat u de meeste van deze tools niet kunt gebruiken of dat u de gegevens naar SQL moet vertalen om ze te kunnen gebruiken, wat moeilijker kan zijn dan u denkt.
Veel ontwikkelaars die zich tot MongoDB wendden, begrepen de afwegingen niet echt en doken er vaak meteen in om het als hun primaire gegevensopslag te installeren. Hierna was het vaak ontzettend moeilijk om terug te komen.
Wat had anders gedaan kunnen worden?
Niet iedereen sprong met zijn hoofd naar voren en raakte de bodem. Maar bij veel projecten is MongoDB geïnstalleerd op plaatsen waar het eenvoudigweg niet paste - en ze zullen er nog vele jaren mee moeten leven. Als deze organisaties wat tijd hadden besteed aan het methodisch doordenken van hun technologische keuzes, zouden velen andere keuzes hebben gemaakt.
Hoe kies je de juiste technologie? Er zijn verschillende pogingen ondernomen om een systematisch raamwerk voor technologiebeoordeling te creëren, zoals и , maar het lijkt mij dat dit onnodige complexiteit is.
Veel technologieën kunnen op intelligente wijze worden beoordeeld door slechts twee basisvragen te stellen. Het probleem is het vinden van mensen die deze op verantwoorde wijze kunnen beantwoorden, de tijd nemen om de antwoorden te vinden en zonder vooringenomenheid.
Als u geen enkel probleem ondervindt, heeft u geen nieuw gereedschap nodig. Punt.
Vraag 1: Welke problemen probeer ik op te lossen?
Als u geen enkel probleem ondervindt, heeft u geen nieuw gereedschap nodig. Punt. Het is niet nodig om naar een oplossing te zoeken en dan een probleem te bedenken. Tenzij u een probleem bent tegengekomen dat de nieuwe technologie aanzienlijk beter oplost dan uw bestaande technologie, valt hier niets te bespreken. Als u overweegt deze technologie te gebruiken omdat u anderen deze hebt zien gebruiken, overweeg dan met welke problemen zij worden geconfronteerd en vraag of u die problemen heeft. Het is gemakkelijk om een technologie te accepteren omdat anderen deze gebruiken. De uitdaging is om te begrijpen of u met dezelfde problemen wordt geconfronteerd.
Vraag 2: Wat mis ik?
Dit is absoluut een moeilijkere vraag, omdat je je zult moeten verdiepen en een goed begrip moet hebben van zowel de oude als de nieuwe technologie. Soms kun je een nieuwe pas echt begrijpen als je er iets mee hebt gebouwd of iemand hebt met die ervaring.
Als u geen van beide heeft, is het verstandig om na te denken over de minimaal mogelijke investering om de waarde van dit instrument te bepalen. En als u eenmaal de investering heeft gedaan, hoe moeilijk zal het dan zijn om de beslissing terug te draaien?
Mensen verpesten altijd alles
Terwijl u deze vragen zo onpartijdig mogelijk probeert te beantwoorden, moet u één ding onthouden: u zult de menselijke natuur moeten bestrijden. Er zijn een aantal cognitieve vooroordelen die moeten worden overwonnen om technologie effectief te kunnen evalueren. Hier zijn er maar een paar:
- - iedereen kent hem, maar het is nog steeds moeilijk om met hem te vechten. Zorg ervoor dat de technologie daadwerkelijk aansluit bij uw werkelijke behoeften.
- — Veel ontwikkelaars hebben de neiging de technologieën waarmee ze al heel lang werken te onderschatten en de voordelen van nieuwe technologie te overschatten. Het zijn niet alleen programmeurs, iedereen is vatbaar voor deze cognitieve bias.
- - We hebben de neiging om te zien wat er is en uit het oog te verliezen wat er ontbreekt. Dit kan tot chaos leiden als je het combineert met het nieuwigheidseffect, omdat je nieuwe technologie niet alleen inherent overwaardeert, maar ook de tekortkomingen ervan negeert.
Objectieve beoordeling is niet eenvoudig, maar als u de onderliggende cognitieve vooroordelen begrijpt, kunt u rationelere beslissingen nemen.
Beknopt
Wanneer er een innovatie verschijnt, moeten twee vragen met grote zorg worden beantwoord:
- Lost deze tool een echt probleem op?
- Begrijpen we de afwegingen goed?
Als u deze twee vragen niet met vertrouwen kunt beantwoorden, doe dan een paar stappen terug en denk na.
Dus was MongoDB wel de juiste keuze? Natuurlijk; Zoals bij de meeste technische technologieën is dit van veel factoren afhankelijk. Onder degenen die deze twee vragen hebben beantwoord, hebben velen geprofiteerd van MongoDB en blijven dat doen. Voor degenen die dat niet hebben gedaan: ik hoop dat je een waardevolle en niet al te pijnlijke les hebt geleerd over het doorstaan van de hype-cyclus.
Disclaimer
Ik wil duidelijk maken dat ik noch een liefdes- noch een haatrelatie heb met MongoDB. We hebben gewoon niet het soort problemen gehad dat MongoDB het meest geschikt is om op te lossen. Ik weet dat 10gen/MongoDB Inc. was in het begin erg stoutmoedig, stelde onveilige standaardinstellingen in en promootte MongoDB overal (vooral op hackathons) als een universele oplossing voor het werken met welke gegevens dan ook. Het was waarschijnlijk een slechte beslissing. Maar het bevestigt de hier beschreven aanpak: deze problemen konden zeer snel worden opgespoord, zelfs met een oppervlakkige beoordeling van de technologie.
Bron: www.habr.com