Une solution de base de données en mémoire avec la réplication en temps réel plus rapide [fermé]

Question

Nous avons une table de 10 mille de ligne qui a seulement deux colonnes, une clé primaire et une deuxième colonne qui maintiennent l'état. Le problème est que nous avons besoin de cet état à répliquer sur 3 emplacements physiques aux États-Unis (environ 2000 miles de distance), en temps quasi réel ou aussi vite que possible dans la pratique sur un réseau. Tous les 3 emplacements peuvent mettre à jour l'état pour une ligne donnée dans ce tableau qui devrait être reproduit en temps réel à proximité des 2 autres endroits.

Existe-t-il open source ou poids léger commerciale base de données en mémoire qui pourrait nous aider à atteindre ce que nous essayons de faire. la persistance de disque n'est pas important.

Answer 1

Consultez Redis . Voici le réplication Howto .

En outre, si vous décidez que la DB n'a pas absolument besoin d'être en mémoire, il a juste besoin d'être rapide, vous voudrez peut-être considérer CouchDB . Il peut faire la réplication continue, qui est essentiellement instantanée, et tous les noeuds sont maîtres. Il a une détection de conflit bien pensé et le mécanisme de résolution. noreferrer"> Ce billet de blog

Answer 2

Bien qu'il n'y ait pas de support de réplication intégrée, vous pouvez utiliser déclencheurs avec en -Memory base de données SQLite. Dans le trigger, utilisez un fonction personnalisée pour communiquer les changements aux autres sites.

Vous pouvez consulter Altibase . Ils ont dit qu'ils ont la plus rapide base de données en mémoire du monde. Ils disent qu'ils sont 5 à 10 fois plus rapide que la plupart des SGBD en mémoire et ils ont aussi un essai gratuit sur le site.

J'Exécute une requête SQL complexe qui a plus de 6000 lignes 10000 fois dans mon Websphere Server. temps d'exécution net total sont comme ça:

          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

Je compare évidemment Derby, SQLite et HSQLDB. Oracle est pas dans la mémoire db. Mais je l'ai mis à la table est le résultat parce que pour montrer la différence de vitesse entre dans la mémoire db et db normal.

PS: En SQLite et le résultat HSQLDB ne sont pas stables. Je choisis donc 10 résultats stables 100 essayer. Parfois, HSQLDB est plus rapide que SQLite. Je pense que leurs performances sont les mêmes.

Answer 3

Bien qu'il n'y ait pas de support de réplication intégrée, vous pouvez utiliser déclencheurs avec en -Memory base de données SQLite. Dans le trigger, utilisez un fonction personnalisée pour communiquer les changements aux autres sites.

Answer 4

Vous pouvez consulter Altibase . Ils ont dit qu'ils ont la plus rapide base de données en mémoire du monde. Ils disent qu'ils sont 5 à 10 fois plus rapide que la plupart des SGBD en mémoire et ils ont aussi un essai gratuit sur le site.

Answer 5

J'Exécute une requête SQL complexe qui a plus de 6000 lignes 10000 fois dans mon Websphere Server. temps d'exécution net total sont comme ça:

          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

Je compare évidemment Derby, SQLite et HSQLDB. Oracle est pas dans la mémoire db. Mais je l'ai mis à la table est le résultat parce que pour montrer la différence de vitesse entre dans la mémoire db et db normal.

PS: En SQLite et le résultat HSQLDB ne sont pas stables. Je choisis donc 10 résultats stables 100 essayer. Parfois, HSQLDB est plus rapide que SQLite. Je pense que leurs performances sont les mêmes.