MongoDB o CouchDB: adatti alla produzione? [chiuso]

Mi chiedevo se qualcuno potesse dirmi se MongoDB o CouchDB sono pronti per un ambiente di produzione .

Sto ora esaminando queste soluzioni di archiviazione (al momento preferisco MongoDB), tuttavia questi progetti sono piuttosto giovani e quindi prevedo che dovrò lavorare abbastanza duramente per convincere il mio manager che dovremmo adottare questo nuova tecnologia.

Quello che mi piacerebbe sapere è:

1. Chi utilizza MongoDB o CouchDB oggi in un ambiente di produzione?

2. Come stai usando MongoDB / CouchDB?

3. Quali problemi hai riscontrato quando hai adottato questo nuovo meccanismo di archiviazione (e come li hai superati)?

4. Come hai affrontato i problemi di migrazione che hai dovuto affrontare?

5. Hai delle esperienze positive / negative con una di queste soluzioni che vorresti condividere?

Sono il CTO di 10gen (sviluppatori di MongoDB), quindi sono un po 'di parte, ma gestisco anche alcuni siti che utilizzano MongoDB in produzione.

businessinsider utilizza mongo in produzione da oltre un anno. Lo stanno usando per tutto, dagli utenti e post di blog, a ogni immagine del sito.

shopwiki lo sta usando per alcune cose tra cui analisi in tempo reale e un livello di memorizzazione nella cache. Stanno eseguendo oltre 1000 scritture al secondo su un database abbastanza grande.

Se vai alla pagina Distribuzioni di produzione mongodb vedrai alcune persone che usano mongo in produzione.

In caso di domande sulla portata o l'ambito delle distribuzioni di produzione, pubblicare sul nostro elenco utenti e saremo più che felici di aiutarti.

La BBC e meebo.com usano CouchDB in produzione e anche uno dei miei clienti. Ecco un elenco di altre persone che usano Couch: CouchDB in natura

La sfida principale è sapere come organizzare i documenti e smettere di pensare in termini di dati relazionali.

SourceForge utilizza MongoDB. Vedi questa presentazione o leggi qui .

Stiamo eseguendo CouchDB come sostituto di MySQL per i nostri negozi (70.0000 articoli / negozio, per un totale di 4 milioni di attributi di tutti gli articoli, collegamenti incrociati tra gli articoli).

I nostri obiettivi erano:

1. Facile replica da un master-db a diversi client con documenti diversi.

2. Dati precalcolati rapidi come "quante parti ho con questo attributo e quel filtro, adattandosi a quelle condizioni"

fatti:

1. I nostri negozi ora funzionano molto più velocemente rispetto a MySQL (e il database mysql ha richiesto 1-3 giorni di pre-calcolo (quindi l'aggiornamento è stato due volte al mese), rendendo i dati pronti per il conteggio e il filtro dei prodotti, CouchDB ha bisogno di 5 ore, quindi potremmo aggiornare i dati dei prodotti ogni notte)
2. L'impostazione della distribuzione dei dati (filtrata) e dei backup sui nodi del negozio è semplice e veloce

ma anche:

1. Comprendere mappa / ridurre e i limiti di non avere join è abbastanza difficile
2. Nessuna operazione su dati come "elimina dove" o "aggiorna dove" senza programmi esterni
3. La replica funziona bene, a meno che non ci sia un problema; quindi è davvero difficile scoprire qual è stata la ragione (per i principianti)
4. L'installazione di CouchDB senza binari (sì, ce ne sono alcuni in the wild, ma non per ogni sistema operativo / versione) potrebbe essere difficile, se non sei un fanatico di Linux. Ma la Community di CouchDB è utile (#couchdb), e fortunatamente ci sono aziende là fuori (cloudant, iriscouch) che offrono servizi da liberi a grandi aziende.
5. CouchDB sta andando avanti, quindi ci sono molte modifiche (miglioramenti) che potrebbero cambiare nel modo in cui lavori. Ma le cose di base rimangono stabili.

Di conseguenza: MySQL come database per la creazione e la gestione dei dati è affidabile, facile da capire e gestire. Penso che non cambieremo questo. Inoltre, non voglio perdere la potenza delle visualizzazioni CouchDB e la facilità di impostazione della replica.

I divani di produzione a volte causavano problemi dopo mesi di lavoro a causa di errata configurazione e logrotati dimenticati (la visualizzazione della vista richiede troppo tempo o si blocca, la replica si arresta), ma non ha mai perso i dati e potrebbe sempre essere facilmente ripristinata.

Sto usando CouchDB in produzione. Attualmente memorizza tutti quei campi 'opzionali' che non erano nello schema DB originale. E proprio ora sto pensando di spostare tutti i dati su CouchDB.

È un passo piuttosto rischioso, lo ammetto. Innanzitutto, perché non è ancora v1.0. E in secondo luogo, perché ha fame di spazio. Secondo i miei calcoli, il file CouchDB (con indici) è ~ 30 volte più grande del database MySQL con le stesse righe. Ma sono abbastanza sicuro che funzionerà bene.

CouchDB 0.11 (rilasciato alla fine di marzo) è una versione freeze per 1.0. Ciò significa che manterremo la compatibilità con l'attuale API per 1.0, quindi ora è un buon momento per dare un'altra occhiata a CouchDB se non lo fai da un po '.

La versione del codice sorgente di CouchDB 0.11 è disponibile qui. Ci sono installatori binari e altri gadget collegati qui.

Non so nulla di MongoDB, ma dalle FAQ di CouchDB :

CouchDB è pronto per la produzione?

Sì, vedi InTheWild per un elenco parziale di progetti che utilizzano CouchDB. Un'altra buona panoramica è Case Study di CouchDB

Inoltre, alcuni link:

• Ri: Stato CouchDB attuale?
• SimpleDB, CouchDB e altri "NUOVI" archivi dati - Feedback

Usiamo couchdb in produzione e da poco prima che il progetto passasse sotto l'ombrello di Apache.

Lo usiamo per archiviare tutto ciò che altrimenti potremmo usare un dbms, oltre a tutti i tipi di dati non strutturati. Personalmente, mi piace molto il modo in cui puoi semplicemente inserire tutti i tipi di dati e utilizzare le viste per eliminare ciò di cui non hai bisogno a seconda della situazione.

La parte più difficile si stava allontanando dalla mentalità dei dbms. Abbiamo scritto i nostri programmi di utilità per la migrazione quando il formato di archiviazione è cambiato solo per sicurezza, quindi non è stato un problema.

Non abbiamo ancora avuto esperienze negative, ma di nuovo non abbiamo avuto l'installazione sotto alcun tipo di carico enorme. Penso che le cose funzionerebbero abbastanza bene dal momento che abbiamo due server di tipo slave che si replicano da un singolo server master che ottiene tutte le scritture. Sono abbastanza sicuro che non dobbiamo farlo in questo modo per far funzionare correttamente la replica, ma è come l'abbiamo impostato all'inizio e si è bloccato.

Usiamo CouchDB per archiviare messaggi in entrata e in uscita mobili e per riferire su questo traffico tramite alcune visualizzazioni personalizzate che ho scritto. Il front-end è scritto in Python. Non abbiamo avuto problemi tecnici reali ed è attivo dalla fine di dicembre. L'unico ostacolo che ho incontrato è stato inizialmente pensare in termini di MapReduce, ma una volta che ho imparato a farlo, tutto il resto è andato liscio.

Attualmente stiamo utilizzando MongoDB in produzione come livello di memorizzazione nella cache, nonché motore di archiviazione per l'importazione e la manipolazione dei dati dei prodotti. Siamo una società di eCommerce che gestisce oltre due milioni di prodotti (oltre 100 milioni di attributi), che comprende oltre 10 distributori e senza MongoDB, questo compito sarebbe quasi impossibile.

Attualmente stiamo usando mongodb come servizio di archiviazione di file per la nostra collaborazione su LAN. Inoltre, progetti come trello utilizzano mongodb come archivio dati back-end. Ho usato couchdb prima, ma non in capacità di produzione.

Stiamo utilizzando MongoDB in produzione nel nostro servizio di backend mobile, ovvero Netmera. Lo stiamo usando per archiviare tutti i dati di utenti e contenuti.

Uso CouchDB in produzione da quasi 2 anni. Non c'è lavoro di migrazione poiché il progetto è iniziato direttamente con l'implementazione di CouchDB. Funge da database che memorizza i dati di un singolo prodotto elettronico dall'inizio fino al confezionamento.

Dal momento che stiamo vendendo sensori con una richiesta di alta precisione, facciamo molti test in diverse fasi e tutti questi saranno archiviati in un documento su CouchDB.

C'è una curva di apprendimento che ho imparato dalla mia esperienza, che è di sfruttare appieno le viste (o anche conosciute come viste permanenti). Le viste dovrebbero essere "piccoli filtri" di una frazione del database che verrà chiamata spesso.

Il mio databse di CouchDB non è pazzo come un'altra compagnia gigantesca. Ma finora, sto ancora bene. Attualmente sto avendo 24000 documenti a 700 MB.

La funzionalità di CouchDB che mi piace è "replica", "memorizza le revisioni di un documento".

Ho letto molte buone recensioni su MongoDB e vorrei provarlo se c'è una possibilità.

Stiamo usando mongodb in produzione per

www.beachfront.io - vicino a 5k richiesta di scrittura al secondo www.beachfrontbuilder.com - 500 richieste di lettura / scrittura al secondo, gestione di 10 milioni di dati utente e olap.

L'unica sfida affrontata per l'archiviazione dei dati è stata superata implementando il nostro componente personalizzato.

Questa domanda ha già accettato la risposta, ma ora un giorno un altro DB NoSQL è di tendenza per molte delle sue fantastiche funzionalità. Lo è Couchbase; che funziona come CouchbaseLitesu piattaforma mobile e Couchbase Serversul lato server.

Ecco alcune delle caratteristiche principali di Couchbase Lite.

Couchbase Lite è un motore di database leggero, orientato ai documenti (NoSQL) e sincronizzabile adatto per l'integrazione in app mobili.

Leggero significa:

Incorporato: il motore di database è una libreria collegata all'app, non un processo server separato. Dimensioni ridotte del codice: importante per le app mobili, che vengono spesso scaricate su reti cellulari. Tempo di avvio rapido: importante perché i dispositivi mobili hanno CPU relativamente lente. Basso utilizzo della memoria: i set di dati mobili tipici sono relativamente piccoli, ma alcuni documenti potrebbero avere allegati multimediali di grandi dimensioni. Buone prestazioni: le cifre esatte dipendono dai dati e dall'applicazione, ovviamente.

Orientato al documento significa:

Memorizza i record in formato JSON flessibile anziché richiedere schemi o normalizzazioni predefiniti. I documenti possono avere allegati binari di dimensioni arbitrarie, ad esempio contenuti multimediali. Il formato dei dati delle applicazioni può evolversi nel tempo senza la necessità di migrazioni esplicite. L'indicizzazione di MapReduce fornisce ricerche rapide senza la necessità di utilizzare linguaggi di query speciali.

Sincronizzabile significa:

Ogni due copie di un database possono essere sincronizzate tramite un algoritmo di replica efficiente, affidabile e comprovato. La sincronizzazione può essere su richiesta o continua (con una latenza di pochi secondi). I dispositivi possono sincronizzarsi con un sottoinsieme di un database di grandi dimensioni su un server remoto. Il motore di sincronizzazione supporta connessioni di rete intermittenti e inaffidabili. I conflitti possono essere rilevati e risolti, con la logica dell'app che ha il pieno controllo della fusione. Gli alberi di revisione consentono complesse topologie di replica, tra cui server-server (per più data center) e peer-to-peer, senza perdita di dati o falsi conflitti. Couchbase Lite fornisce API native per lo sviluppo continuo di iOS (Objective-C) e Android (Java). Inoltre, include il plug-in Couchbase Lite per PhoneGap,

Puoi esplorare di più su Couchbase Lite

e Couchbase Server

Questo sta per la prossima grande cosa.

Parlando di produzione, il failover / recupero senza soluzione di continuità richiede entrambi una baby sitter
1- Couchbase, non c'è failover / recupero senza soluzione di continuità, è necessario un intervento manuale.
il riequilibrio richiede troppo tempo, troppi rischi se si perde più di un nodo.

2- Mongo con i frammenti, il recupero dei dati dalla perdita di un server di configurazione, non è un compito facile

Adobe utilizza MongoDB per l'imminente rilascio di Adobe Experience Manager (precedentemente Day CQ ) come motore DB principale.

Numerosi clienti dell'agenzia presso cui lavoro utilizzano CouchDB su progetti per clienti di grandi dimensioni.

A mio avviso, entrambi sono DB validi e vitali. :)

Ecco un elenco di siti distribuiti di produzione con mongoDB

• The New Yorks Times : utilizzarlo in un'applicazione per la creazione di moduli per l'invio di foto. La mancanza di schema di Mongo offre ai produttori la possibilità di definire qualsiasi combinazione di campi modulo personalizzati.
• SourceForge : viene utilizzato per l'archiviazione back-end nelle prime pagine di SourceForge, nelle pagine dei progetti e nelle pagine di download per tutti i progetti.
• Bit.ly
• Etsy
• IGN : supporta le analisi del traffico in tempo reale di IGN e le API di contenuto RESTful.
• Justin.tv : potenzia gli strumenti di analisi interna di Justin.tv per la viralità, la fidelizzazione degli utenti e le statistiche generali di utilizzo che le soluzioni pronte all'uso non sono in grado di fornire.
• Posterous
• Intuit
• Foursquare : i database Sharded Mongo vengono utilizzati per la maggior parte dei dati su foursquare.
• Business Insider : utilizzandolo dall'inizio del 2008. Tutti i dati del sito, inclusi post, commenti e persino le immagini, sono archiviati su MongoDB.
• Github : viene utilizzato per un'applicazione di reporting interna.
• Examiner : migrato il loro sito da Cold Fusion e SQL Server a Drupal 7 e MongoDB.
• Grooveshark : attualmente utilizza Mongo per gestire oltre un milione di sessioni utente uniche al giorno.
• Buzzfeed
• disco
• Evite : utilizzato per analisi e report rapidi.
• Squarespace
• Shutterfly : viene utilizzato per vari requisiti di archiviazione dei dati persistenti all'interno di Shutterfly. MongoDB aiuta Shutterfly a costruire un servizio senza rivali che consente relazioni più profonde e personali tra i clienti e coloro che contano di più nella loro vita.
• Topsy
• Condividi questo
• Mongohq : fornisce una piattaforma di hosting per MongoDB e utilizza MongoDB come back-end per il suo servizio. La nostra pagina dei centri di hosting fornisce ulteriori informazioni su MongoHQ e altre opzioni di hosting MongoDB.

e altro ancora ...

Estratto da: http://lineofthought.com/tools/mongodb

È possibile controllare anche altri database o strumenti.

MongoDB ha alcuni problemi con le licenze alle imprese, non sono sicuro dei dettagli, ma il nostro ufficio legale ci ha detto in nessun modo che non ci era permesso usare MongoDB in nessuno dei nostri prodotti.