Una soluzione di database in-memory con più rapido tempo reale replica [chiusa]

Question

Abbiamo un tavolo 10 mila riga che ha solo 2 colonne, una chiave primaria e una seconda colonna che mantengono lo stato. Il problema è che abbiamo bisogno di questo stato da replicare in 3 luoghi fisici negli Stati Uniti (circa 2000 miglia di distanza), quasi in tempo reale o il più velocemente possibile, in pratica su una rete. Qualsiasi dei 3 posizioni può aggiornare lo stato di una data riga in questa tabella che dovrebbe essere replicata in tempo reale alle altre 2 posizioni.

Ci sono delle open source o commerciale leggero database in memoria che potrebbe aiutarci a raggiungere ciò che stiamo cercando di fare. Disk persistenza non è poi così importante qui.

Answer 1

Redis . Ecco il replica Howto .

Inoltre, se si decide che la DB non ha assolutamente bisogno di essere in-memory, ha solo bisogno di essere veloce, si potrebbe prendere in considerazione CouchDB . Si può fare la replica continua, che è essenzialmente istantanea, e tutti i nodi sono maestri. Ha un rilevamento dei conflitti ben ponderata e il meccanismo di risoluzione. Questo post del blog è una grande introduzione ai migliori e più recenti funzionalità di replica CouchDB.

Answer 2

Anche se non v'è alcun supporto replica built-in, è possibile utilizzare trigger con un in -Memoria SQLite database. All'interno il grilletto, utilizzare un funzione personalizzata per comunicare le modifiche agli altri siti.

Answer 3

Si potrebbe voler controllare Altibase . Hanno detto che hanno più veloce database in memoria del mondo. Dicono che sono da 5 a 10 volte più veloce rispetto alla maggior parte DBMS in memoria e hanno anche una prova gratuita sul sito.

Answer 4

eseguo uno SQL complesso che ha più di 6000 righe 10000 volte nella mia Websphere Server. Totale tempi di esecuzione netti sono così:

          Derby (In Memory)   Oracle(standard DB) SQLite (In Memory)  HSQLDb (In Memory)
          nano sec.  second    nano sec.  second  nano sec.  second   nano sec. second
1. try    58000000    0,058   6149976000   6,1    1141988000   1,14   999403000    1,00
2. try    78560000    0,078   5268477000   5,2    1182621000   1,18   1338705000   1,34
3. try    58849000    0,058   5200898000   5,2    1133003000   1,13   2239527000   2,24
4. try    60901000    0,06    5435216000   5,4    1205442000   1,21   1370711000   1,37
5. try    58798000    0,058   6501929000   6,5    1186734000   1,19   1001800000   1,00
6. try    62928000    0,062   5913053000   5,9    1224470000   1,22   1066736000   1,07
7. try    71171000    0,071   5111207000   5,1    1200769000   1,20   1304524000   1,30
8. try    66913000    0,066   5517989000   5,5    1173495000   1,17   1299230000   1,30
9. try    58777000    0,058   7209555000   7,2    1179013000   1,18   1031795000   1,03
10. try   75299000    0,075   5356514000   5,3    1182715000   1,18   1368461000   1,37
average   65019600    0,064   5766481400   5,7    1181025000   1,18   1302089200   1,30

mi confronto, ovviamente, Derby, SQLite e HSQLDB. Oracle non è un db in memoria. Ma ho messo che il risultato vada a tavola perché per mostrare la differenza di velocità tra un db in memoria e db normale.

PS: In SQLite e il risultato HSQLDB non sono stabili. Così ho scelto 10 risultati stabili a 100 prova. A volte HSQLDB è più veloce di SQLite. Credo che loro prestazioni sono gli stessi.