Back-Of-The-Envelope-Calculations: подход Google к проектированию систем
Как узнать, какой вариант лучше всего подходит для данной проблемы? Если, например,
«у вас возникла проблема создания страницы результатов поиска изображений из 30 эскизов, не могли бы вы загружать изображения последовательно? В параллели? Вы бы кешировали? Как бы вы решили? »
Один из способов - начать реализовывать все возможные варианты и посмотреть, как можно добиться максимального прироста производительности. Но это безумно непрактично, не правда ли? Но есть другой способ обойти это, мы можем использовать метод «Обратные вычисления», который обычно используется Google в качестве обходного пути для таких проблем. . Давайте посмотрим, как это работает, и определимся с тем, что вы собираетесь реализовать дальше.
Оцените разные дизайны: числа, которые вам следует знать раньше
Джефф Дин, руководитель Google School of Infrastructure Wizardry - играет важную роль во многих ключевых системах Google: показ рекламы, BigTable; search, MapReduce, ProtocolBuffers - пропагандирует оценку различных проектов с помощью скрытых расчетов. Он дает полную историю в этой видеопрезентации Стэнфорда.
Предварительные расчеты - это оценки, которые вы создаете с помощью комбинации мысленных экспериментов и общих показателей производительности, чтобы получить хорошее представление о том, какие проекты будут соответствовать вашим требованиям. Д-р Дин считает, что важным навыком для каждого инженера-программиста является способность оценивать производительность альтернативных систем с использованием расчетов на обратной стороне конверта, не создавая их. Чтобы оценить альтернативы дизайна, вам сначала нужно хорошо понимать, сколько времени займет типичная операция. Вот список, который он дал
- Ссылка кэша L1 0,5 нс
- Ошибочный прогноз ветвления 5 нс
- Ссылка на кэш L2 7 нс
- Блокировка / разблокировка мьютекса 100 нс
- Ссылка на основную память 100 нс
- Сжать 1 Кбайт с помощью Zippy 10,000 нс
- Отправка 2 Кбайт по сети 1 Гбит / с 20000 нс
- Последовательное чтение 1 МБ из памяти 250 000 нс
- Поездка туда и обратно в одном центре обработки данных 500000 нс
- Поиск по диску 10,000,000 нс
- Последовательное чтение 1 МБ из сети 10 000 000 нс
- Последовательное чтение 1 МБ с диска 30 000 000 нс
- Отправить пакет CA- ›Нидерланды-› CA 150,000,000 нс
Здесь можно увидеть множество фактов:
- Обратите внимание на разницу в производительности разных опций.
- Центры обработки данных находятся далеко, поэтому на передачу чего-либо между ними уходит много времени.
- Память быстрая, а диски медленные.
- Используя дешевый алгоритм сжатия, можно сэкономить значительную (в 2 раза) пропускную способность сети.
- Запись в 40 раз дороже чтения.
- Обмен данными по всему миру стоит дорого. Это фундаментальное ограничение распределенных систем. Конфликт блокировок в совместно используемых сильно записанных объектах снижает производительность, поскольку транзакции становятся сериализованными и медленными.
- Пишет архитектор по масштабированию.
- Оптимизация для уменьшения числа конфликтов записи.
- Широкая оптимизация. Делайте записи как можно более параллельными.
Поскольку вы узнали эти числа сейчас, мы можем вернуться к первоначальной проблеме, которую мы обсуждали.
Страница результатов создания изображений из 30 эскизов
Вариант 1 - Последовательный
- Читайте изображения поочередно. Сделайте поиск диска. Прочтите изображение размером 256 КБ, а затем перейдите к следующему изображению.
- Производительность: 30 поисков * 10 мс / поиск + 30 * 256 КБ / 30 МБ / с = 560 мс
Вариант 2 - Параллельный
- Выпуск читается параллельно.
- Производительность: 10 мс / поиск + 256 КБ чтения / 30 МБ / с = 18 мс
- Показания с диска будут отличаться, поэтому более вероятное время составляет 30–60 мсек.
Какой дизайн лучше? Это зависит от ваших требований, но с учетом предварительных расчетов у вас есть быстрый способ сравнить их, не создавая их.
Теперь у вас есть система, позволяющая задавать себе другие вопросы по дизайну и сравнивать различные варианты дизайна:
- Есть ли смысл кэшировать отдельные миниатюры?
- Следует ли кэшировать весь набор изображений в одной записи?
- Есть ли смысл предварительно вычислять эскизы?
Чтобы сделать эти оценки реалистичными, вам необходимо знать эффективность ваших услуг. Если есть неизвестная переменная, то, возможно, вы могли бы быстро создать прототип именно этой части, чтобы решить вопрос. Например, чтобы узнать, является ли кеширование хорошей альтернативой дизайну, вам нужно знать, сколько времени требуется для записи в ваш кеш.
