Una soluzione di database in-memory con più rapido tempo reale replica [chiusa]
-
22-09-2019 - |
Domanda
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.
Soluzione
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.
Altri suggerimenti
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.
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.
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.