Пишу архитектуру кластерного решения с одним из режимов работы в оперативной памяти.
В связи с чем провожу ревизию знаний и возникло несколько вопросов. Сначала приведу краткое описание, а затем задам список вопросов.

Рассмотрим следующую архитектуру. Базу средних размеров наверное до 300 ГБ полностью помещаем в оперативную память(виртуальный диск). Плюсом такого решения будет ускорения работы, минусом – потеря данных, что неприемлемо. Далее берем и включаем асинхронный always on на сервер с физическим диском. Таким образом у нас имеется копия БД на диске с небольшим отставанием. Как показывает практика(для большинства oltp ИТ систем) без учета пересчета статистики или индексов среднее оставание составляет 2-3 секунды.
Можно ли исключить потерю данных за эти 2-3 секунды? - Можно! Необходима интеграция с приложением. Реализуется простейшая система логирования транзакций на триггерах. Например в таблицу пишутся ссылки на документы, тип операции(I,U,D), доп информация(например сумма документа и т.п.). Далее job непрерывно работающий сравнивает две таблицы – на сервере источнике с оперативной памятью и на сервере приемнике с диском и апдейтит статус транзакций(разумеется в источнике) которые уже записаны на диск. Таким образом мы оперативно получаем дельту не записанных на диск транзакций и статус транзакций когда они записаны на диск.
Важный момент, что приложение должно делить транзакции на важные и нет. То есть на те которые можно потерять и на те которые нельзя. Далее приложение для важных транзакций передает фокус управления только тогда, когда они записаны на диск. Для транзакций не важных можно передавать фокус моментально. Под фокусом управления подразумевается не только активизация окна диалога приложения но и выгрузка во внешние базы, распечатка документов и т.п. Передача фокуса может быть реализована различным способами, например сокет сервер опрашивает статус таблицы логирования(запрос таблицы транзакций на севрерах) их апдейтит и передает сообщения на сокет клиент в приложение, которое разрешает дальнейшие действия.
Если мы считаем что все транзакции важны и фокус всегда ожидает статуса(ЗаписаноНаДиск) то в этом случае у нас вообще исключена потеря данных! (Если кто то считает по другому просьба обосновать)
При использовании такого подхода у нас уменьшается время блокировок, потому как время транзакций уменьшается(ожидание статуса идет вне транзакции,уже после ее фиксации). Для большинства транзакций просто уменьшается время выполнения потому как их в случае непредвиденного выключения сервера(что в последнее время редкость) их можно воспроизвести в системе(то есть их можно спокойно потерять), тем более всегда есть лог незакомиченных транзакций(номер документа, время, пользователь, например сумма) который можно писать на физический диск.
Если считать среднее время рассинхронизации нод - 2 сек. То за это время пользователь даже осмыслить ничего не успеет. Например можно разрешить передавать фокус управления приложения пользователю после проведения документа заказа, но печатать(отправлять на печать) его позволять только после фиксации на диске. На самом деле для подавляющего количества операций можно не дожидаться фиксации на диске. Что приведет к существенному уменьшению времени отклика от ИТ системы.
В случае размещения базы в памяти у нас ускоряются не только операции вставки и изменений но и мы гарантированно всегда обращаемся к данным в памяти. В этом случае вообще необходимо запретить СУБД обращаться к кешу данных в оперативной памяти, потому как это будет двойная работа.(если это возможно, будет один из вопросов)
Плюсы этой системы я уже приводил а минусы тоже существуют.

Обслуживание БД, переиндексация и пересчет статистики могут привести к большому времени рассинхронизации – из чего следует, что их необходимо проводить в режиме прямого коннекта к БД.(необходимо автоматизировать режим реконнекта) Перезагрузка сервера должна предварять процедура остановки БД и ожидания (пара секунд) нулевого времени рассинхронизации. Короче говоря, процедуру перезагрузки необходимо также автоматизировать. После перезагрузки сервера необходимо вычитать всю БД в память, это тоже время(пару минут,300 ГБ). В общем, перезагрузка сервера будет занимать немного больше времени и требовать доп. регламента. В самом приложении, тажке нужна небольшая адаптация(система логирования и система семафоров).
С точки зрения надежности мы полагаемся на надежный транспорт always on. Надежность работы памяти в современных серверах также обеспечивается механизмами про которые я здесь не буду расписывать. По сути эффективность системы будет определятся размером БД(для супер больших БД памяти не напасешься), количеством незапланированных перезагрузок СУБД(надежность ЦОД-а в первую очередь), а также средним временем рассинхронизации нод.


А теперь вопросы.

Вы реализовывали подобную схему?
Кто ни будь размещал БД в память, проводил замеры? Можно поделиться результатами?
Кто ни будь размещал БД приемник в always on в память, с целью горизонтального масштабирования? Каковы результаты?(то есть описанная ситуация но наоборот)
Можно ли, и какими настройками запретить СУБД обращаться к кешу данных в оперативной памяти? (заставить считывать все страницы напрямую с виртуального диска)

Ну совсем детали я не стал расписывать. Например это могут быть два инстанса на одном физическом сервере для того что бы атач базы можно было быстро сделать в оперативную память. Не знаю к слову, можно ли обмануть систему и писать always on из одной БД в другую на этом же сервере?

Коллеги, спасибо за живой интерес к данному вопросу. Просьба к данной теме не относится слишком серьезно, это скорее логический эксперимент. Тем не менее, интуитивно я уверен, что для небольшого количества систем это вариант в разы уменьшить количество блокировок в системе с относительно небольшими трудозатратами(за счет уменьшения времени транзакций). Буду рад если кому то эта информация пригодится.

Сразу задам единственный вопрос касающийся практической стороны вопроса. Кто ни будь знает(догадывается) оптимальные настройки для работы БД полностью в оперативной памяти?
Какая может быть(возможно) практическая польза. Компания, в которой я работаю активно использует always on для построения кластеров для горизонтального масштабирования. Также знаю, что некоторые участники этого форума используют в подобных целях. Как вы знаете транспортировке данных c помощью always-on возникает некоторая задержка(в синхронном в том числе тоже). Иногда она не важна и запрос можно перенаправлять на доп. ноду, игнорируя запоздалость данных, а иногда это важно и необходимо дожидаться синхронности с помощью семафоров. Уменьшение времени синхронизации для некоторых систем становится важной задачи. Размещение ноды в памяти позволяет уменьшить время рассинхронизации ,в этом случае можно и синхронный режим(alwaya on) включать а в асинхронном писать на диск.


Теперь просто размышления на тему.
Как правильно отметил alexeyvg , вопрос о сохранности данных стоит не только для размещенных в памяти данных но и для классических дисковых хранилищ. Независимо от моделей, принцип остается один – контроллер пишет во внутренний кеш(память), затем порциями записывает на диск. За счет укрупнения происходит ускорение(не буду вдаваться в детали), но за счет этого происходит риск потери части данных. Все сводится к записи порции данных из кеша на диск в случае аварии. Для некоторых банковских систем подобное кеширование осознанно отключают. То есть данные записанные в БД немедленно записываются на диск(происходит замедление, увеличение времени отклика). Но многие данный факт скромненько замалчивают так как сами в жизни ни разу с этим не сталкивались, либо последствия были не существенны.
Владислав Колосов , вы видимо подзабыли что условие большего обьема(да хоть бы и в три раза) памяти по отношению к БД вовсе не гарантирует нам того что она целиком будет в кеше.
Есть запросы когда оптимизатору нужно выбрать вариант долгий и тяжелый с точки зрения ЦПУ и низкого использования памяти вариант типа вложенных циклов(nested loops).Либо оптимизатору выбрать затратный с точки зрения памяти типа хеш джоин. Так вот такие запросы выполняемый многочисленно в единицу времени могут постоянно вытеснять память(page life expectancy – падает) и результатом этого будет нахождение в памяти, например, не более чем 30% от БД. Понятно что это неоптимальные запросы и нужно их оптимизировать но это жизнь и наблюдал это многократно.

А вообще, еще есть мысли реализовать отдельное кластерное решение полностью работающая синхронно в памяти на нескольких географически распределенных нодах с асинхронной записью на диск. Решение это не на базе always -on. Как вы считаете насколько такая система жизненно способна с точки зрения надежности? Каковы риски потери данных(не синхронной дельты между памятью и диском)?

Владислав Колосов,Давно дело было. Помнится одного админа за разряженную батарейку уволили:)

rahzer, Все что нужно я для себя открыл;)

Alibek B., Общаюсь регулярно с инженерами в том числе разрабатывающие такие решения. Может вы мне чего нового расскажете кроме общих туманных формулировок? А в целом ничего нового(SSD немного поменяла расклады), оперативная память гораздо быстрее диска. Хоть онлайн репликацию сделайте на СХД, вам пользы от нее ноль будет - все равно нужна реплика памяти. Если у вас стоит задача горизонтального масштабирования то чем вам СХД поможет(Ну только если у него время отклика не будет как у памяти)? Рекомендую вам прежде про Numa архитектуру почитать прежде, чем давать советы по СХД;)