Onlangs ontdekte ik dat Red Hat de ondersteuning voor MongoDB uit Satellite verwijdert (het schijnt vanwege veranderingen in de licentie). Dit heeft me aan het denken gezet, want de afgelopen jaren heb ik een heleboel artikelen gezien over hoe verschrikkelijk MongoDB is en dat niemand het ooit zou moeten gebruiken. Maar in die tijd is MongoDB een veel volwassener product geworden. Wat is er gebeurd? Is alle haat echt het gevolg van fouten in het begin van de marketing van deze nieuwe DBMS? Of gebruiken mensen MongoDB gewoon niet daar waar het nodig is?

Als je denkt dat ik MongoDB verdedig, lees dan alsjeblieft de disclaimer aan het einde van het artikel.

Nieuwe trend

Ik werk al jaren in de software-industrie, meer dan je fatsoenlijk kunt zeggen, maar ik heb slechts een klein deel van de trends meegemaakt die onze sector hebben getroffen. Ik heb de opkomst van 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... gezien; de lijst is eindeloos. Elk jaar verschijnen er nieuwe tendensen. Sommige doven snel uit, terwijl anderen de manier waarop software wordt ontwikkeld, fundamenteel veranderen.

Rond elke nieuwe trend ontstaat enige opwinding: mensen springen zelf in de boot of zien de ruis die anderen veroorzaken – en volgen de menigte. Dit proces is gecodificeerd door Gartner in de hypecyclus. Hoewel het omstreden is, beschrijft deze grafiek ongeveer wat er met technologieën gebeurt voordat ze uiteindelijk nuttig worden.

Maar af en toe verschijnt er (of is er een tweede komst, zoals in dit geval) een nieuwe innovatie, aangedreven door een specifieke implementatie. In het geval van NoSQL was de hype sterk bepaald door de introductie en snelle opkomst van MongoDB. Het was niet MongoDB die deze trend lanceerde: in feit, grote internetbedrijven ondervonden problemen met het verwerken van grote hoeveelheden gegevens, wat leidde tot de terugkeer van niet-relationele databases. De algemene beweging begon met projecten zoals Bigtable van Google en Cassandra van Facebook, maar het was juist MongoDB die de meest bekende en toegankelijke implementatie van een NoSQL-database werd, waar de meeste ontwikkelaars toegang toe hadden.

Opmerking: je zou kunnen denken dat ik documentgebaseerde databases meng met kolomgebaseerde databases, key/value-opslag of een van de vele andere types gegevensopslag die onder de algemene definitie van NoSQL vallen. En je hebt gelijk. Maar in die tijd was er chaos. Iedereen was geobsedeerd door NoSQL. absoluut noodzakelijk, hoewel velen de verschillen tussen de verschillende technologieën niet hebben gezien. Voor velen is MongoDB een synoniem voor NoSQL.

Ontwikkelaars sprongen erop af. Het idee van een schema-loze database die magisch opschaalt om elk probleem op te lossen, was behoorlijk verleidelijk. Rond 2014 leek het wel alsof overal waar een jaar geleden nog een relationele database werd gebruikt, zoals MySQL, Postgres of SQL Server, nu MongoDB-databases werden uitgerold. Op de vraag waarom, kon je antwoorden krijgen variërend van het simpele 'dat is de schaal van het web' tot een meer doordachte 'mijn gegevens zijn erg slecht gestructureerd en passen goed in een schema-loze database'.

Het is belangrijk om te onthouden dat MongoDB en documentdatabases in het algemeen een aantal problemen met traditionele relationele databases oplossen:

Strikte schema: met een relationele database, als je dynamisch gegenereerde gegevens hebt, ben je gedwongen om een hoop willekeurige 'verschillende' datacolumns te creëren, daarin blobs van gegevens te proppen of een configuratie te gebruiken EAV… dit alles heeft aanzienlijke nadelen.
Schaalproblemen: als de gegevens zo talrijk zijn dat ze niet op één server passen, bood MongoDB mechanismen die het mogelijk maakten om ze over meerdere machines te schalen.
Complexe schemawijzigingen: geen migraties! Bij een relationele database kan het veranderen van de database-structuur een enorm probleem worden (vooral wanneer er veel gegevens zijn). MongoDB heeft dit proces aanzienlijk vereenvoudigd. Het was zo makkelijk dat je gewoon het schema on-the-fly kunt bijwerken en heel snel verder kunt gaan.
Schrijfprestaties: de prestaties van MongoDB waren goed, vooral met de juiste configuratie. Zelfs de standaardconfiguratie van MongoDB, waarvoor het vaak bekritiseerd werd, toonde enkele indrukwekkende prestaties.

Alle risico's zijn voor jou

De potentiële voordelen van MongoDB waren enorm, vooral voor bepaalde klassen van problemen. Als je de bovenstaande lijst leest zonder de context te begrijpen en zonder ervaring, kan de indruk ontstaan dat MongoDB echt een revolutionaire DBMS is. Het enige probleem was dat de hierboven genoemde voordelen gepaard gingen met een aantal voorbehouden, waarvan sommige hieronder worden vermeld.

Terwijl we eerlijk moeten zijn, zal niemand bij 10gen/MongoDB Inc. zeggen dat wat volgt onwaar is, het zijn gewoon compromissen.

Verlies van transacties: transacties zijn een van de belangrijkste kenmerken van veel relationele databases (niet allemaal, maar de meeste). Transacties betekenen dat je meerdere bewerkingen atomair kunt uitvoeren en kunt garanderen dat de gegevens consistent blijven. Natuurlijk kan in een NoSQL-database de transactionaliteit zich binnen één document bevinden, of je kunt tweefasige commits gebruiken om transactionele semantiek te verkrijgen. Maar je moet deze functionaliteit zelf implementeren... wat een complexe en tijdrovende taak kan zijn. Vaak realiseer je je de problemen pas als je ziet dat gegevens in de database in ongeldig toestanden terechtkomen, omdat je de atomiciteit van bewerkingen niet kunt garanderen. Opmerking: velen hebben me verteld dat er vorig jaar in MongoDB 4.0 transacties zijn verschenen, maar met verschillende beperkingen. De conclusie van het artikel blijft hetzelfde: beoordeel in hoeverre de technologie aan jouw behoeften voldoet.
Verlies van relationele integriteit (buitenlandse sleutels): als er relaties in jouw gegevens zijn, moet je ze in de applicatie toepassen. Een database die aan deze relaties voldoet, vermindert aanzienlijk de hoeveelheid werk voor de applicatie en dus voor je programmeurs.
Het ontbreken van de mogelijkheid om een datastructuur toe te passen: strikte schema's kunnen soms een groot probleem zijn, maar ze zijn ook een krachtig mechanisme voor goede gegevensstructurering, mits correct gebruikt. Documentdatabases zoals MongoDB bieden een ongelooflijke flexibiliteit in schema's, maar deze flexibiliteit neemt de verantwoordelijkheid weg voor het behoud van gegevens in een schone toestand. Als je hier niet op let, moet je uiteindelijk veel code in de applicatie schrijven om rekening te houden met gegevens die niet in de verwachte vorm zijn opgeslagen. Zoals vaak wordt gezegd in ons bedrijf Simple Thread... de applicatie zal ooit herschreven worden, maar de gegevens zullen voor altijd leven. Opmerking: MongoDB ondersteunt schema-verificatie: het is nuttig, maar biedt niet dezelfde garanties als in een relationele database. Bovenal heeft het toevoegen of wijzigen van schema-verificatie geen invloed op bestaande gegevens in de collectie. U moet zelf controleren of u de gegevens bijwerkt volgens het nieuwe schema. Bepaal zelf of dit voldoende is voor uw behoeften.
Eigen querytaal / verlies van ecosysteem van hulpmiddelen: De opkomst 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 databasequeries te construeren in een nieuwe taal, bestaande uit JSON-fragmenten, wordt door mensen met ervaring in SQL als een grote stap terug gezien. Er bestaat een hele universum van tools die interageren met SQL-databases: van IDE's tot rapportage-instrumenten. Overstappen naar een database die geen SQL ondersteunt, betekent dat u de meeste van deze tools niet kunt gebruiken of dat u gegevens naar SQL moet vertalen om ze te kunnen gebruiken, wat moeilijker kan zijn dan u denkt.

Veel ontwikkelaars die overstapten naar MongoDB, begrepen de compromissen niet goed en duikten vaak met beide voeten in het diepe door het als de primaire gegevensopslag te installeren. Na zo'n stap was het vaak ongelooflijk moeilijk om terug te keren.

Wat had anders gedaan kunnen worden?

Niet iedereen sprong met het hoofd vooruit en botste op de bodem. Maar veel projecten installeerden MongoDB daar waar het simpelweg niet geschikt was - en ze zullen er nog vele jaren mee moeten leven. Als deze organisaties enige tijd hadden besteed aan het methodisch overwegen van hun technologische keuzes, zouden velen een andere keuze hebben gemaakt.

Hoe kies je de juiste technologie? Er zijn verschillende pogingen gedaan om een systematisch kader voor het evalueren van technologieën te creëren, zoals ‘Kader voor het implementeren van technologieën in softwareorganisaties’ en ‘Kader voor het evalueren van softwaretechnologieën’, maar ik denk dat dit te complex is.

Veel technologieën kunnen redelijk worden geëvalueerd door slechts twee basisvragen te stellen. Het probleem ligt in het vinden van mensen die er verantwoordelijk op kunnen antwoorden, tijd besteden aan het zoeken naar antwoorden en zonder vooringenomenheid.

Als u niet met een probleem wordt geconfronteerd, heeft u geen nieuw hulpmiddel nodig. Punt.

Vraag 1: Welke problemen probeer ik op te lossen?

Als je niet met een probleem wordt geconfronteerd, heb je geen nieuw hulpmiddel nodig. Punt. Zoek niet naar een oplossing en verzin dan een probleem. Als je niet geconfronteerd bent met een probleem dat een nieuwe technologie aanzienlijk beter oplost dan je bestaande technologie, is er hier niets te bespreken. Als je overweegt deze technologie te gebruiken omdat je anderen het hebt zien gebruiken, denk dan na over de problemen waarmee zij worden geconfronteerd en vraag jezelf af of jij soortgelijke problemen hebt. Het is gemakkelijk om een technologie te omarmen omdat anderen dat doen, de moeilijkheid ligt in het begrijpen of jij dezelfde problemen hebt.

Vraag 2: Waarvoor moet ik opofferen?

Dit is zeker een moeilijker vraag, omdat je moet graven en goed moet begrijpen zowel de oude als de nieuwe technologie. Soms kun je een nieuwe technologie niet echt begrijpen totdat je er iets mee hebt gebouwd of je hebt een medewerker met die ervaring.

Als je geen van beide hebt, is het logisch om na te denken over de minimaal mogelijke investeringen om de waarde van dit hulpmiddel te bepalen. En als je investeringen doet, hoe moeilijk zal het dan zijn om de beslissing terug te draaien?

Mensen verpesten altijd alles

Probeer deze vragen zo objectief mogelijk te beantwoorden, houd één ding in gedachten: je zult moeten vechten tegen de menselijke natuur. Er zijn verschillende cognitieve bias die overwonnen moeten worden om technologie effectief te kunnen beoordelen. Hier zijn er een paar:

Het bandwagon-effect — iedereen weet ervan, maar het blijft moeilijk om mee om te gaan. Zorg er simpelweg voor dat de technologie echt aan jouw reële behoeften voldoet.
Het nieuwigheidseffect — veel ontwikkelaars hebben de neiging om technologieën die ze al langere tijd gebruiken te onderschatten en de voordelen van nieuwe technologie te overschatten. Niet alleen programmeurs, iedereen is gevoelig voor deze cognitieve bias.
Het positieve eigenschapseffect — we hebben de neiging om te zien wat er is en we missen wat er niet is. Dit kan leiden tot chaos in combinatie met het nieuwigheidseffect, omdat je niet alleen de nieuwe technologie van nature overschat, maar ook haar tekortkomingen negeert..

Objectieve evaluatie is niet eenvoudig, maar inzicht in de belangrijkste cognitieve biases kan helpen om rationelere beslissingen te nemen.

Samenvatting

Wanneer een nieuwe innovatie verschijnt, moet je met veel voorzichtigheid op twee vragen antwoorden:

Lost dit instrument een echt probleem op?
Begrijpen we de compromissen goed?

Als je niet met vertrouwen op deze twee vragen kunt antwoorden, neem dan een paar stappen terug en denk na.

Was MongoDB überhaupt de juiste keuze? Uiteraard; zoals bij de meeste engineeringtechnologieën, hangt dit van veel factoren af. Velen die deze twee vragen beantwoord hebben, hebben voordeel gehaald uit MongoDB en blijven dat doen. Degenen die dat niet deden, hoop ik, hebben een waardevolle en niet al te pijnlijke les geleerd over het navigeren door de hypecyclus.

Disclaimer

Ik wil opmerken dat ik geen liefde of haat heb voor MongoDB. We hadden gewoon geen problemen waarvoor MongoDB de meest geschikte oplossing bood. Ik weet dat 10gen/MongoDB Inc. aanvankelijk zeer gedurfd handelde door onveilige standaardinstellingen in te stellen en MongoDB overal (vooral op hackathons) als de universele oplossing voor databeheer te promoten. Dat was waarschijnlijk een slechte beslissing. Maar het bevestigt de benadering die hier wordt beschreven: deze problemen konden heel snel worden ontdekt, zelfs bij een oppervlakkige beoordeling van de technologie.

Bron: habr.com