Решение для базы данных в памяти с самой быстрой репликацией в реальном времени

Question

У нас есть таблица из 10 тысяч строк, в которой всего 2 столбца: первичный ключ и второй столбец, сохраняющий состояние.Проблема в том, что нам нужно, чтобы это состояние было реплицировано в трех физических точках в США (на расстоянии около 2000 миль друг от друга) практически в реальном времени или как можно быстрее по сети.Любое из трех мест может обновить состояние определенной строки в этой таблице, которая должна быть реплицирована практически в реальном времени в два других места.

Есть ли какая-либо база данных с открытым исходным кодом или коммерческая легкая база данных в памяти, которая могла бы помочь нам достичь того, что мы пытаемся сделать?Сохранение диска здесь не так важно.

Answer 1

Проверить Редис.Вот Репликация: инструкции.

Кроме того, если вы решите, что БД не обязательно должна находиться в памяти, она просто должна быть быстрой, вы можете рассмотреть возможность CouchDB.Он может выполнять непрерывную репликацию, которая по существу является мгновенной, и все узлы являются ведущими.Имеет продуманный механизм обнаружения и разрешения конфликтов. Этот пост в блоге — отличное введение в новейшие и лучшие возможности репликации CouchDB.

Answer 2

Хотя встроенной поддержки репликации нет, вы можете использовать триггеры с оперативной памятью SQLite база данных.В триггере используйте пользовательская функция чтобы сообщить об изменениях другим сайтам.

Answer 3

Возможно, вы захотите проверить Альтибаза.Они сказали, что у них самая быстрая в мире база данных в памяти.Они говорят, что они в 5-10 раз быстрее, чем большинство СУБД в памяти, и у них также есть бесплатная пробная версия на сайте.

Answer 4

Я выполняю сложный SQL, содержащий более 6000 строк, 10 000 раз на моем сервере Websphere.Общее чистое время выполнения выглядит следующим образом:

          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 не является базой данных в памяти.Но я поместил результат в таблицу, чтобы показать разницу в скорости между базой данных в памяти и обычной базой данных.

ПС:В SQLite и HSQLDB результаты нестабильны.Поэтому я выбираю 10 стабильных результатов за 100 попыток.Иногда HSQLDB работает быстрее, чем SQLite.Я думаю, что их производительность такая же.