sql >> Databasteknik >  >> NoSQL >> MongoDB

Azure Table vs MongoDB på Azure

Tabelllagring är en kärnlagringsfunktion i Windows Azure, designad för att vara skalbar (100TB 200TB 500TB per konto), hållbar (trippelreplikerad i datacentret, valfritt georeplicerad till ett annat datacenter) och schemalös (varje rad kan innehålla vilka egenskaper du vill). En rad lokaliseras med partitionsnyckel + radnyckel, vilket ger mycket snabb uppslagning. All åtkomst till tabelllagring sker via ett väldefinierat REST API som kan användas via alla språk (med SDK:er, byggda ovanpå REST API:erna, redan på plats för .NET, PHP, Java, Python och Ruby).

MongoDB är en dokumentorienterad databas. För att köra den i Azure måste du installera MongoDB på en webb-/arbetarroll eller virtuell maskin, peka den på en molnenhet (och därigenom tillhandahålla en enhetsbeteckning) eller ansluten disk (för virtuella Windows/Linux-maskiner), aktivera eventuellt journalföring (vilket jag skulle rekommendera), och valfritt definiera en extern slutpunkt för din användning (eller komma åt den via virtuellt nätverk). Cloud Drive/anslutna disk, förresten, lagras faktiskt i en Azure Blob, vilket ger dig samma hållbarhet och georeplication som Azure Tables.

När du jämför de två, kom ihåg att Table Storage är Storage-as-a-Service:du får helt enkelt tillgång till en välkänd REST-slutpunkt. Med MongoDB är du ansvarig för att underhålla databasen (t.ex. när MongoDB Inc (tidigare 10gen) släpper ut en ny version av MongoDB, måste du uppdatera din server därefter).

Angående MongoDB Inc:s alfaversion som jtoberon pekade på:Om du tittar närmare på den kommer du att se några viktiga saker:

  • Inställningen är för en fristående mongodb-instans, utan replikuppsättningar eller skärvor. När det gäller replika-set får du fortfarande flera fördelar med den fristående versionen, på grund av hur Blob-lagring fungerar.
  • För att ge hög tillgänglighet kan du köra med flera instanser. I det här fallet är det bara en instans som betjänar databasen, och en är en "varm-standby" som startar mongod-processen så snart den andra instansen misslyckas (för underhållsomstart, hårdvarufel, etc.).

Medan 10gens Windows Azure-omslag fortfarande anses vara "alfa", är det inte mongod.exe. Du kan starta mongod exe precis som du skulle starta alla andra Windows exe. Det är bara hanteringskoden kring lanseringen, och det är vad alpa-implementeringen visar.

EDIT 2011-12-8:Detta är inte längre i ett alfatillstånd. Du kan ladda ner det senaste MongoDB+Windows Azure-projektet här, som ger stöd för replikuppsättningar.

För prestanda tror jag att du måste göra några benchmarking. Med det sagt, tänk på följande:

  • När du kommer åt antingen Table Storage eller MongoDB från till exempel en webbroll, kontaktar du fortfarande Windows Azure Storage-systemet.
  • MongoDB använder mycket minne för sin egen cache. Av denna anledning distribueras många högskaliga MongoDB-system till större instansstorlekar. För åtkomst till tabelllagring har du inte samma hänsyn till minnesstorlek.

REDIGERA 7 april 2015 Om du vill använda en dokumentbaserad databas som en tjänst erbjuder Azure nu DocumentDB.



  1. redis prestanda, lagra json-objekt som en sträng

  2. Timeout utför SET {Key}, inst:0, mgr:Inaktiv, kö:2, qu=1, qs=1, qc=0, wr=1/1, in=0/0

  3. Hur man använder Node.js för att göra en SSH-tunnlinganslutning till en MongoDB-databas

  4. Tillkännage ClusterControl 1.4.2 - DevOps Edition