Выбор хранилища: обзор с выбором ответа
Синтез всего раздела хранилищ в формате с выбором ответа: SQL против NoSQL и обмен ACID/BASE, дизайн под паттерны доступа, блобы против объектного хранилища с presigned-ссылками, долговечность против доступности, специализированные хранилища и проблема двойной записи.
Шесть вопросов через весь раздел. Каждый — решение, которое ты принимаешь на дизайн-ревью или у доски: какое хранилище подходит нагрузке, где живут байты, какой согласованностью ты торгуешь и как два хранилища держатся в синхроне — не определение для пересказа.
Убедись, что умеешь разместить нагрузку на оси SQL/NoSQL по нужной согласованности, заметить, когда дизайн под паттерны доступа укусит, держать байты вне базы, разделить долговечность и доступность, выбрать специализированное хранилище на измеренном пределе и избежать тихого расхождения двойной записи.
Фича должна атомарно перевести деньги между двумя строками без промежуточного состояния, видимого параллельным транзакциям. Какое свойство не обсуждается и какой класс хранилища его обычно даёт?
Ты смоделировал key-value таблицу под «получить элемент по id». Полгода спустя продукту нужно «перечислить все элементы клиента, новые сверху», а клиента в ключе нет. Что предсказывает дизайн под паттерны доступа?
Видеоприложение хранит многогигабайтные загрузки как BYTEA в Postgres, «чтобы байты и метаданные были в одной транзакции». Что ломается на масштабе и какова починка?
«S3 долговечен на одиннадцать девяток, так что наши картинки переживут любой сбой, и межрегиональная репликация не нужна». В чём точная поправка?
Поисковая строка гонит `WHERE description LIKE '%word%'` по таблице на 3 млн строк с B-tree индексом на description и отваливается по таймауту под нагрузкой. Каков вердикт и правильный инструмент?
Ты пишешь заказ в Postgres, потом best-effort индексируешь его в Elasticsearch (логируешь и игнорируешь провалы), чтобы держать запрос быстрым. Месяцы спустя поиск непредсказуемо теряет заказы. Корневая причина и починка?
- 01Почему «долговечно на одиннадцать девяток» — не «всегда доступно» и что закрывает разрыв?
- 02Как держать поисковый индекс согласованным с базой без двойной записи?
Сквозная линия — выбор хранилища это подгонка нагрузки под гарантии, которые хранилище реально даёт. Деньгам нужны ACID-атомарность и изоляция (реляционка), а не BASE — схождение «в итоге» это окно, которого нельзя допустить. Дизайн под паттерны доступа NoSQL быстр для запланированных паттернов и зверский для незапланированных, так что новый запрос без совпадающего ключа деградирует в скан. Крупные байты никогда не идут в базу (раздутые бэкапы, отравленный буфер-кеш, раздутый WAL, голодание пула) — держи метаданные в БД, байты в объектном хранилище, отдавая через presigned-ссылки. Долговечность — не доступность: одиннадцать девяток значат, что байты не потеряются, а не что регион не может погаснуть, для чего и нужна межрегиональная репликация. Специализированное хранилище (time-series, поиск) заслуживает место на измеренном пределе и считается производным индексом, а проблема двойной записи решается выводом этого индекса из одного авторитетного коммита через CDC или транзакционный outbox — никогда две независимые записи.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.