内存数据库解决方案,具有最快的实时复制

时间:2010-03-24 22:22:49

标签: database replication in-memory-database

我们有一个只有2列的万行表,一个主键和一个保持状态的第二列。问题是我们需要在美国的3个物理位置(相距大约2000英里),近乎实时或在网络上尽可能快地复制这种状态。 3个位置中的任何一个都可以更新此表中给定行的状态,该状态应该近实时复制到其他2个位置。

是否有任何开源或商业轻量级内存数据库可以帮助我们实现我们想要做的事情。磁盘持久性在这里并不重要。

4 个答案:

答案 0 :(得分:4)

结帐Redis。这是Replication Howto

此外,如果您确定数据库并非绝对需要在内存中,它只需要很快,您可能需要考虑CouchDB。它可以进行连续复制,这基本上是即时的,并且所有节点都是主节点。它有一个经过深思熟虑的冲突检测和解决机制。 This blog post是对最新和最好的CouchDB复制功能的精彩介绍。

答案 1 :(得分:1)

虽然没有内置的复制支持,但您可以将triggers与内存中的SQLite数据库一起使用。在触发器中,使用custom function将更改传达给其他站点。

答案 2 :(得分:1)

您可能想查看Altibase。他们说他们拥有世界上最快的内存数据库。他们说他们比大多数内存DBMS快5到10倍,他们也在网站上免费试用。

答案 3 :(得分:0)

我在Websphere Server中执行一个复杂的SQL,它有超过6000行10000次。总净执行时间如下:

          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

我显然比较了Derby,SQLite和HSQLDB。 Oracle不是内存数据库。但是我将它的结果放到了表中,因为它显示了内存db和普通db之间的速度差异。

PS:在SQLite和HSQLDB中结果不稳定。所以我在100次尝试中选择10个稳定的结果。有时HSQLDB比SQLite快。我认为他们的表现是一样的。