Как-то давно в одном известном месте, в департаменте архитектуры, мне сказали: "вам выпала большая честь, у вас не будет базы и будет всё в памяти". Я после этой встречи пришёл к команде и сказал: "парни, пи**ец, делаем две ветки, одна на Оракле, другая на "всё в памяти". При этом говорим, что идея хорошая, но пока "всё в памяти" нихера не работает, поэтому Оракл. Через несколько лет такую тактику признали правильной. Всё в памяти не заработало.

Но это не дешевое железо, как я понимаю?

~ 40круб за 128гб

Ну, вот да.. Хотя вариант с чистым inmem с репликацией и возможностью все скинуть на диск при major version update стоит рассмотреть.

Не думаю, что это хорошая идея. Нет гарантий, что в какой-то момент кластер всё же не развалится или реплики не разъедутся.

На тот момент, кстати, у того решения, которое нам навязали, никакой персистентности не было вообще. И это был банк.

Это чье? И в амазоне есть с ней хосты? Или в ажуре?

Ну, так это и для persistance нет. Хотя inmem баз, которые проходоят jepsen - я не знаю. Надо посмотреть, что там у редиса.

И платы нужны специальные или стандартные? Ну и какие СУБД это умеют поддерживать )

Мне нравится мысль, что перед фиксацией транзакции данные хотя бы в каком-то виде сброшены на диск

Ну, мне тоже. Но тогда FoundationDB или Cockroach - и опаньки

Оно втыкается вместо ddr4 модуля. Заявлено ~ 33Gb/s чтение и 9.8Gb/s запись

И всё же) вопрос в масштабе потерь)

А толку-то, если СУБД с ней не умеют работать как с диском...
Т.е. даже сделав redis поверх я не решу проблемы major version update.
Разве что развернуть виртуальный диск поверх и делать на нее snapshot

Ну, тут скорее дело в масштабе моей лени это реализовывать на FDB. Ну и смотреть, как оно реально смасштабируется. И лечить детские проблемы.

Ну и есть ли БД, умеющие хранить данные в этом nvdimm, а потом восстанавливать оттуда после рестарта версии?

На HDD, кстати, 1000 не получить, там где-то 300 IOPS, не больше.