Quali sistemi di database dovrebbero prendere in considerazione una società startup?

Question

In questo momento sto sviluppando il prototipo di un'applicazione Web che aggrega un numero elevato di voci di testo da un numero elevato di utenti. Questi dati devono essere spesso visualizzati e spesso aggiornati. Al momento memorizzo il contenuto all'interno di un database MySQL e utilizzo il layer ORM di NHibernate per interagire con il DB. Ho una tabella definita per utenti, ruoli, invii, tag, notifiche e così via. Mi piace questa soluzione perché funziona bene e il mio codice sembra bello e sano, ma sono anche preoccupato di come MySQL si esibirà una volta che le dimensioni del nostro database raggiunge un numero significativo. Sento che potrebbe essere difficile eseguire le operazioni di join abbastanza velocemente.

Questo mi ha fatto pensare a sistema di database non relazionali come MongoDB, CouchDB, Cassandra o Hadoop. Sfortunatamente non ho esperienza con nessuno dei due. Ho letto alcune buone recensioni su MongoDB e sembra interessante. Sono felice di passare il tempo e imparare se si scopre che è la strada da percorrere. Gradirei molto qualcuno che offra punti o problemi da considerare quando si va con nessun dbms relazionale?

Answer 1

Le altre risposte qui si sono concentrati principalmente sugli aspetti tecnici, ma penso che ci sono importanti punti da effettuare che si concentrano sulla all'avvio società aspetto delle cose:

• Availabililty di talento. MySQL è molto comune e probabilmente troverai più facile (e soprattutto più economico) trovare gli sviluppatori, rispetto ai sistemi di database più rari. Questa più ampia base di sviluppatori significherà anche più tutorial, una comunità di supporto più attiva, ecc.
• Facilità di sviluppo. Anche in questo caso, poiché MySQL è così comune, troverete che è il db di scelta per molti sistemi/servizi. Questo terreno comune può rendere un po 'più semplice qualsiasi integrazione esterna.
• Ti stai preparando per una situazione che potrebbe non esistere mai ed è gestibile se lo fa. Pochissime aziende (non sempre le startup) si avvicinano ai limiti di MySQL e con il dovuto rispetto (e sto solo indovinando); la probabilità che la tua startup colpirà il tipo di throughput dei dati per paralizzare un db MySQL ben strutturato e ben attrezzato è quasi zero.

In sostanza, non spendere il vostro tempo (== denaro) preoccuparsi di quale db da utilizzare, come MySQL in grado di gestire un sacco di dati, è ben collaudato e ben supportato.

Tornando al lato tecnico delle cose ... qualcosa che avrà un gran lunga maggiore impatto sulla velocità della vostra applicazione di scelta di db, è il modo in modo efficiente i dati possono essere memorizzati nella cache . Una cache efficace può avere effetti drammatici sulla riduzione del carico del database e sull'accelerazione della reattività generale di un'app. Trascorrerei il tuo tempo a esaminare le soluzioni di memorizzazione nella cache e assicurandoti che stiate sviluppando la vostra app in modo tale da poter utilizzare al meglio tali soluzioni.

FYI, la mia soluzione di caching preferita è memcached.

Answer 2

Quale pensi sia una quantità significativa di dati? MySQL, e fondamentalmente la maggior parte dei motori di database relazionali, può gestire una grande quantità di dati, con indici appropriati e schemi di database sensati.

Perché non provare come si comporta MySQL con una maggiore quantità di dati nella configurazione? Crea alcuni script che generano dati realistici nel database di test MySQL e genera un carico sul sistema e verifica se è abbastanza veloce.

Solo quando non è abbastanza veloce, iniziare innanzitutto considerando l'ottimizzazione del database e il passaggio a un altro motore di database.

Prestare attenzione a NHibernate, è facile creare una soluzione che sia piacevole e facile da codificare, ma presenta prestazioni non buone con una grande quantità di dati. Ad esempio, se utilizzare il recupero pigro o avido con associazioni dovrebbe essere attentamente considerato. Non voglio dire che non dovresti usare NHibernate, ma assicurati di capire come funziona NHibernate, ad esempio cosa significa "n + 1 seleziona" -problema.

Answer 3

Misura, non assumere.

I database relazionali e i database NoSQL possono entrambi scalare enormemente, se l'applicazione viene scritta correttamente in ciascun caso e se il sistema su cui viene eseguito viene sintonizzato correttamente.

Quindi, se si dispone di un caso d'uso per NoSQL, codice ad esso. Oppure, se ti senti più a tuo agio con la relazionalità, esegui il codice. Quindi, misurare quanto bene si comporta e come si scala, e se è OK, andare con esso, se non, analizzare il perché.

Solo una volta compreso il problema delle prestazioni dovresti andare alla ricerca di tecnologie esotiche, a meno che tu non stia bene con quella tecnologia o desideri provarla per qualche altro motivo.

Answer 4

Finora nessuno ha menzionato PostgreSQL come alternativa a MySQL dal lato relazionale. Sappi che le librerie MySQL sono GPL pure, non LGPL. Questo potrebbe costringerti a rilasciare il tuo codice se ti colleghi a loro, anche se forse qualcuno con più esperienza legale potrebbe dirti meglio le implicazioni. D'altra parte, il collegamento a una libreria MySQL non è la stessa cosa che basta connettersi al server e impartire comandi, è possibile farlo con closed source.

PostreSQL è in genere la migliore sostituzione gratuita di Oracle e la licenza BSD dovrebbe essere più conveniente per le aziende.

Poiché si preferisce un database non relazionale, si consideri che la transizione sarà più drammatica.Se è necessario personalizzare il database, è necessario considerare anche il fattore del tipo di licenza.

Ci sono tre cose che realmente hanno un impatto profondo su cui uno è la scelta migliore del database e non accennate:

1. La dimensione dei dati o se avete bisogno di memorizzare i file all'interno del database.
2. Un numero enorme di letture e pochissime (anche ristrette) scritture. In questo caso più di un database è necessaria una directory come LDAP
3. L'importanza della distribuzione e/o della replica dei dati. La maggior parte dei database relazionali può essere più o meno ben replicata, ma a causa del loro concetto/design non gestisce anche la distribuzione dei dati ... ma gestirai quanti più dati non si adattano a un server o hanno diritti di accesso che richiedono speciali separazioni/server extra?

Tuttavia la maggior parte delle persone andrà per un database non relazionale solo perché a loro non piace imparare SQL

Answer 5

Ti suggerisco di provare ogni db e scegliere quello che rende più facile sviluppare la tua applicazione. Vai a http://try.mongodb.org per provare MongoDB con un semplice tutorial. Non preoccuparti tanto della velocità dato che all'inizio il tempo di sviluppo è più prezioso del tempo della CPU.

So che molti utenti MongoDB sono stati in grado di abbandonare il loro ORM e il loro livello di memorizzazione nella cache. Il modello dati di Mongo è molto più vicino agli oggetti con cui lavori rispetto alle tabelle relazionali, quindi di solito puoi semplicemente archiviare direttamente gli oggetti così come sono, anche se contengono elenchi di oggetti nidificati, come un post di blog con commenti. Inoltre, poiché mongo è abbastanza veloce per la maggior parte dei siti così com'è, è possibile evitare di gestire le complessità della memorizzazione nella cache e generalmente fornire un sito più in tempo reale. Ad esempio, Wordnik.com reported 250.000 letture/sec e 100.000 inserti/sec con un DB oggetto da 1,2 TB/5 miliardi.

Ci sono alcuni modi per connettersi a MongoDB da Net, ma non ho abbastanza esperienza con quella piattaforma di sapere che è meglio:

• Norm: http://wiki.github.com/atheken/NoRM/
• MongoDB-CSharp: http://github.com/samus/mongodb-csharp
• Simple-MongoDB: http://code.google.com/p/simple-mongodb/

Disclaimer: io lavoro per 10gen su MongoDB, quindi sono un po 'prevenuto.