Оптимальный (отказоустойчивый, недорогой) способ ведения журнала упреждающей записи (WAL) в IaaS?

Я работаю над новым проектом для «облачной» СУБД с «облачной», что означает, что гарантии (например, ACID), которые он предоставляет, будут зависеть от наличия определенных поддерживающих сервисов IaaS (например, хранилище объектов, управляемые очереди сообщений и т. д.). Цель состоит в том, чтобы уменьшить размер кодовой базы и накладные расходы на операции СУБД в тех случаях, когда вы все равно собираетесь работать в среде IaaS.

Одна из функций, необходимых любой СУБД, - это журнал с упреждающей записью (WAL) для воспроизведения состояния после сбоя. Наивный, «не обращающий внимания на облака» способ реализовать WAL - просто сделать его файлом на диске, которым управляет демон СУБД. В облачной среде это неявно переводится в журнал WAL, который находится либо на локально подключенном «временном» диске, либо в томе SAN (например, EBS, GCE PD), подключенном к гипервизору виртуальной машины через что-то вроде iSCSI. (И, поскольку WAL предназначены для восстановления после сбоя, мы можем игнорировать параметр ephemeral-disk; если сбой произошел из-за сбоя экземпляра, диск пропал бы!)

WAL имеют особую семантику:

• WAL принадлежит одному процессу / заданию; ничто другое не сможет прочитать или записать его (т. е. он может считаться навсегда заблокированным его владельцем)

• единственные записи - это добавления (которые могут быть переведены на перезапись в файле кольцевого буфера, но это деталь реализации)

• нет смешанного трафика чтения / записи; WAL открывается только когда-либо только для чтения, или открыл только для записи, без переключения во время сеанса

• сеансы чтения редки (только для аварийного восстановления) и всегда представляют собой потоковое чтение всего WAL, начиная с первого доступного (т.е. не собираемого мусором) сегмента

• автор WAL может признать что все в WAL до данной контрольной точки было привязано к своему конечному месту назначения. Это может позволить пометить все, что было до контрольной точки, для сборки мусора или перезаписи.

Учитывая эту семантику, мне интересно, есть ли какой-нибудь другой компонент инфраструктуры IaaS, который лучше подходил бы для обработки записи WAL и трафика восстановления после сбоя - лучше, чем том SAN.

Под «лучше подходит» я имею в виду некоторую комбинацию этих соображений:

1. для связи с этим инфра-компонентом можно использовать протокол потоковой передачи, который более точно соответствует семантике WAL, чем протокол блочного хранения, такой как iSCSI, уменьшая накладные расходы на экземпляр;

2. WAL, с учетом его важности для восстановления после сбоев, с меньшей вероятностью будет поврежден, чем на отдельном томе SAN;

3. решение будет иметь более низкую стоимость за гигабайт записываемых данных WAL, чем стоимость тома SAN.

(Я, наверное, не могу получить все три, но два из трех было бы неплохо.)

Два класса инфра-компонентов, которые кажется для этого, но на самом деле не работают, надежные службы очереди сообщений (AWS SQS; Google Cloud Pub / Sub) и хранилище объектов (S3, GCS).

Оба этих типа сервисов позволяют быстро записывать небольшие сообщения / объекты, а затем надежно сохраняют / реплицируют их; но ни один тип службы не будет сохранять сообщение, которое было только частично написаны, и к тому же они слишком дороги для этого случая использования, даже по сравнению с диском SAN. WAL может иметь несколько ТБ данных, проходящих через него в день, и как хранилища объектов, так и очереди сообщений имеют, по сути, запись с оплатой за контрольную точку, что делает WAL, возможно, большинство хранить в них дорогие вещи.