In NoSQL:se solo fosse così facile , l'autore scrive su MongoDB:
MongoDB non è un archivio chiave/valore, è un po' di più. Non è nemmeno un RDBMS. Non ho usato MongoDB in produzione, ma l'ho usato un po' per creare un'app di prova ed è un kit molto interessante. Sembra essere molto performante e ha, o avrà presto, tolleranza agli errori e partizionamento orizzontale automatico (ovvero si ridimensionerà). Penso che Mongo potrebbe essere la cosa più vicina a un sostituto RDBMS che ho visto finora. Non funzionerà con tutti i set di dati e i modelli di accesso, ma è costruito per le tue tipiche cose CRUD. La memorizzazione di quello che è essenzialmente un enorme hash e la possibilità di selezionare una qualsiasi di queste chiavi è ciò per cui la maggior parte delle persone usa un database relazionale. Se il tuo DB è 3NF e non esegui join (stai solo selezionando un gruppo di tabelle e mettendo insieme tutti gli oggetti, AKA ciò che la maggior parte delle persone fa in un'app Web), MongoDB probabilmente prenderebbe a calci in culo per tu.
Poi, in conclusione:
La cosa reale da sottolineare è che se ti viene impedito di realizzare qualcosa di super fantastico perché non puoi scegliere un database, stai sbagliando. Se conosci MySQL, usalo. Ottimizza quando ne hai effettivamente bisogno. Usalo come un negozio k/v, usalo come un rdbms, ma per l'amor di Dio, costruisci la tua app killer! Niente di tutto questo avrà importanza per la maggior parte delle app. Facebook usa ancora MySQL, molto. Wikipedia usa molto MySQL. FriendFeed usa molto MySQL. NoSQL è un ottimo strumento, ma sicuramente non rappresenterà il tuo vantaggio competitivo, non renderà la tua app interessante e, soprattutto, ai tuoi utenti non importerà nulla di tutto ciò.
Su cosa costruirò la mia prossima app? Probabilmente Postgres. Userò NoSQL? Forse. Potrei anche usare Hadoop e Hive. Potrei tenere tutto in file flat. Forse inizierò a hackerare Maglev. Utilizzerò tutto ciò che è meglio per il lavoro. Se ho bisogno di rapporti, non utilizzerò alcun NoSQL. Se ho bisogno di memorizzare nella cache, probabilmente userò Tokyo Tyrant. Se ho bisogno di ACIDity, non userò NoSQL. Se ho bisogno di un sacco di contatori, userò Redis. Se ho bisogno di transazioni, userò Postgres. Se ho un sacco di un singolo tipo di documenti, probabilmente userò Mongo. Se avessi bisogno di scrivere 1 miliardo di oggetti al giorno, probabilmente userei Voldemort. Se ho bisogno di una ricerca full-text, probabilmente userei Solr. Se avessi bisogno di una ricerca full-text di dati volatili, probabilmente userei Sphinx.
Mi piace questo articolo, lo trovo molto istruttivo, offre una buona panoramica del panorama e del clamore di NoSQL. Ma, e questa è la parte più importante, aiuta davvero porsi le domande giuste quando si tratta di scegliere tra RDBMS e NoSQL. Vale la pena leggere IMHO.
