На что сменить MongoDB

Сейчас на сервере (2хE5-2630, 128Гб RAM, SAS) стоит MongoDB 2.4.1
В ней две коллекции (в разных бд):
— Коллекция-1: 70 млн. записей (120 insert/s, 60 find/s, база с индексами ~ 9 Гб).
— Коллекция-2: 40 млн. записей (50 insert/s, 40 find/s, база с индексами ~ 11 Гб).

Цифры вроде не большие для данного железа. Вообще-то, запросов на чтение приходит на порядок больше, но по остальным информация берется из кэша (Redis). До монго доходит только в случае кэш промаха.

Проблема в том, что постоянно несколько операций find выполняются по 180 — 600 мс. Судя по отчетам профайлера и логам они ожидают, пока не освободится writing lock.
Sun Apr 14 13:40:44.859 [conn3581] query db1.coll1 query: { _id: "14638g27189a6a957c6a792151df31b7" } ntoreturn:1 idhack:1 keyUpdates:0 locks(micros) r:188697 reslen:105 188ms

К базе вообще делаю только findOne или insert. Объем данных в insert не превышает 120 байт.

iostat -x
rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0,01 5,55 0,57 27,60 35,60 1531,59 111,28 0,41 14,46 8,01 14,60 1,61 4,53

Вопрос: что делать? В дальнейшем объем данных вырастет до 500 — 1000 млн записей. И количество обращений на чтение до 10 тыс/сек.
Мне нужна БД с очень низкой латентностью для чтения по ключу. Никаких сложных выборок. Нужен backend для кэша. А монго со своим per-database write lock все портит.

Еще вариант, читать только со slave ноды. А писать на master. Но боюсь столкнуться с задержками при репликации данных, и, как следствие, с неконсистентными данными.

Что посоветуете? HBase, Hypertable? Нужно уложиться в максимум 2-5 мс при чтении из БД.