Suggerimenti di database per una comunità di social network / knowledge base?

Sto cercando vari tipi di database e DBMS per un nuovo progetto che voglio iniziare in estate.

Ho creato sistemi in MySQL e postgreSQL, ora voglio espandere la mia conoscenza ed esperienza nei database.

Il mio progetto sarà un tipo di social network / conoscenza aggregata. (non ha ancora sviluppato un termine per descriverlo ancora).

Ho visto:

• Cassandra (usa il proprio tipo di linguaggio di query); Sembra essere buono per contenuti ricchi di funzionalità e per fornire l'esecuzione di query ad alte prestazioni. Tuttavia, non mi interessa molto perché richiede un ambiente Java su cui lavorare e preferirei non avere nulla a che fare con Oracle.
• MongoDB (tipo di DBMS noSQL); grande scalabilità, tuttavia si perdono tutte le funzionalità già disponibili sul comprovato linguaggio SQL come le query di informazioni aziendali.

Requisiti del sistema:

• Testo dati , date, orari, xml, piccoli ints, blob,
• Struttura / comportamento : 3NF normalizzato, non in tempo reale, relazionale, scalabile, robusto
• Ambiente: unix / linux, no JAVA !, preferibilmente eseguito su C

Mi chiedevo se potevi indicarmi qualsiasi altro sistema di database su cui avrei dovuto cercare.

Ho anche dato un'occhiata ai database relazionali di oggetti, mi piace l'idea che funzionino con oggetti PHP (PDO), tuttavia le loro prestazioni sembrano un po 'scadenti.

Visto che ci saranno DBA qui, qualsiasi feedback su questi sistemi che hai operato sarebbe apprezzato.

Grazie

I tuoi requisiti astratti mi gridano "PostgreSQL". Tuttavia, penso che valga la pena rimanere al passo con ciò che la borghesia sta facendo, quindi ecco un elenco di varie cose che potresti voler controllare.

Roba gratis

• CouchDB - uno dei primi database NoSQL, potente sistema di mappatura / riduzione delle query, altamente distribuito e tollerante ai guasti. Uno dei migliori contendenti NoSQL.
• Hyperdex : nuovissima tabella hash distribuita con funzionalità di ricerca.
• Riak - tabella hash distribuita degna di rispetto.

Strane cose gratis

• Metakit : più di un database incorporato come SQLite ma non basato su SQL, quindi più procedurale.
• FramerD - molto simile a un classico database "di rete", molto orientato al puntatore. Forse morto?
• Magma - Smalltalk OODBMS. Fresco ma non ben documentato.

Roba non gratuita

• AllegroGraph - Database RDF (grafico), supporta SPARQL. Lisp al gusto.
• Caché - un database relazionale / OO ibrido, originariamente basato su MUMPS (IIRC).
• Obiettività - Uno degli ultimi OODB davvero grandi. Molto potente, impressionante e costoso.
• VoltDB - Database relazionale prevalentemente scalabile. Supporta "most" SQL. Molto nuovo. Immagino che abbiano anche una versione della community.

Conclusione

Non ho usato nessuna di queste cose ampiamente. Ho giocato un po 'con la maggior parte di loro e sono sempre tornato con PostgreSQL. Considerando le tue esigenze, l'unico PostgreSQL che non soddisfa immediatamente è la scalabilità. D'altra parte, per i miei scopi è molto più facile lanciare $ 4000 di hardware su un singolo computer di database dedicato piuttosto che lanciare $ 4000 di nodi cloud o macchine di fascia bassa a questo problema. E ci sono modi per raggiungere la scalabilità con PostgreSQL, come con EnterpriseDB .

È molto divertente giocare con queste cose a parte, ma quando arriva il momento di mettere in valore dati di produzione preziosi e irreprensibili, emergono una serie di attributi noiosi come affidabilità, stabilità e fattibilità a lungo termine.

Esperimento di pensiero per te

Considera questo. Immagina di essere Mark Zuckerberg e devi scegliere di rinunciare alla tua base di codice o ai tuoi dati. Puoi mantenere tutto il tuo personale di sviluppo, ma o devi rinunciare a tutto il tuo codice - ogni riga, dire anche a tutti i ricordi degli sviluppatori di come hanno implementato tutto è sparito - ma puoi mantenere tutti i tuoi account utente e tutti i tuoi utenti caricati dati e tutto il resto, oppure puoi rinunciare a tutti i dati. Mantieni tutte le strutture, i server e la configurazione, l'installazione, ma perdi ogni riga in ogni tabella in ogni database.

Dovrebbe essere ovvio che sarebbe peggio perdere i dati. Perché tutti i tuoi utenti dovrebbero rigenerare tutti quei dati? Pensa a tutti i dati di marketing persi, ed è così che Facebook guadagna davvero. E ci sono tonnellate di imprenditori entusiasti all'opportunità di indurre le persone a usare il loro clone di Facebook: ora tutti quegli utenti ex-Facebook senza diritto di voto sarebbero là fuori a considerare alternative. D'altro canto, se perdessero la base di codice, potrebbero ricostruirla, probabilmente anche meglio di quanto non sia ora, ma potrebbero avere qualcosa online in un ordine molto breve. Cavolo, probabilmente potrebbero comprarela base di codice clone di qualcun altro di Facebook e caricarla con i dati reali, ma non puoi semplicemente copiare i loro dati. Se Facebook ha ancora i dati importanti di tutti sui propri server, l'incentivo a partire è molto più basso. Ancora male, ma molto meno. Sorprendentemente meno.

L'ironia è che è molto più facile perdere tutti i tuoi dati in un incidente strano che perdere tutto il tuo codice. Per la maggior parte delle società di Internet, tuttavia, i dati sono l'azienda, è la risorsa più preziosa. E questo è un valido motivo per considerare l'uso di un database relazionale tradizionale, testato nel tempo, vecchio stile, non sexy.

Considera anche che non vi è alcun motivo per cui non è possibile utilizzare un database relazionale per alcune cose e il database nosql per altre cose.

A proposito di nosql, ho solo 1 cosa da aggiungere sul riferimento di Facebook:

Se prevedi di ridimensionare molto, ti suggerisco di ottenere un motore DB sysadmin amichevole contro lo sviluppatore.

Esci da MongoDB amichevole e super veloce per gli sviluppatori che non può ridimensionare geograficamente la dispersione e non ha modo di eseguire il backup in modo efficiente e facile. Anche se qui usiamo MongoDB, sembra che Riak o CouchDB abbiano un aspetto migliore nelle specifiche per gli amministratori di sistema (non ho esperienza con Riak o CouchDB)