Evitare il rischio di perdere dei dati, poter scalare con le performance e superare la limitazione di funzionalità che rallenta lo sviluppo di applicazioni, queste alcune delle ragioni principali che spingono i clienti MongoDB a passare a Couchbase.

Le carenze critiche di MongoDB ed il modo in cui Couchbase le supera

MongoDB

La replica master-slave di MongoDB determina nodi inattivi e un basso utilizzo dell'hardware. Tutti i servizi MongoDB condividono le stesse risorse, rendendo impossibile isolare i carichi di lavoro: l'errore di un servizio blocca l'intera operatività.

Gli ambienti single-node (no shard) e multi-node (sharded), richiedono modelli di sviluppo delle applicazioni diversi, il che determina oneri aggiuntivi nel passaggio da un ambiente all'altro, necessario per la scalabilità.

La shard key deve è un elemento progettuale di scelta assai critico, perchè impone di prevedere andamenti futuri che se errati penalizzano le performance o, peggio, costringono alla ricreazione delle collezioni di documenti così frammentati.

Couchbase

Couchbase è stato progettato come un database distribuito senza master, clusterizzato e replicato sin dal primo giorno: tutti i nodi possono leggere e scrivere.

Tutti gli utenti beneficiano del clustering e del riequilibrio dei dati fra i nodi del cluster, con miglioramenti alla sicurezza dei dati. La scalabilità multidimensionale (MDS) consente di scalare ogni servizio in modo indipendente in funzione del carico di lavoro, in totale isolamento uno dall'altro.

Il comportamento dell'applicazione rimane invariato sia che si utilizzi un singolo nodo (tipico dell sviluppo), o si passi a 3 nodi (tipico della fase di test pre-rilascio) o la si utilizzi con 20 nodi di produzione in un cloud, il tutto con miglioramenti delle prestazioni scalabili.

MongoDB

La funzionalità di cache delle pagine di MongoDB non funziona bene e richiede strumenti di terze parti per ottenere prestazioni elevate (spesso viene utilizzato Redis). Altri fattori riducono anche le prestazioni del database, inclusi livelli di routing inefficienti che aggiungono complessità e latenza alle richieste. A causa delle rigide limitazioni di partizionamento dei dati e degli indici, per alcune query sono necessari metodi lenti di raccolta sparsa tra nodi. Questo approccio limita le prestazioni delle query, specialmente su cluster di grandi dimensioni.

Couchbase

Couchbase ha uno strato di cache attentamente gestito e completamente integrato per dati e indici, senza la necessità di ulteriori prodotti di cache per prestazioni elevate. Il routing intelligente con la ricerca diretta di documenti da applicazione a nodo, consente comunicazioni efficienti con un singolo accesso alla rete. Gli indici globali consentono di partizionare gli indici indipendentemente dai dati, riducendo al minimo la latenza per query importanti.

MongoDB

MongoDB ha diverse funzionalità che sono frutto di aggiunte successive al di fuori del core principale, tra cui replica, sharding, ricerca full-text limitata e analisi basate su SQL: questo si riflette in termini di maggior complessità nella progettazione e nello sviluppo delle applicazioni. Sono richiesti sviluppatori dedicati perché MongoDB ™ utilizza un linguaggio proprietario unico per le query, con tempi di apprendimento più lunghi rispetto ad un SQL standard.

Gli ambienti frammentati hanno limiti di funzionalità. Le funzioni di tipo serverless e la sincronizzazione mobile sono disponibili solo tramite l'offerta Atlas in cloud.

Couchbase

Couchbase dispone di API unificate per applicazioni e gestione, che consentono la ricerca di documenti, query strutturate, ricerca full-text, analisi e trigger, offrendo agli sviluppatori un facile accesso a tutte le funzionalità, comprese quelle di sicurezza e gestione. Il linguaggio di query basato su SQL sfrutta le competenze che gli utenti dei classici db relazionali hanno già, così da semplificarne l'adozione. Tutte le funzionalità sono disponibili su tutti i modelli di distribuzione: locale, container e cloud.

Couchbase sfrutta la sitassi SQL per semplificare le Query (e riusare i tuoi skill...)

Se volessimo conoscere il valore delle transazioni relative a Google ed Apple presenti in un nostro db.stock:

MongoDB Query

db.stocks.aggregate([
        { "$match": {
                "$and": [
                    {"symbol": {
                            "$in": [
                                "AAPL",
                                "GOOG"]}},
                    { "value": {
                            "$gt": 0 }}]}},
        { "$group": {
                "_id": {
                    "symbol": "$symbol" },
                "sum(value * volume)": {
                    "$sum": {
                        "$multiply": [
                            "$value",
                            "$volume"]}}}},
        { "$project": {
                "_id": 0,
                "sum(value * volume)": "$sum(value * volume)",
                "symbol": "$_id.symbol"}}
        { "$sort": {
                "sum(value * volume)": -1,
                "symbol": 1 }}]})

Couchbase N1QL

SELECT SUM(value * volume) AS val, symbol
FROM   db.stocks
WHERE  symbol IN ( "AAPL", "GOOG" ) AND value > 0
GROUP  BY symbol
ORDER  BY val DESC, symbol ASC

Perché le aziende scelgono Couchbase su MongoDB

Gli spettatori di oggi richiedono un'esperienza senza soluzione di continuità e una costante innovazione. Trovando MongoDB difficile da usare e scalare, DirectTV ha scelto Couchbase per la sua ineguagliabile capacità di scalare, la replicazione cross datacenter bidirezionale per mantenere i servizi per gli utenti disponibili 24x7 e N1QL per potenti query

Poichè l'accoppiata MongoDB e Redis non riuscivano più a supportare il ritmo di crescita della sua piattaforma di messaggistica, Viber è passata a Couchbase. Ora è in grado i garantire quasi un milione di operazioni al secondo e dataset con miliardi di record, in un ambiente così robusto da ridurre il tempo complessivo di indisponibilità e tagliare del 50% il numero dei server necessari

Nunace, a speech recognition and imaging software company, era consapvole che il suo ambiente monolitico, basato su Oracle, era costoso da scalare e per niente flessibile con la variabilità dei loro dati. Esplorando i NoSQL. trovarono MongoDB difficile da amministrare, così scelsero Couchbase: per la semplicità, le performance scalabili proporzionali al costo e, aspetto non secondario, la replicazioni cross-datacenter bidirezionale

Staples dovevano gestire il loro catalogo B2B online, usando 1.6 billion di regole da applicare in realtime. Hanno provato a farlo con MongoDB, ma la sua incapacità a scalare facilmente ed in modo affidabile ha fatto cancellare il progetto e passare a Couchbase, che non solo ha consentito a Staples di semplificare il proprio catalog management, grazie a N1QL e JSON, ma ha anche notevolmente migliorato le performance del db e la sua affidabilità