Ein In-Memory-Datenbanklösung mit schnellster Echtzeit-Replikation [geschlossen]

Question

Wir haben eine 10 Tausend Zeilen-Tabelle, die nur 2 Spalten, einen Primärschlüssel und eine zweite Spalte, den Zustand zu halten. Das Problem ist, dass wir brauchen, diesen Zustand über drei physische Standorte in den USA repliziert wird (etwa 2000 Meilen voneinander entfernt), nahezu in Echtzeit oder so schnell wie praktisch möglich über ein Netzwerk. Jede der drei Standorte kann den Zustand für eine bestimmte Zeile in dieser Tabelle aktualisieren, die nahezu in Echtzeit zu den anderen zwei Standorten repliziert werden sollen.

Gibt es ein Open-Source oder kommerzielle Leichtgewichtler In-Memory-Datenbank, die wir zu erreichen, helfen könnte, was wir zu tun versuchen. Disk-Persistenz ist nicht so wichtig hier.

Answer 1

Schauen Sie sich Redis . Hier ist der Replication Howto .

Auch wenn Sie entscheiden, dass die DB absolut nicht im Speicher sein müssen, es muss nur schnell sein, könnten Sie in Erwägung ziehen, CouchDB . Es kann eine kontinuierliche Replikation tun, die im Wesentlichen sofortige ist und alle Knoten sind Meister. Es verfügt über eine gut durchdacht Konflikterkennung und -lösung Mechanismus. Dieser Blog-Eintrag ist eine großartige Einführung in die neuesten und besten CouchDB Replikationsfunktionen.

Answer 2

Obwohl es keine Replikation Unterstützung eingebaut, können Sie verwenden, Trigger mit einem in -Speicher SQLite Datenbank. Im Trigger verwenden, um eine benutzerdefinierte Funktion die Änderungen an den anderen Standorten zu kommunizieren.

Answer 3

Sie möchten vielleicht Altibase . Sie sagten, sie die weltweit am schnellsten In-Memory-Datenbank haben. Sie sagen, sie sind 5 bis 10 mal schneller als die meisten In-Memory-DBMS und sie haben auch eine kostenlose Testversion auf der Website.

Answer 4

Ausführen mir eine komplexe SQL, die mehr als 6000 Zeilen 10000 mal in meinem Websphere Server hat. Die gesamten Nettolaufzeiten sind wie folgt aus:

          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

Ich vergleiche offensichtlich Derby, SQLite und HSQLDB. Oracle ist ein nicht im Speicher db. Aber ich es das Ergebnis zu Tisch setzen, weil zu zeigen Geschwindigkeitsdifferenz zwischen einem im Speicher db und normalen db.

PS: In SQLite und HSQLDB Ergebnis ist nicht stabil. So wählte ich 10 stabile Ergebnisse in 100 versuchen. Manchmal ist HSQLDB schneller als SQLite. Ich denke, dass ihre Leistung gleich ist.