2011-09-15 15 views
8

Qualcuno ha avuto esperienza con MonetDB? Attualmente, ho un database MySQL che sta diventando troppo grande e le query stanno diventando troppo lente. Secondo il paradigma orientato alle colonne, le inserzioni saranno più lente (cosa che non mi dispiace affatto), ma il recupero dei dati diventa molto veloce. Ho la possibilità di ottenere più prestazioni di recupero dei dati semplicemente passando a MonetDB? MonetDB è abbastanza maturo?Vale la pena provare MonetDB?

+1

Qualsiasi benchmark che confronti MonetDB contro Hyperdex, Aerospike, DynamoDB, Voldermort, VoltDB o ExtremeDB? – skan

+0

Mi chiedo se non hai provato MonetDB? Se la prestazione è buona per te? – carfield

risposta

16

Hai la possibilità di migliorare le prestazioni della tua applicazione. Il guadagno, tuttavia, dipende in gran parte dal carico di lavoro, dalle dimensioni del database e dall'hardware. MonetDB è sviluppato/messo a punto sotto due ipotesi principali:

  1. Il tuo carico di lavoro è analitico, cioè hai un sacco di aggregazioni (raggruppate) e simili.
  2. Ancora più importante: il set di dati hot (i dati con cui lavori effettivamente) si inserisce nella memoria principale del tuo sistema. MonetDB non ha il proprio Buffer Manager ma si affida al sistema operativo per gestire l'I/O del disco. Poiché il sistema operativo (in particolare Windows ma anche Linux) è a volte molto stupido riguardo allo scambio di dischi che può diventare un problema (specialmente per i join che esauriscono la memoria).

Per quanto riguarda la maturità, ci sono probabilmente più opinioni su questo rispetto alle persone che abitano questo pianeta. Personalmente, lo trovo abbastanza maturo, ma sono un membro del team di sviluppo e, quindi, di parte. Ma MonetDB è un progetto di ricerca, quindi se hai un'applicazione interessante ci piacerebbe sentirne parlare e vedere se possiamo aiutarti.

+0

Qualche ulteriore descrizione: supponiamo che la mia tabella contenga questi campi (nome, data di nascita, social_security_id, drivers_licence_id, annual_income), voglio essere in grado di farlo: selezionare * da persone dove nome> "M" e birth_date tra DATE1 e DATE2 e annual_income tra 10 e 100; E voglio essere in grado di ordinare da uno di questi campi. Tutte queste gamme stanno uccidendo le prestazioni se il tavolo diventa davvero grande. Ho la sensazione che MonetDB non possa aiutare molto in questo caso, ma se c'è una piccola possibilità, farò un tentativo. – martincho

+1

Bene, direi che dipende dalla dimensione dei risultati intermedi (cioè il numero di tuple che si qualificano per ciascuna condizione). Se i loro ID (interi interni a 64 bit) si adattano alla memoria principale, dovrebbe andare bene. In caso contrario, potrebbe comunque funzionare in modo decente se si omette "ordine per".Una cosa da notare su MonetDB è che tutte le operazioni sono implementate in modo molto efficiente, ma tutti i risultati intermedi sono materializzati nella memoria principale (o potenzialmente su disco) che può uccidere le prestazioni se non si dispone di RAM sufficiente. Direi che potresti provare MonetDB. – Holger

+0

"Fit in RAM" compresso o non compresso? Voglio dire, dovrei avere abbastanza RAM per adattarsi a tutti i contenuti della cartella "dbfarm"? (parlando di un database con un grande tavolo). Grazie – GBrian

4

La risposta ovviamente dipende dal carico utile ma la mia esperienza fino ad ora sembrerebbe indicare che su MonetDB tutto è più veloce di quanto abbia visto in MySQL. L'eccezione sarebbe l'unione, che non solo sembra lenta, ma sembra completamente inetta al pipelining, quindi finisci per aver bisogno di sprazzi di memoria per elaborare quelli grandi. Detto questo, la mia esperienza con i join in MySQL non è stata esattamente stellare, quindi suppongo che le tue aspettative possano essere basse. Se vuoi davvero una buona performance di join, probabilmente raccomanderei SQL Server o qualcosa di simile; per quelle altre domande che hai citato nei commenti di follow-up, MonetDB dovrebbe essere fantastico.

Ad esempio, data una tabella con circa 2 milioni di righe, è stato possibile eseguire l'intervallo su una colonna (dove c'erano circa 800K righe nell'intervallo) e ordinare da un'altra colonna e il risultato limitato è stato elaborato e restituito in 25ms. Le prestazioni di questo tipo di query sembrano peggiorare con la scala, ma questo dovrebbe darti un assaggio di ciò che potresti aspettarti a quella scala.

Devo mettere in guardia sul fatto che l'ottimistico modello di concorrenza potrebbe eliminare quelli che sono stati esposti solo a concorrenza pessimistica (la maggior parte delle persone). Lo farei prima di chiedermi perché alcuni dei tuoi commit falliscono sotto carico simultaneo.

+0

Direi che molte persone hanno familiarità con il modello OCC poiché la maggior parte degli ORM lo fa. La concorrenza pessimistica e MVCC d'altro canto la maggior parte delle persone non ha familiarità con esso (MySQL non lo supportava in origine e la maggior parte delle app Web non aziendali sono prive di transazioni e alcune ORMS non supportano nemmeno il blocco di riga/tabella). –