DB con le prestazioni migliori inserti/sec?

Distribuiamo un Instant Messenger (basato su AJAX) che è servito da un server Comet. Abbiamo l'obbligo di archiviare i messaggi inviati in un DB per scopi di archiviazione a lungo termine al fine di soddisfare i requisiti di conservazione legale.DB con le prestazioni migliori inserti/sec?

Quale motore DB offre le prestazioni migliori in questo requisito di scrittura una sola volta, mai letto (con rare eccezioni)?

Abbiamo bisogno di almeno 5000 inserti/sec. Suppongo che né MySQL né PostgreSQL possano soddisfare questi requisiti.

Qualche proposta per una soluzione ad alte prestazioni? HamsterDB, SQLite, MongoDB ...?

fonte

2010-08-19 Nenad

Sono in procinto di ristrutturare alcune applicazioni in mongoDB. Hai dimenticato CouchDB nella tua lista, ma da quello che ho imparato, opterei anche per mongoDB ... – polemon

Grazie, significa che sarei con MongoDB sulla giusta strada, altri voti per MongoDB? :-) – Nenad

Nei miei test non recenti, ho raggiunto 14K tps con MySQL/Innodb sul server quad-core e il throughput è stato cpu-bound in python, non mysql. In altre parole, la tua ipotesi su MySQL era abbastanza sbagliata. Le mie transazioni sono state abbastanza semplici da testare e inserire con la contesa, penso che "King of the Hill" abbia giocato tra molti utenti. –

Se siete mai andare a interrogare i dati, quindi non vorrei conservarlo in un database a tutti, non si sarà mai battere la performance del solo loro scrittura su un file flat.

Ciò che si vorrebbe considerare sono i problemi di ridimensionamento, cosa succede quando si tratta di rallentare la scrittura dei dati in un file flat, si investe in dischi più veloci o qualcos'altro.

Un'altra cosa da considerare è come scalare il servizio in modo che è possibile aggiungere più server senza dover coordinare i registri di ciascun server e consolidarli manualmente.

modifica: hai scritto che vuoi averlo in un database, e poi vorrei prendere in considerazione anche i problemi di sicurezza con l'odio dei dati on line, cosa succede quando il tuo servizio viene compromesso, vuoi che i tuoi aggressori siano in grado di alterare la storia di ciò che è stato detto?

Potrebbe essere più intelligente per memorizzare temporaneamente in un file, e poi dump in un luogo fuori sede che non è accessibile se i vostri fronti Internet ottiene hacked.

fonte

2010-08-19 08:40:42

Questo è un motivo in più per un sistema DB, la maggior parte di questi aiuterà a essere in grado di ridimensionarli senza problemi. Al momento il mio preferito è MongoDB, ma mi chiedo se un altro sistema DB può fornire più Insert/sec – Nenad

in realtà, i file di registro con rotazione dei log è un'arte risolta. Il dimensionamento affidabile del database viene risolto solo a prezzi di fascia alta del mercato, e anche in questo caso la mia esperienza personale suggerisce che di solito è mal configurata e non funziona correttamente. I file flat saranno molto più veloci, sempre. – Will

vecchio, ma il risultato top 5 in google .. Sto considerando questo su un progetto al momento, installazione simile .. non dimenticare, un database è solo un file flat alla fine della giornata pure, così tanto tempo sai come diffondere il carico .. individuare e accedere al proprio metodo di archiviazione .. È un'opzione molto valida .. Quindi devo essere d'accordo con la dichiarazione di cui sopra. La pratica comune ora è quella di memorizzare i dati JSON, in questo modo è possibile serializzare e accedere facilmente alle informazioni strutturate. I database hanno il loro posto, ma se stai facendo un archivio ... questo è il modo di farlo. – Mayhem

Se non è necessario eseguire query, il database non è ciò di cui si ha bisogno. Usa un file di registro.

fonte

2010-08-19 08:39:02 jmz

Ho scoperto che siamo in grado di gestire i dati più facilmente con un sistema DB, non interrogare i dati per la nostra app Web, ma se c'è qualche indagine sulla legge, dobbiamo essere in grado di fornire i dati richiesti, significa che userà meno tempo per raccoglierlo. – Nenad

Anche io andrei a cercare una soluzione basata su file di testo. Per cercarli puoi usare strumenti a riga di comando come grep o semplici elaborazioni del testo. Il tempo impiegato per ridimensionare un DBMS per questo lavoro sarà molto più che scrivere piccoli script per analizzare i file di log, specialmente se si dispone di un file di registro strutturato in modo decente. Se è per scopi legali: un file di testo su un CD/DVD sarà ancora leggibile in 10 anni (purché il disco stesso non sia danneggiato), sei sicuro che i dump del database saranno? –

Comprendere il compromesso. L'ultima query potrebbe accadere una volta o non esserlo affatto. Quanto tempo vuoi dedicare ad ottimizzare, considerando che potresti non conoscere nemmeno la richiesta esatta? È spesso fattibile e legalmente ragionevole avere tutti i dati necessari e interrogarli manualmente quando arriva una richiesta di polizia. – MSalters

Se il denaro non svolge alcun ruolo, è possibile utilizzare Times Times. http://www.oracle.com/timesten/index.html

Un database completo in memoria, con velocità sorprendente.

fonte

2010-08-19 08:43:25 BitKFu

Ho dimenticato di menzionare che abbiamo un budget limitato :-) – Nenad

Eh, se vuoi una soluzione in memoria, salva i tuoi $$. Utilizzare qualcosa come mysql ma specificare che le tabelle utilizzano il motore di memoria MEMORY e quindi configurare un server slave per replicare le tabelle di memoria su una tabella myisam non indicizzata. problema risolto e $$ salvato. – Timothy

L'ultima volta che ho provato a fare qualcosa di spiritoso ho avuto problemi con la limitazione dei record sulla tabella di memoria, ma il problema più grande era la mancanza di prestazioni con blocco/sblocco di questa tabella quando viene utilizzata con più thread. – Nenad

Vorrei utilizzare il file di registro per questo, ma se si deve utilizzare un database, mi raccomando Firebird. Ho appena testato la velocità, inserisce circa 10k di record al secondo su hardware abbastanza medio (computer desktop di 3 anni). La tabella ha un indice composto, quindi credo che avrebbe funzionato ancora più veloce senza di essa:

[email protected]:~$ fbexport -i -d test -f test.fbx -v table1 -p ** 
Connecting to: 'LOCALHOST'...Connected. 
Creating and starting transaction...Done. 
Create statement...Done. 
Doing verbatim import of table: TABLE1 
Importing data... 
SQL: INSERT INTO TABLE1 (AKCIJA,DATUM,KORISNIK,PK,TABELA) VALUES (?,?,?,?,?) 
Prepare statement...Done. 
Checkpoint at: 1000 lines. 
Checkpoint at: 2000 lines. 
Checkpoint at: 3000 lines. 
...etc. 
Checkpoint at: 20000 lines. 
Checkpoint at: 21000 lines. 
Checkpoint at: 22000 lines. 

Start : Thu Aug 19 10:43:12 2010 
End  : Thu Aug 19 10:43:14 2010 
Elapsed : 2 seconds. 
22264 rows imported from test.fbx.

Firebird è open source e completamente gratuito anche per progetti commerciali.

fonte

2010-08-19 08:46:38

Non sono realmente aggiornato con i sistemi RDBMS, ma l'ultima volta circa 4 anni prima quando tocco Firebird era il RDBMS più lento disponibile per Inserts. Se non sbaglio, MongoDB è circa 5 volte più veloce per Inserts e Firebird. – Nenad

Firebird è un buon DBMS, ma se si utilizza un DBMS, scegliere PostgreSQL su Firebird in qualsiasi momento. La comunità di PostgreSQL è più attiva di Firebird e ha cicli di rilascio programmabili. Il più grande svantaggio di Firebird è il manuale non strutturato. Se è necessario trovare una funzione/funzione specifica, è necessario prima passare attraverso i manuali di Interbase e quindi attraverso ciascuna (!) Delle note di rilascio da allora. Non esiste un manuale completo e consolidato per la versione corrente, il che è molto fastidioso. –

è memorizzato solo per motivi legali.

E i requisiti dettagliati? Si menzionano le soluzioni NoSQL, ma queste non possono promettere che i dati vengano memorizzati sul disco. In PostgreSQL tutto è sicuro per le transazioni, quindi sei sicuro al 100% che i dati siano su disco ed è disponibile. (semplicemente non girare fsync)

La velocità ha molto a che fare con l'hardware, la configurazione e l'applicazione. PostgreSQL può inserire migliaia di record al secondo su hardware buono e utilizzando una configurazione corretta, può essere dolorosamente lento usando lo stesso hardware ma usando una semplice configurazione stupida e/o l'approccio sbagliato nell'applicazione.Un singolo INSERT è lento, molti INSERT in una singola transazione sono molto più veloci, le istruzioni preparate sono ancora più veloci e COPY fa magie quando è necessario velocità. Tocca a voi.

fonte

2010-08-19 09:02:05

Il 100% sicuro sul disco potrebbe non essere necessario per motivi legali. Se riesci a provare che hai avuto un crash del disco, e in particolare perché non è possibile soddisfare una particolare richiesta legale, quel crash può essere considerato un Act of God. – MSalters

Chi lo sa. Ma un atto di Dio? Sarebbe una bella dichiarazione in tribunale, ma una buona possibilità di perdere. Basta controllare i requisiti e trovare una soluzione. –

@Frank Heikens - I dati provengono da un IM di un sito di incontri, non è necessario memorizzarlo in modo sicuro. Certo, spero che non perderemo alcun dato. Poiché il nostro budget è limitato, abbiamo per questo server comet su una casella deidata che gestirà le conversazioni di messaggistica istantanea e sullo stesso archivieremo i dati. Conosco i vantaggi di PostgreSQL ma in questo scenario reale penso che non possa eguagliare le prestazioni di MongoDB fino a quando non spendiamo molti dollari per un server 48 core, un array ssd e molta ram. – Nenad

seconda nel vostro MySql configurazione del sistema può gestire facilmente oltre 50.000 inserti al secondo.

Per le prove su un sistema attuale sto lavorando abbiamo ottenuto a oltre 200k inserti al secondo. con 100 connessioni simultanee su 10 tabelle (solo alcuni valori).

Non dicendo che questa è la scelta migliore dal momento che altri sistemi come il divano potrebbero rendere più semplice la replica/backup/ridimensionamento, ma ignorando mysql unicamente dal fatto che non è in grado di gestire una quantità così piccola di dati un po 'troppo dura.

Credo che ci sono soluzioni migliori (leggi: più economico, più facile da amministrare) soluzioni là fuori.

fonte

2010-08-19 09:10:37 edorian

Puoi dirmi le specifiche hardware del tuo sistema attuale? – Nenad

Non posso dirvi le specifiche esatte (produttore ecc.) Ma in generale si tratta di un 8 ram, 16 gb di RAM con una memoria collegata in esecuzione ~ 8-12 unità da 600 gb con un raid 10 – edorian

So che questo è vecchio ma se si è ancora in giro ... c'erano questi inserti sfusi? – lcm

Firebird può facilmente gestire 5000 Inserire/sec se la tabella non ha indici.

fonte

2010-08-19 12:38:50

Posso ottenere 5000 inserti/sec con MongoDB –

Non so perché escludere MySQL. Potrebbe gestire inserti elevati al secondo. Se vuoi davvero inserti alti, usa il tipo di tabella BLACK HOLE con la replica. Sta essenzialmente scrivendo su un file di log che alla fine viene replicato in una normale tabella di database. È possibile anche interrogare lo slave senza influire sulla velocità di inserimento.

fonte

2010-08-19 12:52:05

Il Benchmark che ho mi mostra che MySQL è davvero un RDBMS serio. – Nenad

Si prega di ignorare il benchmark sopra abbiamo avuto un bug all'interno.

Abbiamo record Inserire 1M con le seguenti colonne: id (int), stato (int), il messaggio (140 char, casuale). Tutti i test sono stati eseguiti con il driver C++ su un PC desktop i5 con disco Sata da 500 GB.

Benchmark con MongoDB:

1M Records Inserire senza Indice

time: 23s, insert/s: 43478

1M Records Inserire con Indice su Id

time: 50s, insert/s: 20000

prossimo aggiungiamo record 1M a la stessa tabella con Index a nd 1M records

time: 78s, insert/s: 12820

che risultano tutti in prossimità di file da 4 GB su fs.

Benchmark con MySQL:

1M Records Inserire senza Indice

time: 49s, insert/s: 20408

1M Records Inserire con Indice

time: 56s, insert/s: 17857

prossimo aggiungiamo record 1M allo stesso tabella con Indice e 1M record

time: 56s, insert/s: 17857

esattamente stesse prestazioni, nessuna perdita su MySQL sulla crescita

Vediamo Mongo è mangiare intorno 384 MB di Ram durante il test e del carico 3 nuclei della CPU, MySQL era felice con 14 MB e di carico solo 1 core.

Edorian era sulla strada giusta con la sua proposta, farò qualche altro Benchmark e sono sicuro che possiamo raggiungere un 2x Quad Core Server 50K Inserti/sec.

Penso che MySQL sia la strada giusta da percorrere.

fonte

2010-08-19 14:46:14 Nenad

Wow ... queste sono fantastiche statistiche. Posso chiederlo però, erano questi inserti di massa o ...? – lcm

Questo non mi dice se questi sono stati inserimenti concorrenti, se sono state utilizzate le operazioni di massa o quale fosse lo stato delle cache. Un benchmark di un minuto è quasi inutile, soprattutto quando si confrontano due tipi di database fondamentalmente diversi. – slang

Credo che la risposta dipenda anche dal tipo di disco rigido (SSD o meno) e anche dalla dimensione dei dati inseriti. Stavo inserendo un singolo campo dati in MongoDB su una macchina Ubuntu dual-core e stavo colpendo oltre 100 record al secondo. Ho introdotto alcuni dati piuttosto grandi in un campo, che è sceso a circa 9p e la CPU ha raggiunto circa il 175%! La scatola non ha SSD e quindi mi chiedo se mi sarei migliorato.

Ho eseguito anche MySQL e ci sono voluti 50 secondi solo per inserire 50 record su un tavolo con record di 20 m (con circa 4 indici decenti), quindi con MySQL dipenderà dal numero di indici in uso.

fonte

2017-05-18 20:15:17 Antony

DB con le prestazioni migliori inserti/sec?

risposta

Problemi correlati