An In-memory database solution with quickest real time replication [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

开发者_StackOverflow中文版

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 8 years ago.

Improve this question

We have a 10 thousand row table that has just 2 columns, a primary key and a second column that keep state. The problem is that we need this state to be replicated across 3 physical locations in the US(about 2000 miles apart), in near real time or as fast as practically possible over a network. Any of the 3 locations can update the state for a given row in this table which should be replicated in near real time to the other 2 locations.

Are there any open source or commercial light weight in-memory database that could help us achieve what we are trying to do. Disk persistence is not that important here.

---

Check out Redis. Here's the Replication Howto.

Also, if you decide that the DB doesn't absolutely need to be in-memory, it just needs to be fast, you might want to consider CouchDB. It can do continuous replication, which is essentially instant, and all nodes are masters. It has a well-thought-out conflict detection and resolution mechanism. This blog post is a great introduction to the latest and greatest CouchDB replication capabilities.

---

Though there is no replication support built-in, you can use triggers with an in-memory SQLite database. Within the trigger, use a custom function to communicate the changes to the other sites.

---

You might want to check out Altibase. They said they have the world's fastest in-memory database. They say they are 5 to 10 times faster than most in-memory DBMS and they also have a free trial on the site.

---

I execute a complex SQL which has more than 6000 rows 10000 times in my Websphere Server. Total net execution times are like that:

          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 obviously compare Derby, SQLite and HSQLDB. Oracle isn't a in memory db. But I put it's result to table because to show speed difference between a in memory db and normal db.

PS: In SQLite and HSQLDB result aren't stable. So I choose 10 stable results in 100 try. Sometimes HSQLDB is faster than SQLite. I think theirs performance are same.