--- title: Алекс Сюй, «System Design. Подготовка к сложному интервью» (Vol. 1, рус. изд.) — глава 2: Приблизительные оценки source: materials/System Design. Подготовка к сложному интервью.pdf, стр. 40–45 конспект: TASK-45.38, извлечено pymupdf 2026-09-17; ниже полный «грязный» текст главы + выжимка статус: выжимка и перенос в knowledge-base.md / methodology.md / classic-designs.md — см. _map.md --- # Глава 2. Приблизительные оценки ## Выжимка Инструменты прикидки (скелет каждой оценки на секции): - **Степени двойки**: 2^10 ≈ 1 тыс., 2^20 ≈ 1 млн, 2^30 ≈ 1 млрд, 2^40 ≈ 1 трлн, 2^50 ≈ 1 квадр. - **Latency-числа** (от Ютдейла/Дина): L1 0.5 нс → RAM 100 нс → SSD random read 150 мкс → HDD seek 10 мс → через океан 150 мс. - **Доступность**: 99 % = 3.65 дня/год простоя; 99.9 % = 8.76 ч; 99.99 % = 52 мин; 99.999 % = 5 мин. - **Пример Twitter**: 100 млн DAU × 2 твита/день ≈ 2300–3500 QPS запись; медиа 30 ТБ/день; 5 лет хранения ≈ 55 ПБ. **Правила гигиены оценок**: округлять до круглых чисел (не 11.64 МБ, а 10 МБ); записывать допущения вслух; всегда подписывать единицы (KB = килобайт, Kb = килобит); проверять размерность формулы. Перенос: KB §1.3 (таблица nines), KB §2.5 (гигиена + пример Twitter). ## Полный текст (грязная выгрузка) 2 ПРИБЛИЗИТЕЛЬНЫЕ ОЦЕНКИ В ходе интервью по проектированию ИТ-систем претендента иногда просят «на коленке» оценить емкость или требования к производительности систе­ мы. Согласно Джеффу Дину, старшему сотруднику Google, «наколеночные вычисления — это оценки, основанные на мысленных экспериментах и ти­ пичных показателях производительности, которые дают хорошее представ­ ление о том, какие архитектуры соответствуют вашим требованиям» [1]. Для эффективного выведения приблизительных оценок нужно хорошо разбираться в основах масштабирования. Вы должны уверенно владеть следующими концепциями: степень двойки [2], показатели латентности, которые должен знать любой программист, и показатели доступности. СТЕПЕНЬ ДВОЙКИ В распределенных системах данные могут достигать огромных размеров, но все вычисления сводятся к элементарным свойствам. Чтобы получить правильный результат, нужно обязательно знать объем данных, используя вторую степень. Байт — это последовательность из 8 бит. Символ ASCII занимает в памяти один байт (8 бит). В табл. 2.1 перечислены единицы измерения данных. Таблица 2.1 Степень Примерное значение Полное название Сокращенное обозначение 10 1 тысяча 1 килобайт 1 Кб 20 1 миллион 1 мегабайт 1 Мб 30 1 миллиард 1 гигабайт 1 Гб 40 1 триллион 1 терабайт 1 Тб 50 1 квадрильон 1 петабайт 1 Пб Приблизительные оценки      41 ПОКАЗАТЕЛИ ЛАТЕНТНОСТИ, КОТОРЫЕ ДОЛЖЕН ЗНАТЬ ЛЮБОЙ ПРОГРАММИСТ В 2010 году доктор Дин из Google поделился данными о продолжи­ тельности типичных компьютерных операций [1]. Некоторые из этих показателей потеряли актуальность в связи с повышением производи­ тельности компьютеров. Но они по-прежнему должны давать хорошее представление о том, насколько быстрыми или медленными являются те или иные операции. Таблица 2.2 Название операции Время Обращение к кэшу L1 0,5 нс Ошибочное предсказание перехода 5 нс Обращение к кэшу L2 7 нс Блокирование/разблокирование мьютекса 100 нс Обращение к основной памяти 100 нс Сжатие 1 Кб с помощью Zippy 10 000 нс = 10 мкс Отправка 2 Кб по сети 1 Гбит/с 20 000 нс = 20 мкс Последовательное чтение из памяти 1 Мб 250 000 нс = 250 мкс Перемещение пакета туда и обратно внутри одного ЦОД 500 000 нс = 500 мкс Время поиска по диску 10 000 000 нс = 10 мс Последовательное чтение 1 Мб из сети 10 000 000 нс = 10 мс Последовательное чтение 1 Мб с диска 30 000 000 нс = 30 мс Передача пакета из Калифорнии в Нидерланды и обратно 150 000 000 нс = 150 мс Обозначения: нс = наносекунда, мкс = микросекунда, мс = миллисекунда 1 нс = 10^-9 секунд 1 мкс = 10^-6 секунд = 1000 нс 1 мс = 10^-3 секунд = 1000 мкс = 1 000 000 нс 42      ГЛАВА 2 Один разработчик ПО из Google написал утилиту для визуализации по­ казателей, опубликованных доктором Дином. Помимо прочего, она делает поправку на современные реалии. На рис. 2.1 даны визуализированные показатели латентности по состоянию на 2020 год (источник данных: справочный материал [3]). Рис. 2.1 Проанализировав цифры, представленные на рис. 2.1, мы можем сделать следующие выводы: память быстрая, а диск медленный; по возможности следует избегать поиска по диску; простые алгоритмы сжатия отличаются высокой скоростью; Приблизительные оценки      43 прежде чем отправлять данные по интернету, их по возможности нужно сжимать; центры обработки данных обычно находятся в разных регионах, и передача информации между ними занимает время. ПОКАЗАТЕЛИ ДОСТУПНОСТИ Высокая доступность — это способность системы долго и непрерывно находиться в рабочем состоянии. Она измеряется в процентах. 100 % означает, что сервис никогда не простаивает. У большинства сервисов доступность варьируется от 99 % и 100 %. Поставщики сервисов часто используют такой термин, как соглашение об уровне услуг (service level agreement, SLA). Это соглашение между вами (поставщиком) и вашим клиентом, которое официально определяет уровень беспрерывной работы вашего сервиса. Облачные провайдеры Amazon [4], Google [5] и Microsoft [6] предлагают SLA от 99,9 % и выше. Время беспрерывной работы обычно измеряется в девятках. Чем больше девяток, тем лучше. Как видно из табл. 2.3, количество девяток соответ­ ствует ожидаемому времени простоя системы. Таблица 2.3 Доступность Суточный простой Недельный простой Месячный простой Годичный простой 99 % 14,40 минуты 1,68 часа 7,31 часа 3,65 дня 99,9 % 1,44 минуты 10,08 минуты 43,83 минуты 8,77 часа 99,99 % 8,64 секунды 1,01 минуты 4,38 минуты 52,60 минуты 99,999 % 864,00 миллисекунды 6,05 секунды 26,30 секунды 5,26 минуты 99,9999 % 86,40 миллисекунды 604,80 миллисекунды 2,63 секунды 31,56 секунды ПРИМЕР: ОЦЕНКА ТРЕБОВАНИЙ К QPS И ХРАНИЛИЩУ ДЛЯ TWITTER Пожалуйста, имейте в виду, что следующие цифры относятся лишь к на­ шему упражнению и не имеют ничего общего с реальными показателями Twitter. 44      ГЛАВА 2 Предположения: 300 миллионов активных пользователей в месяц; 50 % из них пользуются Twiter ежедневно; пользователи в среднем публикуют по 2 твита в день; 100 % твитов содержат медиаданные; данные хранятся на протяжении 5 лет. Оценки: ежедневные активные пользователи (daily active users, DAU) = 300 миллионов * 50 % = 150 миллионов; запросов в секунду (queries per second, QPS) = 150 миллионов * 2 твита / 24 часа / 3600 секунд = ~3500; пиковый показатель QPS = 2 * QPS = ~7000. Здесь мы оценим лишь место, необходимое для хранения данных: средний размер твита: Š Š tweet_id — 64 байта; Š Š текст — 140 байтов; Š Š медиаданные — 1 Мб; объем данных: 150 миллионов * 2 * 10% * 1 Мб = 30 Тб в день; объем данных за 5 лет: 30 Тб * 365 * 5 = ~55 Пб. СОВЕТЫ Главное в наколеночных оценках — процесс. То, как вы решаете задачу, важнее результатов. Интервьюеры могут проверить ваши навыки реше­ ния задач. Вот несколько советов. Округление и приближение. Во время интервью сложно прово­ дить серьезные математические расчеты. Например, сколько будет 99987/9,1? Не нужно тратить ценное время на сложную арифме­ тику. От вас не ждут высокой точности. Для удобства пользуйтесь Приблизительные оценки      45 округленными и приблизительными числами. Вопрос с делением можно упростить до 100 000/10. Записывайте свои предположения, чтобы позже на них можно было сослаться. Не забывайте о единицах измерения. Когда вы записываете 5, это означает 5 Кб или 5 Мб? Вы можете запутаться. Указывайте единицы измерения, поскольку это помогает избавиться от не­ определенности. Поздравляем, вы проделали длинный путь и можете собой гордиться. Отличная работа! СПРАВОЧНЫЕ МАТЕРИАЛЫ [1]  J. Dean, Google Pro Tip: Use Back-Of-The-Envelope-Calculations To Choose The Best Design: http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back- ofthe-envelope-calculations-to-choo.html [2]  System design primer: https://github.com/donnemartin/systemdesign-primer [3]  Latency Numbers Every Programmer Should Know: https://colin-scott.github. io/personal_website/research/interactive_ latency.html [4]  Amazon Compute Service Level Agreement: https://aws.amazon.com/compute/ sla/ [5]  Compute Engine Service Level Agreement (SLA): https://cloud.google.com/ compute/sla [6]  SLA summary for Azure services: https://azure.microsoft.com/en-us/support/ legal/sla/summary/