Как базы данных в памяти обеспечивают надежность?

Если вы хотите, чтобы переходы сохранялись, запись в постоянное хранилище - единственный вариант (возможно, вы не хотите строить много кластеров с независимыми источниками питания в независимых центрах обработки данных и при этом молитесь, чтобы они никогда не выходили из строя одновременно). С другой стороны, это зависит от того, насколько ценны ваши данные. Если это необязательно, тогда может потребоваться чистая БД в памяти с достаточной репликацией. Кстати, даже жесткий диск может выйти из строя после того, как вы сохранили на нем свои данные, поэтому здесь нет идеального решения. Вы можете посмотреть http://www.julianbrowne.com/article/viewer/brewers-cap-theorem, чтобы выбрать компромисс репликации.

Prevayler http://prevayler.org/ - это пример системы в оперативной памяти с резервным копированием с помощью постоянного хранилища (и код чрезвычайно прост, кстати). Долговечность обеспечивается за счет журналов транзакций, которые хранятся на соответствующем устройстве (например, HDD или SSD). Каждая транзакция, изменяющая данные, записывается в журнал, и журнал используется для восстановления состояния БД после сбоя питания или перезапуска базы данных / системы. Помимо Prevayler, я видел похожую схему, используемую для сохранения очередей сообщений. Это действительно похоже на то, как работает «классическая» СУБД, за исключением того, что журналы - это только данные, записываемые в базовое хранилище. Журналы также могут использоваться для репликации, поэтому вы можете отправить одну копию журнала на живую реплику, а другую - на жесткий диск. Конечно, возможны различные комбинации.

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

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

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

Ознакомившись с вашим предыдущим постом, можно сказать, что многосерверная репликация будет работать до тех пор, пока вы можете поддерживать работу последнего сервера. Как только он выйдет из строя, вы потеряете очередь. Однако есть ряд альтернатив Oracle, которые можно рассмотреть.

КПК часто используют память с резервным питанием от батареи для хранения своих баз данных. Эти базы данных становятся недолговечными после разрядки батареи. Резервные копии важны.

In-memory означает, что все данные хранятся в памяти для доступа к ним. Когда данные читаются, они могут быть прочитаны с диска или из памяти. В случае баз данных в памяти он всегда извлекается из памяти. Однако, если сервер внезапно выключится, данные будут потеряны. Следовательно, считается, что базы данных в памяти не поддерживают ACID, обеспечивающую надежность. Однако во многих базах данных реализованы разные методы обеспечения надежности. Эти методы перечислены ниже.

• Моментальный снимок - запишите состояние базы данных в данный момент времени. В случае Redis данные сохраняются на диске каждые две секунды для обеспечения надежности.
• Ведение журнала транзакций - изменения в базе данных записываются в файл журнала, что облегчает автоматическое восстановление.
• Использование NVRAM обычно в виде статической RAM с резервным питанием от батареи. В этом случае данные могут быть восстановлены после перезагрузки из последнего согласованного состояния.

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

• используйте memcached (или аналогичный) для хранения в памяти на достаточном количестве узлов, так что маловероятно, что данные будут потеряны
• храните свою базу данных oracle в файловой системе на основе SAN, вы можете предоставить ей достаточно ОЗУ (скажем, 3 ГБ), чтобы вся база данных находилась в ОЗУ, и поэтому доступ с поиском диска никогда не приведет к остановке вашего приложения. Затем SAN выполняет отложенную обратную запись содержимого кэша на диск. Это очень дорогой вариант, но он часто встречается там, где требуется высокая производительность и высокая доступность, и они могут себе это позволить.
• если вы не можете позволить себе SAN, смонтируйте RAM-диск и установите на нем свою базу данных, а затем используйте репликацию уровня БД (например, отправку журналов) для обеспечения переключения при отказе.

Есть ли причина, по которой вы не хотите использовать постоянное хранилище?