Обратная сторона расчета для интервью по проектированию системы

Расчет оборотной стороны конверта:
~ Быстрый и приблизительный расчет, который дает нам более глубокое понимание.

Назван он так, поскольку расчеты обычно можно проводить на обратной стороне конверта или салфетки. Примечание: для интервью они должны называться «Расчеты на доске».

Зачем нам это нужно?

Иногда мы сталкиваемся с выбором между альтернативными архитектурами. В самом простом случае мы можем спросить, достаточно ли одного сервера? Если не, сколько серверов нам потребуется? Быстрый расчет дает приблизительную оценку.

Как правило, расчет говорит нам

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

Как это сделать?

Во-первых, нам нужно распознать ограниченный ресурс в нашей системе, а затем аппроксимировать фактическое использование. Например, наши серверы ограничены процессорами с тактовой частотой 2 ГГц, и мы хотели бы знать, можем ли мы обслуживать все запросы пользователей, используя один сервер.

Итак, как приблизить фактическое использование? Нам надо разбить использование на составляющие его факторы, сделать грубую оценку этих факторов (при необходимости, их дальнейшее разбиение) и их объединение.

Например, можно ожидать, что у нас будет 1 тыс. активных пользователей, каждый из которых отправляет 15 запросов в день. Это 15 тыс. запросов в день или 15 тыс./86400 запросов в секунду.

При соединении частей, хитрость заключается в агрессивном округлении. Никто не хочет делить на 86400. Так что давайте округлим до 20K/100K, оставив 0,2 секунды времени для обслуживания одного запроса. Если мы знаем, что обработка одного запроса занимает примерно 0,7 секунды, нам нужно запустить как минимум 4 машины. Конечно, вы не хотите жить на грани, так что давайте добавим некоторый буфер и сделаем 10 машин (что также является более подходящим числом).

О быстрых операциях

Предпочитаю использовать небольшие числа вместе с аббревиатурой для величины (или, при необходимости, степени), а не писать полное число. 10К вместо 10000.

Если дано большое и слишком точное число, например 7432, немедленно преобразуйте его и запишите как 7К. Вы все равно приближаетесь.

Имея числа в этой форме делает умножение и деление быстрым. K*K — это M. G/M — это K. 4K*7M=28G. Чтобы работать с большими числами, округляйте их оба до меньшего, кратного степени 2 или 10.

27*14 ~= 30*10 = 300.
6500/250 ~= 6400/256 ~= 100 * 2^6/2^8 ~= 100/2^2 = 25.

Приблизительные размеры

Найдите типичные ограниченные размеры, а также упражнения ниже.

Пропускная способность сети

Предполагая, что канал 1 Гбит/с на машину, если мы хотим сканировать 70 ТБ веб-сайтов каждый день, сколько машин потребуется системе сканирования?

Пространство для хранения

Сколько места потребуется для хранения содержимого 100 миллионов веб-страниц? Что, если мы заменим каждое слово целочисленным индексом? Сколько машин с 64 ГБ SSD поместится?

пропускная способность ввода-вывода

Вы сохраняете извлеченные веб-страницы на механическом жестком диске с ограниченной скоростью произвольного доступа. Пользователи отправляют запросы со скоростью 100 запросов в секунду (qps), каждый запрос обычно возвращает содержимое 20 страниц. Сколько жестких дисков вам потребуется, чтобы поддерживать низкую задержку запросов?

Инженерные усилия.

Вам нужно предоставить новую функцию. Есть 5 программистов и 40 задач. Сколько недель до возможного запуска?

Деньги.

Пользователь платит 10 долларов в месяц за службу хранилища изображений, где хранятся все его фотографии, размер каждой из которых уменьшен до 3 МБ. В течение месяца пользователь получает 1 тыс. фотографий. Найдите страницу с ценами вашего любимого поставщика облачных услуг и рассчитайте стоимость, связанную с каждым пользователем. Какой у вас доход с пользователя? Проверьте различное предполагаемое количество фотографий.

Другие включают Процессорное время, объем оперативной памяти, различные задержки (доступ к диску, доступ к ОЗУ, сеть), количество потоков.

Когда начать?

Перечислите типичные варианты использования системы и определить наиболее важные ресурсы, которые им нужны. Магазину документов потребуется много места для хранения. Предположение о размерах и количестве документов — хорошее начало, но дальнейшие подробности будут зависеть от использования. Как часто добавляются новые документы? Доступны ли документы для поиска? Нужны ли нам какие-либо индексы? Это хранилище с интенсивной записью или чтением?

Различные варианты использования, вероятно, потребуют очень разных форм ресурсов. Например, для обслуживания документов может потребоваться много оперативной памяти, но не ЦП, а для предварительной обработки новых документов — наоборот. Размещение всех этих сервисов на однородных машинах приведет к пустой трате как ЦП, так и ОЗУ, поскольку вам нужно получить машины, которые максимальны по обоим измерениям.

Такие различия указывают на то, что функции должны быть разделены между различными службами, размещенными на независимых наборах машин.[efeaturesshouldbesplittodifferentserviceshostedonindependentsetsofmachines

Реальные данные

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

Это не должно быть или-или. При необходимости дополните предположения фактами, подтвержденными данными.