sql >> Database >  >> NoSQL >> MongoDB

Azure Table versus MongoDB op Azure

Table Storage is een kernfunctie van Windows Azure-opslag, ontworpen om schaalbaar te zijn (100TB 200TB 500TB per account), duurzaam (drievoudig gerepliceerd in het datacenter, optioneel georepliceerd naar een ander datacenter) en schemaloos (elke rij kan alle gewenste eigenschappen bevatten). Een rij wordt gelokaliseerd door partitiesleutel + rijsleutel, waardoor zeer snel opzoeken mogelijk is. Alle toegang tot Table Storage is via een goed gedefinieerde REST API die in elke taal kan worden gebruikt (met SDK's, gebouwd bovenop de REST API's, die al aanwezig zijn voor .NET, PHP, Java, Python en Ruby).

MongoDB is een documentgeoriënteerde database. Om het in Azure uit te voeren, moet u MongoDB installeren op een web-/werkrol of virtuele machine, het verwijzen naar een cloudstation (waardoor een stationsletter wordt opgegeven) of een aangesloten schijf (voor Windows/Linux virtuele machines), optioneel journaling inschakelen (wat ik zou aanraden), en optioneel een extern eindpunt definiëren voor uw gebruik (of toegang krijgen via een virtueel netwerk). De Cloud Drive / gekoppelde schijf wordt trouwens daadwerkelijk opgeslagen in een Azure Blob, waardoor u dezelfde duurzaamheid en georeplicatie krijgt als Azure Tables.

Houd er bij het vergelijken van de twee rekening mee dat Table Storage Storage-as-a-Service is:u krijgt eenvoudig toegang tot een bekend REST-eindpunt. Met MongoDB bent u verantwoordelijk voor het onderhoud van de database (bijv. wanneer MongoDB Inc (voorheen 10gen) een nieuwe versie van MongoDB uitbrengt, moet u uw server dienovereenkomstig bijwerken).

Wat betreft de alfaversie van MongoDB Inc waar jtoberon naar verwijst:als je er goed naar kijkt, zie je een paar belangrijke dingen:

  • De configuratie is voor een zelfstandige mongodb-instantie, zonder replicasets of shards. Met betrekking tot replica-sets krijg je nog steeds verschillende voordelen met de Standalone-versie, vanwege de manier waarop Blob-opslag werkt.
  • Om een ​​hoge beschikbaarheid te bieden, kunt u met meerdere instanties werken. In dit geval bedient slechts één instantie de database en één is een 'warm-stand-by' die het mongod-proces start zodra de andere instantie faalt (voor herstart van onderhoud, hardwarestoring, enz.).

Hoewel de Windows Azure-wrapper van 10gen nog steeds als 'alpha' wordt beschouwd, is mongod.exe dat niet. U kunt de mongod exe starten net zoals u elke andere Windows exe zou starten. Het is gewoon de managementcode rond de lancering, en dat is wat de alpa-implementatie aantoont.

EDIT 2011-12-8:Dit is niet langer in een alfastaat. U kunt hier het nieuwste MongoDB+Windows Azure-project downloaden, dat ondersteuning voor replicasets biedt.

Voor prestaties denk ik dat je wat benchmarking moet doen. Dat gezegd hebbende, overweeg het volgende:

  • Als je toegang hebt tot Table Storage of MongoDB vanuit bijvoorbeeld een webrol, heb je nog steeds contact met het Windows Azure Storage-systeem.
  • MongoDB gebruikt veel geheugen voor zijn eigen cache. Om deze reden worden veel grootschalige MongoDB-systemen ingezet voor grotere instantiegroottes. Voor toegang tot Table Storage hoeft u niet dezelfde geheugengrootte te overwegen.

BEWERK 7 april 2015 Als u een op documenten gebaseerde database as-a-service wilt gebruiken, biedt Azure nu DocumentDB.



  1. Hoe verwijder ik vastgelopen/verouderde Resque-werknemers?

  2. Promoot subvelden naar het hoogste niveau in projectie zonder alle sleutels op te sommen

  3. MongoDB - $set om het Array-element bij te werken of te pushen

  4. Hoe voer ik een MongoDB js-script uit met behulp van de Java MongoDriver