Глава про RAM и persistent storage важна тем, что показывает не просто два типа памяти, а резкие ступени в цене задержки, объеме и долговечности данных.
В реальной работе это помогает проектировать hot path и cold path осмысленно: понимать, что держать в памяти, что переносить на SSD или HDD и как это меняет API, кэши и пользовательский опыт.
В интервью и архитектурных обсуждениях материал полезен тем, что делает разговор о хранилищах конкретным: через latency cliffs, durability и инфраструктурный бюджет.
Практическая польза главы
Иерархия памяти
Помогает проектировать hot/cold data path с учетом реальной разницы в задержках и стоимости.
Data placement
Учит, что держать в RAM, что в SSD/HDD, и как это влияет на API и пользовательский опыт.
Стабильность под нагрузкой
Показывает, как избежать деградации при росте working set и давлении на кэш.
Interview trade-offs
Усиливает объяснение компромиссов между скоростью доступа, долговечностью и бюджетом инфраструктуры.
Источник
Random-access memory
Устройство RAM и ключевые свойства оперативной памяти.
RAM и persistent storage работают как разные уровни одной иерархии: RAM даёт минимальную задержку для горячих данных, а SSD/HDD дают объём и долговечность. В System Design почти всегда нужен баланс между latency, capacity и стоимостью.
RAM vs persistent storage
Как устроена RAM
- DRAM организована в матрицы ячеек, адресуемые контроллером памяти.
- Доступ random access, но чтение внутри одной строки обычно быстрее (row buffer).
- Память требует периодического refresh, поэтому есть фоновая задержка.
- CPU работает через L1/L2/L3-кэши, скрывая часть latency RAM.
Как устроено постоянное хранение
- Хранение блочное: чтение/запись происходит страницами и блоками.
- HDD добавляет механический seek, SSD работает с NAND-страницами и erase-блоками.
- Производительность зависит от I/O-очередей, параллелизма и размера блока.
- Файловые системы и СУБД строят поверх этого журналы, индексы и стратегии компакции.
RAM
- Volatile: данные исчезают при отключении питания.
- Очень низкая задержка доступа и высокая скорость чтения/записи.
- Оптимальна для hot data, индексов и кэшей.
- Дороже persistent storage в пересчёте на ГБ.
Persistent storage
- Persistent: данные сохраняются без питания.
- Задержка доступа на порядки выше RAM.
- Гораздо больше доступная ёмкость.
- Ниже стоимость хранения на ГБ.
Динамическая визуализация: калькулятор объёма и tiering
Упрощённый калькулятор оценивает, сколько данных попадёт в RAM/SSD/HDD после репликации и компрессии.
Дневной ingest
600 GB/day
Retention
30 days
Replication
x3
Compression
2.0x
Hot data
20%
SSD доля warm data
60%
Индексный overhead
35%
Результат capacity-калькулятора
Итого данных
26.37 TB
RAM для hot set
3780 GB
SSD объём
12.66 TB
HDD объём
8.44 TB
Распределение данных по tier
Покрытие hot data RAM-контуром: 70%
Оценка monthly cost: $13781 (~$165372/year).
Источник
Solid-state drive
Базовые характеристики SSD и причины низкой задержки относительно HDD.
Динамическая визуализация: latency-калькулятор
Меняйте профиль нагрузки и смотрите, как cache-hit, random I/O и queue depth меняют p95 latency для разных слоёв хранения.
Cache hit ratio
85%
Random I/O
70%
Queue depth
16
Target IOPS
50,000
Latency SLO (p95)
15 ms
RAM
p95: 0.10 us
Device-only: 0.10 us
Load pressure: 0.20x
Укладывается в SLO
NVMe SSD
p95: 46 us
Device-only: 306 us
Load pressure: 0.20x
Укладывается в SLO
SATA SSD
p95: 313 us
Device-only: 2.08 ms
Load pressure: 0.71x
Укладывается в SLO
HDD
p95: 1084.1 ms
Device-only: 7227.2 ms
Load pressure: 142.86x
Не укладывается в SLO
Рекомендуемый primary tier: NVMe SSD
Текущие параметры укладываются в заданный SLO при выбранном профиле кэш-хитов.
Калькулятор выбора под нагрузку
Выберите профиль нагрузки и баланс между performance и cost. Калькулятор предложит целевую долю RAM/SSD/HDD.
Приоритет стоимости
45%
0 = performance-first, 100 = cost-first
Годовой рост нагрузки
+35%
Target p99
6 ms
Target IOPS
120,000
Рекомендуемая доля по tier
Прогноз ingest: 540 GB/day -> объём контура: 23.73 TB
Риск: проверьте growth и queue depth, чтобы избежать скрытой деградации в пиковые периоды.
Как выбирать под нагрузку
- Использовать агрессивный RAM-cache для hot key-space и индексов.
- Сделать SSD основным operational storage для чтения/записи под SLA.
- Холодный слой минимален: фокус на latency, а не на стоимость хранения.
Источник
Hard disk drive
Механический диск и особенности random/seq доступа.
HDD vs SSD в прикладной архитектуре
Для branch-heavy API и транзакционных нагрузок random I/O почти всегда требует SSD. HDD остаётся ценным слоем для архивов, исторических выборок и долгого хранения, когда latency не критична.
HDD
- Механические компоненты и вращающиеся пластины.
- Высокая задержка при random I/O из-за seek time.
- Большая ёмкость и низкая цена за ТБ.
- Подходит для холодных данных, бэкапов и архивов.
SSD
- Флеш-память без движущихся частей.
- Низкая задержка и высокий IOPS относительно HDD.
- Значительно лучше для random-доступа.
- Ограниченный ресурс записи, требует корректного lifecycle и мониторинга.
Частые ошибки
Держать весь датасет только на SSD
Без tiering стоимость быстро растёт, а cold-данные продолжают занимать дорогой быстрый слой.
Игнорировать working set
Если горячий рабочий набор не помещается в RAM, p95/p99 latency резко деградируют.
Считать только среднюю задержку
Для storage критичны хвосты распределения: p95/p99 и поведение под очередями I/O.
Нет политики lifecycle
Без автоматического перевода данных RAM -> SSD -> HDD система теряет предсказуемость стоимости.
Практические рекомендации
Tiered storage by access pattern
Горячие ключи и индексы держите в RAM, operational слой — на SSD, архив и долгий хвост — на HDD/объектном слое.
Capacity planning с запасом
Планируйте объём с учётом репликации, компрессии, индексов и годового роста нагрузки.
SLO-first выбор носителя
Сначала фиксируйте p99 latency и IOPS, затем подбирайте RAM/SSD/HDD и только после этого оптимизируйте цену.
Наблюдаемость storage-контура
Мониторьте cache hit ratio, queue depth, fsync latency и saturation каждого storage-tier.
Практический вывод
Выбор между RAM, SSD и HDD — это не бинарное решение, а проектирование многоуровневого storage-контура. Сначала фиксируйте SLO по latency и профиль нагрузки, затем планируйте объём и только после этого оптимизируйте стоимость через tiering и lifecycle.
Связанные главы
- Зачем нужны фундаментальные знания - поясняет, как ограничения памяти и дисков влияют на архитектурные решения.
- Structured Computer Organization (short summary) - даёт аппаратный контекст: иерархия памяти, шины и взаимодействие CPU с I/O.
- Операционная система: обзор - дополняет тему page cache, планированием I/O и влиянием kernel-space на latency.
- Зачем разбираться в системах хранения - расширяет тему до выбора DB-подходов, репликации, индексов и стратегии хранения.
- Database Selection Framework - помогает выбирать тип БД и storage-паттерн под конкретный профиль нагрузки.
- Performance Engineering в System Design - даёт практики профилирования latency/throughput и оптимизации bottleneck в I/O контуре.
- CPU и GPU: обзор и различия - связывает тему вычислительных ресурсов с memory bandwidth и data movement cost.