Во втором случае вполне можно сохранить (или восстановить, в конце-концов) _структурную_ целостность базы (или fs) - но нет никакой возможности сказать, какие операции теперь надо переделать или считать не происходившими. Потому что мы это теперь никак не узнаем. Эти данные потеряны, нет их. Нигде нет.

Вот зарплату нашему прохфессору кислых щей к счету приплюсовали, но эта ячейка осталась только в памяти. А из счета его работодателя уже вычли, и эта информация (ну, так получилось) уже попала на носитель. А с базой у нас все в порядке.
Вариант интересней - мы уже начали туда писать, и вдруг питание йок, указатель на блок обновился, но содержимое блока - мусор с диска. Опа, оказывается, прохфессор в этом месяце не только не заработал ничего, но и торчит банку пятнадцать миллиардов. Блок на диске - существует, причин не доверять содержимому нет, прохфессор, пройдите на эстакаду. Вместо адреса блока на диске в указателе лежит -1? Профессора не существует вообще, эктерминационная команда выехала для установления структурной целостности мироздания.

Чтобы таких вещей не происходило - используются transaction logs и трехступенчатая запись. И любая база, даже такая которой деньги доверять нельзя - пишет их с O_DIRECT, чтобы быть абсолютно точно уверенной, что если запись вернула OK - данные попали на диск, а не в воздухе повисли.

Здесь утрировать все горазды. То, что у вас хранятся только критически важные данные, не значит, что у всех так. Это ущербное мышление.

Впрочем, думаю, что здесь ресь о кэше на чтение

Я был бы рад, если бы такой пользователь сам "пропал". /s

конечно. Большинство данных в этом мире - неважны.

> Допустим пользователь загрузил вам фото со своим котиком и удалил со своего диска.

"Дурак, это я его пользователь".
В смысле, это мы его - пользуем. Времена когда пользователь был чем-то уважаемым и ценным, к сожалению, прошли.

> База данные сдохла и котик пропал, будет ли доволен пользователь?

а кого это колышет? Куды ни пойди - везде один и тот же пейсбук. Поэтому пользователь заведет себе нового котика, если старый сдох и перефоткать его уже не получится. И выложит поделиться- "го, я создал!" Куда он денется-то?

А лайкающие - пополнят социальный граф - и вот его-то мы храним ни разу не в мемкыше, поэтому твои лайки с прошлого, сдохшего котика - тоже там осели.

> Если и делать хранилище в RAM, то только с резервированием на двух разных серверах с

ох уж эти васяны-неофиты. "У вас на стройке случаи split-brain были? Нет? - Будут!"

А по факту - Optane'ы с ресурсом, в 70+ раз бОльшим, но со стандартным простым интэрфэйсом - стоят очень дорого. Не порядок.

вы там поаккуратнее с такими идеями. Кеннеди вот - пришлось пристрелить.

Ну вот опять "не читал, но осуждаю"...

Эта "хрень" (aka HSE) работает быстрее на 99% из-за mpool (модуль ядра).
В свою очередь, mpool реализует примерно две (нужные для LSM+WAL) вещи, но делает это гораздо оптимальнее чем можно сделать через традиционное API POSIX.

Чтение "через mpool" получается быстрее, во многом, из-за непосредственного отображения данных в память (memory mapped I/O). В этом есть схожесть с libmdbx.

Запись "через mpool" тоже выходит быстрее, так как без лишнего копирования и засорения страничного кэша ядра. Отдельная принципиальная фишка в дозаписи WAL "в одну страницу флеша" без её стирания (хотя многое еще не реализовано). К этому добавьте асинхронность и распараллеливание (внутри ядра) между разными носителями, а также автоматические идеальные write barriers.

При этом специфическое API и реализация внутри ядра позволяют дополнительно экономить на системных вызовов и модификациях PTE (со сбросом кеша).

Т.е. фактически Micron предложил специфическое API для хранения LSM+WAL на solid-носителях, и на примере HSE показал его в действии.
"Но" здесь только одно - в моем понимании вся затея сильно обесценивается при выходе на рынок персистентной памяти и Micron можно заподозрить в "выбрасывании в open-source" проекта, который вот-вот потеряет актуальность.