Eine In-Memory-Datenbank-Lösung mit der schnellsten Echtzeit-Replikation

Question

Wir haben eine 10 Tausend Row-Tabelle, die nur 2 Spalten hat, einen Primärschlüssel und eine zweite Spalte, die den Status beibehalten. Das Problem ist, dass wir diesen Zustand an 3 physischen Standorten in den USA (ungefähr 2000 Meilen voneinander entfernt) replizieren müssen, und zwar nahezu in Echtzeit oder so schnell wie praktisch möglich über ein Netzwerk. Jeder der drei Standorte kann den Status für eine bestimmte Zeile in dieser Tabelle aktualisieren, die nahezu in Echtzeit zu den anderen zwei Standorten repliziert werden sollte.

Gibt es eine Open-Source- oder kommerzielle, leichtgewichtige In-Memory-Datenbank, die uns dabei helfen könnte, das zu erreichen, was wir zu erreichen versuchen? Festplattenpersistenz ist hier nicht so wichtig.

Answer 1

Auschecken Redis. Hier ist die Replication Howto.

Auch wenn Sie sich entscheiden, dass die DB nicht unbedingt in Arbeitsspeicher sein muss, muss es nur schnell sein, möchten Sie vielleicht CouchDB betrachten. Es kann eine fortlaufende Replikation durchführen, die im Wesentlichen sofort erfolgt, und alle Knoten sind Master. Es hat einen durchdachten Mechanismus zur Konflikterkennung und -lösung. This blog post ist eine großartige Einführung in die neuesten und besten CouchDB-Replikationsfunktionen.

Answer 2

Obwohl keine Replikationsunterstützung integriert ist, können Sie triggers mit einer In-Memory-Datenbank SQLite verwenden. Verwenden Sie innerhalb des Triggers eine custom function, um die Änderungen an die anderen Sites zu übermitteln.

Answer 3

Sie möchten vielleicht Altibase auschecken. Sie sagten, sie hätten die weltweit schnellste In-Memory-Datenbank. 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

Ich führe 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 

I Derby offensichtlich vergleichen, SQLite und HSQLDB. Oracle ist keine im Speicher db. Aber ich lege das Ergebnis auf Tabelle, um den Geschwindigkeitsunterschied zwischen einer in der Speicher-db und einer normalen db zu zeigen.

PS: In SQLite und HSQLDB Ergebnis sind nicht stabil. Also wähle ich 10 stabile Ergebnisse in 100 Versuchen. Manchmal ist HSQLDB schneller als SQLite. Ich denke ihre Leistung ist gleich.