voglio usare un database NoSQL su Windows Azure e il volume di dati sarà molto grande. Se una memoria di Azure Table o un database MongoDB in esecuzione utilizzando un ruolo di lavoratore può offrire migliori prestazioni e scalabilità? Qualcuno ha usato MongoDB su Azure usando un ruolo di lavoratore? Si prega di condividere i propri pensieri sull'utilizzo di MongoDB su Azure sull'archivio della tabella di Azure.Azure Table Vs MongoDB su Azure
risposta
Storage Table è una funzione di archiviazione di Windows Azure nucleo, progettato per essere scalabile (
100 TB
200TB
500 TB per conto), durevole (triplo replicate nel centro dati, opzionalmente georeplicated un altro centro dati), e schemaless (ogni riga può contenere proprietà che desideri). Una riga si trova per chiave di partizione + chiave di riga, fornendo una ricerca molto veloce. Tutti gli accessi Storage Table è tramite un API REST ben definito utilizzabile tramite qualsiasi lingua (con SDK, costruita in cima alla API REST, già in vigore per .NET, PHP, Java, Python & Ruby).
MongoDB è un database document-oriented. Per eseguirlo in Azure, è necessario installare MongoDB su ruoli Web/worker o Virtual Machine, puntarlo su un'unità cloud (fornendo in tal modo una lettera di unità) o un disco collegato (per macchine virtuali Windows/Linux), facoltativamente attivare l'inserimento nel journal (che io raccomanderei), e facoltativamente definire un endpoint esterno per il vostro uso (o accedervi tramite la rete virtuale). Il Cloud Drive/disco collegato, a proposito, è in realtà memorizzato in un BLOB di Azure, fornendo la stessa durata e georeplicazione di Tabelle di Azure.
Quando si confrontano i due, ricordate che Storage Table è Storage-as-a-Service: è sufficiente accedere un noto endpoint REST. Con MongoDB, sei responsabile della manutenzione del database (ad esempio, ogni volta che MongoDB Inc (ex 10gen) invia una nuova versione di MongoDB, dovrai aggiornare il tuo server di conseguenza).
Per quanto riguarda la versione alpha di MongoDB Inc puntato da jtoberon: Se si prende uno sguardo da vicino a lui, vedrete alcune cose fondamentali:
- Il setup è per uno standalone MongoDB esempio, senza replicazione set o frammenti. Per quanto riguarda i set di repliche, si ottengono ancora numerosi benefici utilizzando la versione Standalone, a causa del modo in cui funziona lo storage Blob.
- Per fornire disponibilità elevata, è possibile eseguire più istanze. In questo caso, solo una istanza serve il database e una è una "warm-standby" che avvia il processo mongod non appena l'altra istanza fallisce (per il riavvio della manutenzione, l'hardware, ecc.).
Mentre il wrapper Windows Azure di 10gen è ancora considerato 'alfa', non lo è mongod.exe. Puoi lanciare mongod exe proprio come faresti con qualsiasi altro exe di Windows. È solo il codice di gestione del lancio, ed è quello che sta dimostrando l'implementazione di alpa.
EDIT 2011/12/08: Questo non è più in uno stato alfa. È possibile scaricare l'ultimo progetto MongoDB + Windows Azure here, che fornisce il supporto per il set di repliche.
Per le prestazioni, credo che avrete bisogno di fare un po 'di benchmarking. Detto questo, considera quanto segue:
- Quando si accede a Table Storage o MongoDB da, ad esempio, a un ruolo Web, si sta ancora raggiungendo il sistema di archiviazione di Windows Azure.
- MongoDB utilizza molta memoria per la propria cache. Per questo motivo, molti sistemi MongoDB su vasta scala vengono implementati in dimensioni di istanza più grandi. Per l'accesso alla memoria della tabella, non si avrà la stessa considerazione della dimensione della memoria.
EDIT 7 aprile 2015 Se si desidera utilizzare un database basato su documenti as-a-service, Azure offre ora DocumentDB.
Ho usato entrambi.
Tabelle di Azure: dead simple, fast, really hard to write query anche semplici.
Mongo: funziona bene, molte funzionalità di interrogazione, richiede diverse istanze per essere affidabile.
In breve, se le query sono molto semplici (chiave-> valore), è necessario eseguire un confronto dei costi (principalmente il numero di transazioni rispetto allo spazio di archiviazione rispetto al costo di hosting di Mongo su Azure). Preferirei andare al tavolo storage per quello. Se hai bisogno di query più elaborate e non vuoi andare su SQL Azure, probabilmente Mongo è la soluzione migliore.
È ancora così dopo aver pubblicato gli endpoint simili ai servizi dati WCF? Penso che si possa fare LINQ su questi endpoint –
Puoi spiegare (o indicare un riferimento su) il tuo commento "richiede che diverse istanze siano affidabili"? Perché 2 non sarebbe affidabile? – Mark
Sì, è ancora il caso che la query in Azure Tables sia difficile, anche nelle versioni più recenti. È possibile eseguire LINQ, ma non tutte le funzioni sono supportate, ad esempio orderby, "contains" e count e genereranno un errore. Qualsiasi interrogazione oltre a quelle contro il PK risulta in una scansione della tabella. – Daniel
La mia prima scelta è perché AzureTables modello SaaS e di basso costo e SLA 99,99%
http://alexandrebrisebois.wordpress.com/2013/07/09/what-if-20000-windows-azure-storage-transactions-per-second-isnt-enough/
alcuni limiti .. http://msdn.microsoft.com/en-us/library/windowsazure/jj553018.aspx
http://www.windowsazure.com/en-us/pricing/calculator/?scenario=data-management
o AzureSQL per le piccole imprese
Docum entDB http://azure.microsoft.com/en-us/documentation/services/documentdb/ http://azure.microsoft.com/en-us/documentation/articles/documentdb-limits/
seconda scelta è molti fornitori di cloud come Amazon offerta S3
o Google tavoli https://developers.google.com/bigquery/pricing
scelta all'ennesima gestire SHOW tutto da solo non hanno il sonno MongoDB e guarderò di nuovo i primi due SAAS
La mia scelta se sto correndo "CLOUD" I wi ll andare per il modello SaaS, per quanto possibile "RENT-IT" ...
La domanda è che cosa la mia app ha bisogno è AzureTables o DocumentDB o AzureSQL
documentazione DocumentDB http://azure.microsoft.com/en-us/documentation/services/documentdb/
Come funziona Azure pricing http://azure.microsoft.com/en-us/pricing/details/documentdb/
questo è divertente http://www.documentdb.com/sql/demo
mi rendo conto che la questione è datata. Mi piacerebbe aggiungere le seguenti informazioni per coloro che potrebbero imbattersi in questa domanda nelle loro ricerche.
Si noti che ora MongoDB viene offerto come servizio completamente gestito su Azure.(Ufficialmente in versione Beta, come di aprile '15)
See: http://www.mongodb.com/partners/cloud/microsoft o https://azure.microsoft.com/en-us/blog/announcing-new-mongodb-instances-on-microsoft-azure/
See (inclusi i prezzi): https://azure.microsoft.com/en-us/marketplace/partners/mongolab/mongolab/
Soprattutto risposte sono tutte buono - ma la vera risposta dipende quali sono le tue esigenze. È necessario capire quale dimensione dei dati si sta elaborando, quali tipi di operazioni si desidera eseguire sui dati e quindi selezionare la soluzione che soddisfa le proprie esigenze.
In Build 2016 è stato annunciato che DocumentDB supportava tutti i driver MongoDB. Ciò risolve parte della mancanza di problemi di strumenti con DocDB e semplifica anche la migrazione delle app Mongo.
Una cosa da ricordare è Azure Storage Table non supporta tipi di dati complessi .E supporta ogni proprietà in un'entità ad essere una stringa o un numero o booleano o la data ecc Non si può memorizzare un oggetto contro un chiave, che ritengo sia necessario per NoSql DB. https://docs.microsoft.com/en-us/rest/api/storageservices/fileservices/understanding-the-table-service-data-model scorrimento a tipi di Immobili
"L'archiviazione di tabelle di Azure non supporta tipi di dati complessi. " Non è del tutto corretto. Con Azure Storage SDK versione 8.0.0.0, le API vengono aggiunte all'SDK per scrivere oggetti complessi nell'archivio della tabella. Vedere https://msdn.microsoft.com/en-us/library/azure/mt775434.aspx e https://msdn.microsoft.com/en-us/library/azure/mt775432.aspx. Ho scritto queste api s :) quindi se avete commenti non esitate a chiedere .. –
Potete per favore condividere esempi con Node.js, inoltre c'è un vincolo di dimensione della proprietà che forza 64KB limite massimo a destra, con questo possiamo archiviare un oggetto molto grande ?, Grazie in anticipo ... –
Sì, sono d'accordo che possiamo farlo serializzando e deserializzando, ma un DB No-SQL dovrebbe supportarli di default senza alcuno sforzo in più, ma sentivo che Azure è una memoria di tipo Tabella (per quanto riguarda le colonne, è più adatto per dati di valori-chiave semplici). –
non ho tris io stesso, ma MongoDB sembra venire come Azure add-on attraverso il negozio. Presumibilmente ciò rende la distribuzione semplice come quella dell'archiviazione della tabella di Azure. – John