Per decine di migliaia di richieste/secondo Voglio vedere 60.000 -> +90.000 richieste/secondo.(Come può/cosa dovrebbe) Implementare un database che scala fino alle decine di migliaia di richieste/secondo?
Il mio programma di installazione è costituito dai seguenti:
utente ---> Web App -> coda di messaggi -> parser -> database?
Devo dire che il parser al momento può analizzare/roba circa 18750 record/secondo usando COPY quindi siamo limitati a tale scopo fino a quando non iniziamo ad aggiungere altri parser - questa non è una grande preoccupazione per me ora.
Ho un sistema che richiede la possibilità di caricare in blocco il più velocemente possibile il maggior numero di record che posso. Questo stesso sistema (o può essere diverso a seconda di come ci si avvicina a esso) dovrebbe essere in grado di rispondere alle domande di tipo analitico di questo tipo:
wonq = "select sum(amount) from actions where player = '@player' and " +
"(type = 'award' or type = 'return') and hand = hand_num"
lostq = "select sum(amount) from actions where player = 'player' and " +
"type != 'award' and type != 'return' and hand = hand_num"
..... 10-15 mila volte (per utente) poiché sono trasferiti su un'altra tabella. Inutile dire che per ora paghiamo questi risultati a 10/pagina.
Ho guardato il seguente: (. Reg corsa del RDBMS mulino) (presupponendo che siano tutte sullo stesso server)
mysql - è stato in grado di entrare in 15-20 mille richieste/secondo intervallo; nelle condizioni attuali, se tentiamo di ridimensionarlo, abbiamo bisogno di un host/database separato ogni volta che dobbiamo ridimensionarlo - non è fattibile
couchdb (document oriented db) - non ha infranto 700 richieste al secondo; Speravo davvero che questo mi avrebbe salvato il culo, non una possibilità!
vertica (indirizzamento colonnare db) - stava colpendo 60000 richiesta/secondo, fonte chiusa, molto costoso; questa è ancora un'opzione ma personalmente non mi è piaciuta affatto
tokyocabinet (db basato su hash) - attualmente sta pesando in 45.000 inserti/secondo e 66.000 selezioni/secondo; ieri, quando ho scritto questo, stavo usando un adattatore basato su FFI che stava eseguendo circa 5555 richieste al secondo; questo è di gran lunga il database più impressionante più veloce che abbia mai visto !!
terracotta - (vm cluster) attualmente valutando questo insieme a jmaglev (non vedo l'ora che Maglev venga fuori) - questo è IL PIÙ BASSO!
forse sono solo affrontare questo problema sbagliato ma ho sempre sentito dire che RDBMS erano lento come l'inferno - Allora, dove sono questi sistemi super veloce che ho sentito parlare?
Controlli delle condizioni ::
Just so ppl conoscono le mie specifiche sulla mia casella di dev sono:
dual 3.2ghz intel, 1 gig ram
MySQL MySQL.modifiche CNF erano:
key_buffer = 400M # was 16M innodb_log_file_size = 100M # non existent before innodb_buffer_pool_size = 200M # non existent before
UPDATE ::
Si scopre che in terracotta potrebbe avere un posto nella nostra struttura dell'applicazione, ma fuori casa non sostituirà la nostra in qualsiasi momento del database non appena è velocità sono terribili e il suo utilizzo dell'heap fa schifo.
D'altra parte, sono stato molto felice di vedere che la libreria di rubini NON-FFI di tokyocabinet (che significa tiranno/armadio) è super veloce e in questo momento è il primo posto.
feydr - potresti approfondire come hai testato Terracotta? Vorrebbe sapere di più perché credi che la terracotta sia lenta. La maggior parte delle persone lo trova estremamente veloce, quindi forse è un caso di cattiva utilità - o potrebbe esserci qualche regolazione? Mi piacerebbe saperne di più ... –
taylor: certamente è probabile. un caso di cattivo uso; lo stiamo ancora valutando e probabilmente lo faremo per un po 'di tempo ma, come primo test per la semplice condivisione di un elenco di oggetti su un'istanza server-client, siamo stati in grado di inserire solo gli oggetti in ~ 50/secondo rispetto alla maggior parte delle altre opzioni ~ 600/sec – eyberg
taylor: ho appena notato che il tuo blog parla di 3500 txn/secondo - la terracotta garantita si ridimensionerà molto più facilmente (il che significa che ha ancora un posto per noi) ma penso che la velocità txn sia solo relativamente parlando modo rallentare per sostituire i nostri rdbms – eyberg