{"id":30666,"date":"2019-10-31T21:36:48","date_gmt":"2019-10-31T18:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/byla-la-mongodb-voobshhe-pravilnym-vyborom\/"},"modified":"2019-10-31T21:36:48","modified_gmt":"2019-10-31T18:36:48","slug":"byla-la-mongodb-voobshhe-pravilnym-vyborom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/byla-la-mongodb-voobshhe-pravilnym-vyborom","title":{"rendered":"Var MongoDB overhovedet det rigtige valg?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>For nylig fandt jeg ud af, at <noindex><a rel=\"nofollow\" href=\"https:\/\/www.redhat.com\/en\/blog\/red-hat-satellite-standardize-postgresql-backend\">Red Hat fjerner support for MongoDB fra Satellite<\/a><\/noindex> (siger de, p\u00e5 grund af \u00e6ndringer i licensen). Dette fik mig til at t\u00e6nke over, at jeg de seneste par \u00e5r har set en masse artikler om, hvor forf\u00e6rdelig MongoDB er, og at ingen nogensinde burde bruge den. Men i l\u00f8bet af den tid er MongoDB blevet et langt mere modent produkt. Hvad er der sket? Forklarer al den had virkelig fejlene i begyndelsen af marketing for den nye DBMS? Eller bruger folk bare MongoDB de forkerte steder?<\/p>\n<p>Hvis du pludselig synes, at jeg forsvarer MongoDB, s\u00e5 l\u00e6s venligst <noindex><a rel=\"nofollow\" href=\"#1\">disclaimeren<\/a><\/noindex> for enden af artiklen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Ny trend<\/h1>\n<p>\nJeg har arbejdet i softwareindustrien i l\u00e6ngere tid, end det er passende at n\u00e6vne, men jeg har kun set en lille del af de tendenser, der har ramt vores branche. Jeg har v\u00e6ret vidne til v\u00e6ksten af 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... listen er uendelig. Nye tendenser dukker op hvert \u00e5r. Nogle forsvinder hurtigt, mens andre fundamentalt \u00e6ndrer m\u00e5den, vi udvikler software p\u00e5.<\/p>\n<p>Rundt om hver ny trend opst\u00e5r der en form for universel ophidselse: folk hopper selv ind i b\u00e5den, eller de ser det st\u00f8j, der genereres af andre \u2013 og f\u00f8lger m\u00e6ngden. Denne proces er blevet kodificeret af Gartner i <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Hype_cycle\">hype-cyklussen<\/a><\/noindex>. Selvom den er kontroversiel, beskriver denne graf nogenlunde, hvad der sker med teknologier, f\u00f8r de til sidst bliver nyttige at bruge.<\/p>\n<p>Men fra tid til anden opst\u00e5r der (eller sker der et andet komme, som i dette tilf\u00e6lde) en ny innovation, drevet kun af en specifik implementering. I tilf\u00e6lde af NoSQL var hypen st\u00e6rkt betinget af fremkomsten og den hurtige stigning af MongoDB. Det var ikke MongoDB, der startede denne trend: faktisk begyndte store internetfirmaer at have problemer med at h\u00e5ndtere store datam\u00e6ngder, hvilket f\u00f8rte til genopblussen af ikke-relationelle databaser. Den generelle bev\u00e6gelse startede med projekter som Googles Bigtable og Facebooks Cassandra, men det var netop MongoDB, der blev den mest kendte og tilg\u00e6ngelige NoSQL-database, som de fleste udviklere havde adgang til.<\/p>\n<p><i>Bem\u00e6rk: du kan t\u00e6nke, at jeg blander dokumentdatabaser med kolonnebaserede databaser, n\u00f8gle\/v\u00e6rdi-lagre eller nogen af de mange andre typer datalagre, der falder ind under den generelle definition af NoSQL. Og du har ret. Men p\u00e5 det tidspunkt herskede der kaos. Alle var besatte af NoSQL, det blev for dem <b>absolut<\/b> det er n\u00f8dvendigt, selvom mange ikke har set forskelle i forskellige teknologier. For mange blev MongoDB <b>lig med<\/b> NoSQL.<\/i><\/p>\n<p>Og udviklerne kastede sig over den. Ideen om en skemal\u00f8s database, der magisk kunne skaleres til at l\u00f8se ethvert problem, var ret tiltalende. Omkring 2014 s\u00e5 det ud til, at hvor der f\u00f8r var blevet brugt en relationel database som MySQL, Postgres eller SQL Server, begyndte man at implementere MongoDB-databaser. P\u00e5 sp\u00f8rgsm\u00e5let om hvorfor kunne man f\u00e5 svar fra det banale \"det er webskala\" til det mere gennemarbejdede \"mine data er meget svagt struktureret og passer godt ind i en skemal\u00f8s database.\"<\/p>\n<p>Det er vigtigt at huske, at MongoDB og dokumentdatabaser generelt l\u00f8ser en r\u00e6kke problemer med traditionelle relationelle databaser:<\/p>\n<ul>\n<li><b>Strenge skemaer<\/b>: med en relationel database, hvis du har dynamisk genererede data, er du n\u00f8dt til enten at lave en masse tilf\u00e6ldige \"forskellige\" datakolonner, presse blob-data ind eller bruge en konfiguration <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Entity%E2%80%93attribute%E2%80%93value_model\">EAV<\/a><\/noindex>\u2026 alt dette har betydelige ulemper.\n<\/li>\n<li><b>Skal\u00e9rbarhed<\/b>: hvis dataene er s\u00e5 mange, at de ikke kan v\u00e6re p\u00e5 \u00e9n server, tilb\u00f8d MongoDB mekanismer, der gjorde det muligt at skalere dem p\u00e5 flere maskiner.\n<\/li>\n<li><b>Komplekse skem\u00e6ndringer<\/b>: ingen migrationer! I en relationel database kan \u00e6ndring af databasens struktur blive et k\u00e6mpe problem (is\u00e6r n\u00e5r dataene bliver meget store). MongoDB har v\u00e6ret i stand til betydeligt at forenkle processen. Og de gjorde det s\u00e5 let, at du bare kan opdatere skemaet undervejs og hurtigt komme videre.\n<\/li>\n<li><b>Skriveydelse<\/b>: MongoDB's ydelse var god, is\u00e6r med korrekt konfiguration. Selv en standardkonfiguration af MongoDB, som den ofte blev kritiseret for, viste nogle imponerende ydeevneindikatorer.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Alle risici er p\u00e5 dig<\/h1>\n<p>\nDe potentielle fordele ved MongoDB var enorme, is\u00e6r for bestemte typer af problemer. Hvis man l\u00e6ser den ovenst\u00e5ende liste uden at forst\u00e5 konteksten og uden erfaring, kan man f\u00e5 indtryk af, at MongoDB virkelig er en revolutionerende DBMS. Det eneste problem var, at de n\u00e6vnte fordele blev ledsaget af en r\u00e6kke forbehold, hvor nogle af dem er n\u00e6vnt nedenfor.<\/p>\n<p>For the sake of fairness, no one at 10gen\/MongoDB Inc. will say that what follows is untrue; these are simply compromises.<\/p>\n<ul>\n<li><b>Tab af transaktioner<\/b>: transaktioner er en grundl\u00e6ggende egenskab ved mange relationsdatabaser (ikke alle, men de fleste). Transaktionalitet betyder, at du kan udf\u00f8re flere operationer atomart og kan garantere, at dataene forbliver konsistente. Selvf\u00f8lgelig kan transaktionalitet i en NoSQL-database v\u00e6re inden for \u00e9t dokument, eller du kan bruge to-fase commit for at opn\u00e5 transaktionel semantik. Men du skal selv implementere denne funktionalitet... hvilket kan v\u00e6re en kompleks og tidskr\u00e6vende opgave. Ofte opdager du ikke problemerne, f\u00f8r du ser, at data i databasen ender i uacceptable tilstande, fordi det er umuligt at garantere atomaritet i operationerne. <b>Bem\u00e6rk: mange har informeret mig om, at transaktioner blev tilf\u00f8jet i MongoDB 4.0 sidste \u00e5r, men med en r\u00e6kke begr\u00e6nsninger. Konklusionen fra artiklen forbliver den samme: vurder, hvor godt teknologien passer til dine behov.<\/b>\n<\/li>\n<li><b>Tab af relationel integritet (fremmedn\u00f8gler)<\/b>: hvis dine data har relationer, skal du anvende dem i applikationen. At have en database, der opretholder disse relationer, vil reducere en betydelig del af arbejdet med applikationen og dermed for dine programm\u00f8rer.\n<\/li>\n<li><b>Manglende evne til at anvende datastrukturen<\/b>: strenge skemaer kan undertiden udg\u00f8re et stort problem, men det er ogs\u00e5 en kraftfuld mekanisme til god dataopbygning, hvis de bruges korrekt. Dokumentdatabaser som MongoDB giver utrolig fleksibilitet i skemaet, men denne fleksibilitet fral\u00e6gger ansvaret for at holde dataene i orden. Hvis du ikke passer p\u00e5 dem, vil du ende med at skrive meget kode i applikationen for at h\u00e5ndtere data, der ikke opbevares i den form, du forventer. Som man ofte siger i vores virksomhed, Simple Thread... applikationen vil en dag blive omskrevet, men dataene vil leve for evigt. <b>Bem\u00e6rk: MongoDB underst\u00f8tter skemavalidering; det er nyttigt, men giver ikke de samme garantier som en relationsdatabase. F\u00f8rst og fremmest p\u00e5virker tilf\u00f8jelse eller \u00e6ndring af skemavalidering ikke eksisterende data i samlingen. Du skal selv sikre dig, at du opdaterer dataene i overensstemmelse med det nye skema. Vurder selv, om dette er tilstr\u00e6kkeligt til dine behov.<\/b>\n<\/li>\n<li><b>Eget foresp\u00f8rgselssprog \/ tab af v\u00e6rkt\u00f8js\u00f8kosystem<\/b>: fremkomsten af SQL var en absolut revolution, og siden da er intet \u00e6ndret. Det er et utroligt magtfuldt sprog, men ogs\u00e5 temmelig komplekst. Behovet for at konstruere foresp\u00f8rgsler mod databasen p\u00e5 et nyt sprog, der best\u00e5r af JSON-fragmenter, ses som et stort skridt tilbage af personer med erfaring i SQL. Der findes et helt univers af v\u00e6rkt\u00f8jer, der interagerer med SQL-databaser: fra IDE'er til rapporteringsv\u00e6rkt\u00f8jer. Overgangen til en database, der ikke underst\u00f8tter SQL, betyder, at du ikke kan bruge de fleste af disse v\u00e6rkt\u00f8jer, eller du skal konvertere dataene til SQL for at bruge dem, hvilket kan vise sig at v\u00e6re sv\u00e6rere, end du tror.<\/li>\n<\/ul>\n<p>\nMange udviklere, der henvendte sig til MongoDB, havde ikke rigtig forst\u00e5et kompromiserne og dykkede ofte hovedkuls ned, idet de installerede det som deres prim\u00e6re datalager. Efter det var det ofte utroligt sv\u00e6rt at vende tilbage.<\/p>\n<h1>Hvad kunne have v\u00e6ret gjort anderledes?<\/h1>\n<p>\nIkke alle sprang hovedkuls frem og bragede ned. Men mange projekter installerede MongoDB, hvor det simpelthen ikke passede \u2013 og de m\u00e5 leve med det i mange \u00e5r fremover. Hvis disse organisationer havde brugt lidt tid p\u00e5 systematisk at overveje teknologivalget, ville mange have truffet et andet valg.<\/p>\n<p>Hvordan v\u00e6lger man den rette teknologi? Der har v\u00e6ret flere fors\u00f8g p\u00e5 at skabe et systematisk rammev\u00e6rk til vurdering af teknologier, s\u00e5som <noindex><a rel=\"nofollow\" href=\"http:\/\/www.wohlin.eu\/spi96.pdf\">\u00abRammev\u00e6rk for implementering af teknologier i softwareorganisationer\u00bb<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/pdfs.semanticscholar.org\/4268\/30dd5dd944d3b75ec56b2a3b151c18afbaf9.pdf\">\u00abRammev\u00e6rk til vurdering af softwareteknologier\u00bb<\/a><\/noindex>, men jeg mener, at dette er un\u00f8dvendig kompleksitet.<\/p>\n<p>Mange teknologier kan fornuftigt vurderes ved at stille bare to grundl\u00e6ggende sp\u00f8rgsm\u00e5l. <b>Problemet ligger i at finde personer, der kan svare ansvarligt p\u00e5 dem, bruge tid p\u00e5 at finde svar og uden forudindtagethed.<\/b><\/p>\n<blockquote><p>Hvis du ikke st\u00e5r over for et bestemt problem, har du ikke brug for et nyt v\u00e6rkt\u00f8j. Punktum.<\/p><\/blockquote>\n<p><\/p>\n<h1>Sp\u00f8rgsm\u00e5l 1: Hvilke problemer fors\u00f8ger jeg at l\u00f8se?<\/h1>\n<p>\nHvis du ikke st\u00e5r over for et problem, er der ikke behov for et nyt v\u00e6rkt\u00f8j. Punktum. Der er ingen grund til at lede efter en l\u00f8sning og derefter finde p\u00e5 et problem. Hvis du ikke har st\u00f8dt p\u00e5 et problem, som den nye teknologi l\u00f8ser betydeligt bedre end din nuv\u00e6rende teknologi, er der ikke noget at diskutere. Hvis du overvejer at bruge denne teknologi, fordi du har set andre bruge den, skal du t\u00e6nke over, hvilke problemer de st\u00e5r over for, og sp\u00f8rge, om du har de samme problemer. Det er let at tage teknologien til sig, fordi andre g\u00f8r det; udfordringen ligger i at forst\u00e5, om du st\u00e5r over for de samme problemer.<\/p>\n<h1>Sp\u00f8rgsm\u00e5l 2: Hvad g\u00e5r jeg glip af?<\/h1>\n<p>\nDette er uden tvivl et sv\u00e6rere sp\u00f8rgsm\u00e5l, fordi du skal grave dybt og forst\u00e5 b\u00e5de den gamle og den nye teknologi godt. Nogle gange kan du ikke virkelig forst\u00e5 det nye, f\u00f8r du bygger noget med det, eller f\u00f8r du har en medarbejder med den erfaring.<\/p>\n<p>Hvis du ikke har det ene eller det andet, giver det mening at overveje de mindste mulige investeringer for at bestemme v\u00e6rdien af dette v\u00e6rkt\u00f8j. Og hvis du foretager investeringer, hvor sv\u00e6rt vil det s\u00e5 v\u00e6re at annullere beslutningen?<\/p>\n<h1>Mennesker \u00f8del\u00e6gger altid alt<\/h1>\n<p>\nN\u00e5r du fors\u00f8ger at besvare disse sp\u00f8rgsm\u00e5l s\u00e5 objektivt som muligt, skal du huske \u00e9n ting: du vil skulle k\u00e6mpe mod den menneskelige natur. Der er en r\u00e6kke kognitive sk\u00e6vheder, som du skal overvinde for effektivt at kunne vurdere teknologien. Her er bare nogle f\u00e5:<\/p>\n<ul>\n<li><b><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bandwagon_effect\">Flertals-effekt<\/a><\/noindex><\/b> \u2014 alle kender den, men den er stadig sv\u00e6r at h\u00e5ndtere. S\u00f8rg for, at teknologien virkelig matcher dine reelle behov.\n<\/li>\n<li><b><noindex><a rel=\"nofollow\" href=\"https:\/\/mindmodeling.org\/cogsci2015\/papers\/0177\/index.html\">Nyhedseffekt<\/a><\/noindex><\/b> \u2014 mange udviklere har tendens til at undervurdere teknologier, de har arbejdet med i lang tid, og overvurdere fordelene ved ny teknologi. Det er ikke kun programm\u00f8rer, alle er udsat for denne kognitive sk\u00e6vhed.\n<\/li>\n<li><b><noindex><a rel=\"nofollow\" href=\"https:\/\/pigeon.psy.tufts.edu\/avc\/dittrich\/fepef.htm\">Positive karakteristikseffekt<\/a><\/noindex> \u2014 vi har en tendens til at se, hvad der er, og overse, hvad der mangler. Dette kan f\u00f8re til kaos i forbindelse med nyhedseffekten, da du ikke kun undervurderer den nye teknologi, men ogs\u00e5 ignorerer dens mangler.<\/b>.<\/li>\n<\/ul>\n<p>\nDet er ikke nemt at give en objektiv vurdering, men forst\u00e5elsen af de grundl\u00e6ggende kognitive sk\u00e6vheder kan hj\u00e6lpe os med at tr\u00e6ffe mere rationelle beslutninger.<\/p>\n<h1>CV<\/h1>\n<p>\nN\u00e5r der opst\u00e5r en ny innovation, skal man forsigtigt besvare to sp\u00f8rgsm\u00e5l:<\/p>\n<ul>\n<li>L\u00f8ser dette v\u00e6rkt\u00f8j et reelt problem?\n<\/li>\n<li>Forst\u00e5r vi kompromisserne korrekt?<\/li>\n<\/ul>\n<p>\nHvis du ikke kan svare sikkert p\u00e5 disse to sp\u00f8rgsm\u00e5l, s\u00e5 tag et skridt tilbage og t\u00e6nk efter.<\/p>\n<p>Var MongoDB overhovedet det rigtige valg? Selvf\u00f8lgelig ja; ligesom med de fleste ingeni\u00f8rteknologier afh\u00e6nger det af mange faktorer. Blandt dem, der har besvaret disse to sp\u00f8rgsm\u00e5l, har mange haft gl\u00e6de af MongoDB og forts\u00e6tter med at have det. For dem, der ikke gjorde, h\u00e5ber jeg, at de fik en v\u00e6rdifuld og ikke alt for smertefuld lektion om at navigere i hype-cyklussen.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"1\"><\/a><\/noindex><\/p>\n<h1>Fraskrivelse<\/h1>\n<p>\nJeg vil gerne pr\u00e6cisere, at jeg hverken hader eller elsker MongoDB. Vi har bare ikke haft de problemer, hvor MongoDB ville v\u00e6re den bedste l\u00f8sning. Jeg ved, at 10gen\/MongoDB Inc. i starten handlede meget dristigt ved at s\u00e6tte usikre standardv\u00e6rdier og promovere MongoDB overalt (is\u00e6r p\u00e5 hackathons) som en universall\u00f8sning til alle datatyper. Det var sandsynligvis en d\u00e5rlig beslutning. Men det bekr\u00e6fter den tilgang, der beskrives her: disse problemer kunne hurtigt opdages, selv ved en overfladisk vurdering af teknologien.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/446180\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0443\u0437\u043d\u0430\u043b, \u0447\u0442\u043e Red Hat \u0443\u0434\u0430\u043b\u044f\u0435\u0442 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0443 MongoDB \u0438\u0437 Satellite (\u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0438\u0437-\u0437\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u043b\u0438\u0446\u0435\u043d\u0437\u0438\u0438). \u042d\u0442\u043e \u0437\u0430\u0441\u0442\u0430\u0432\u0438\u043b\u043e \u043c\u0435\u043d\u044f \u0437\u0430\u0434\u0443\u043c\u0430\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u044f \u0432\u0438\u0434\u0435\u043b \u043a\u0443\u0447\u0443 \u0441\u0442\u0430\u0442\u0435\u0439, \u043a\u0430\u043a \u0443\u0436\u0430\u0441\u043d\u0430 MongoDB \u0438 \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u0434\u043e\u043b\u0436\u0435\u043d \u0435\u0451 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c. \u041d\u043e \u0437\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f MongoDB \u0441\u0442\u0430\u043b\u0430 \u0433\u043e\u0440\u0430\u0437\u0434\u043e \u0431\u043e\u043b\u0435\u0435 \u0437\u0440\u0435\u043b\u044b\u043c \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u043c. \u0427\u0442\u043e \u0436\u0435 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c? \u0414\u0435\u0439\u0441\u0442\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043b\u0438 \u0432\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30666","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0443\u0437\u043d\u0430\u043b, \u0447\u0442\u043e Red Hat \u0443\u0434\u0430\u043b\u044f\u0435\u0442 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0443 MongoDB \u0438\u0437 Satellite (\u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0438\u0437-\u0437\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/byla-la-mongodb-voobshhe-pravilnym-vyborom\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0411\u044b\u043b\u0430 \u043b\u0430 MongoDB \u0432\u043e\u043e\u0431\u0449\u0435 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u044b\u043c \u0432\u044b\u0431\u043e\u0440\u043e\u043c? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0443\u0437\u043d\u0430\u043b, \u0447\u0442\u043e Red Hat \u0443\u0434\u0430\u043b\u044f\u0435\u0442 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0443 MongoDB \u0438\u0437 Satellite (\u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0438\u0437-\u0437\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/byla-la-mongodb-voobshhe-pravilnym-vyborom\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:36:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:36:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Var MongoDB overhovedet det rigtige valg? | ProHoster","description":"For nylig fandt jeg ud af, at Red Hat fjerner underst\u00f8ttelsen af MongoDB fra Satellite (siges at v\u00e6re p\u00e5 grund af.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/byla-la-mongodb-voobshhe-pravilnym-vyborom","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0411\u044b\u043b\u0430 \u043b\u0430 MongoDB \u0432\u043e\u043e\u0431\u0449\u0435 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u044b\u043c \u0432\u044b\u0431\u043e\u0440\u043e\u043c? | ProHoster","og:description":"\u041d\u0435\u0434\u0430\u0432\u043d\u043e \u044f \u0443\u0437\u043d\u0430\u043b, \u0447\u0442\u043e Red Hat \u0443\u0434\u0430\u043b\u044f\u0435\u0442 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0443 MongoDB \u0438\u0437 Satellite (\u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0438\u0437-\u0437\u0430.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/byla-la-mongodb-voobshhe-pravilnym-vyborom","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:36:48+00:00","article:modified_time":"2019-10-31T18:36:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30666","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 02:22:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:31:23","updated":"2026-01-21 02:22:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30666","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=30666"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30666\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=30666"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=30666"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=30666"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}