Table Storage est une fonctionnalité de stockage de base de Windows Azure, conçue pour être évolutive (100 To 200 To 500 To par compte), durable (triple réplication dans le centre de données, éventuellement géorépliquée dans un autre centre de données) et sans schéma (chaque ligne peut contenir les propriétés de votre choix). Une ligne est localisée par clé de partition + clé de ligne, ce qui permet une recherche très rapide. Tous les accès au stockage de table se font via une API REST bien définie utilisable dans n'importe quel langage (avec des SDK, construits au-dessus des API REST, déjà en place pour .NET, PHP, Java, Python et Ruby).
MongoDB est une base de données orientée documents. Pour l'exécuter dans Azure, vous devez installer MongoDB sur un rôle Web/travailleur ou une machine virtuelle, le pointer vers un lecteur cloud (fournissant ainsi une lettre de lecteur) ou un disque attaché (pour les machines virtuelles Windows/Linux), activer éventuellement la journalisation (ce que je recommanderais), et éventuellement définir un point de terminaison externe pour votre utilisation (ou y accéder via un réseau virtuel). Soit dit en passant, le Cloud Drive/disque attaché est en fait stocké dans un Azure Blob, ce qui vous offre la même durabilité et géoréplication que les tables Azure.
Lorsque vous comparez les deux, n'oubliez pas que Table Storage est un stockage en tant que service :vous accédez simplement à un point de terminaison REST bien connu. Avec MongoDB, vous êtes responsable de la maintenance de la base de données (par exemple, chaque fois que MongoDB Inc (anciennement 10gen) sort une nouvelle version de MongoDB, vous devrez mettre à jour votre serveur en conséquence).
Concernant la version alpha de MongoDB Inc pointée par jtoberon :si vous l'examinez de près, vous verrez quelques éléments clés :
- La configuration est pour une instance mongodb autonome, sans jeux de répliques ni fragments. En ce qui concerne les jeux de répliques, vous bénéficiez toujours de plusieurs avantages en utilisant la version autonome, en raison du fonctionnement du stockage Blob.
- Pour fournir une haute disponibilité, vous pouvez exécuter plusieurs instances. Dans ce cas, une seule instance dessert la base de données, et l'une est une "attente à chaud" qui lance le processus mongod dès que l'autre instance échoue (pour un redémarrage de maintenance, une panne matérielle, etc.).
Alors que le wrapper Windows Azure de 10gen est toujours considéré comme "alpha", mongod.exe ne l'est pas. Vous pouvez lancer l'exe mongod comme vous lanceriez n'importe quel autre exe Windows. C'est juste le code de gestion autour du lancement, et c'est ce que démontre l'implémentation alpa.
EDIT 2011-12-8 :Ceci n'est plus dans un état alpha. Vous pouvez télécharger le dernier projet MongoDB + Windows Azure ici, qui fournit une prise en charge des jeux de répliques.
Pour les performances, je pense que vous aurez besoin de faire des analyses comparatives. Cela dit, considérez ce qui suit :
- Lorsque vous accédez à Table Storage ou à MongoDB à partir, par exemple, d'un rôle Web, vous vous adressez toujours au système de stockage Windows Azure.
- MongoDB utilise beaucoup de mémoire pour son propre cache. Pour cette raison, de nombreux systèmes MongoDB à grande échelle sont déployés sur des instances de plus grande taille. Pour l'accès au stockage de table, vous n'aurez pas la même considération de taille de mémoire.
MODIF 7 avril 2015 Si vous souhaitez utiliser une base de données basée sur des documents en tant que service, Azure propose désormais DocumentDB.
