Источники информации

Эта запись является переводом с английского, автор оригинальной версии — Todd Hoff. Оригинал написан приблизительно в середине 2007 года, но по-моему до сих пор очень даже актуально.

Далее следует перечисление источников информации из оригинала:

• Video: Построение больших систем в Google
• Google Lab: Файловая система Google (GFS)
• Google Lab: MapReduce: упрощенная обработка данных на больших кластерах
• Google Lab: BigTable.
• Video: BigTable: система распределенного хранения данных.
• Как работает Google от David Carr в Baseline Magazine.
• Google Lab: интерпретирование данных. Параллельный анализ с помощью Sawzall.
• Записи с конференции по масштабированию от Dare Obasonjo.

Платформа

• Linux
• Большое разнообразие языков программирования: Python, Java, C++

Что внутри?

Статистика

• На 2006 год система включала в себя 450000 недорогих серверов
• За 2005 год было проиндексировано 8 миллиардов страниц. На данный момент… кто знает?
• На момент написания оригинала Google включает в себя более 200 GFS кластеров. Один кластер может состоять из 1000 или даже 5000 компьютеров
• Десятки и сотни тысяч компьютеров получают данные из GFS кластеров, которые насчитывают более 5 петабайт дискового пространства. Суммарные пропускная способность операций записи и чтения между дата центрами может достигать 40 гигабайт в секунду
• BigTable позволяет хранить миллиарды ссылок (URL), сотни терабайт снимков со спутников, а также настройки миллионов пользователей

// Цифры не первой свежести конечно, но тоже неплохо.

Стек

Google визуализирует свою инфраструктуру в виде трехслойного стека:

• Продукты: поиск, реклама, электронная почта, карты, видео, чат, блоги
• Распределенная инфраструктура системы: GFS, MapReduce и BigTable
• Вычислительные платформы: множество компьютеров во множестве датацентров
• Легкое развертывание для компании при низком уровне издержек
• Больше денег вкладывается в оборудование для исключения возможности потерь данных

Надежное хранение данных с помощью GFS

• Надежное масштабируемое хранение данных крайне необходимо для любого приложения. GFS является основой их платформы хранения информации
• GFS — большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации
• Зачем строить что-либо самим вместо того, чтобы просто взять это с полки? Они контролируют абсолютно всю систему и именно эта платформа отличает их от всех остальных. Она предоставляет:

  – высокую надежность дата центров

  – масштабируемость до тысяч сетевых узлов

  – высокую пропускную способность операций чтения и записи

  – поддержку больших блоков данных, размер которых может измеряться в гигабайтах

  – эффективное распределение операций между датацентрами для избежания возникновения “узких мест” в системе

• В системе существуют мастер-сервера и сервера, собственно хранящие информацию:

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

  – Для обеспечения надежности один и тот же блок данных хранится в трех экземплярах на разных серверах, что обеспечивает избыточность на случай сбоев в работе какого-либо сервера.

  – Новые приложения могут пользоваться как существующими кластерами, так и новыми, созданными специально для них.

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

Работаем с данными при помощи MapReduce

• Теперь, когда у нас есть отличная система хранения, что же делать с такими объемами данных? Допустим, у нас есть много терабайт данных, равномерно распределенных между 1000 компьютерами. Коммерческие базы данных не могут эффективно масштабироваться до такого уровня, именно в такой ситуации в дело вступает технология MapReduce.
• MapReduce является программной моделью и соответствующей реализацией обработки и генерации больших наборов данных. Пользователи могут задавать функцию, обрабатывающую пары ключ/значение для генерации промежуточных аналогичных пар, и сокращающую функцию, которая объединяет все промежуточные значения, соответствующие одному и тому же ключу. Многие реальные задачи могут быть выражены с помощью этой модели. Программы, написанные в таком функциональном стиле автоматически распараллеливаются и адаптируются для выполнения на обширных кластерах. Система берет на себя детали разбиения входных данных на части, составления расписания выполнения программ на различных компьютерах, управления ошибками, и организации необходимой коммуникации между компьютерами. Это позволяет программистам, не обладающим опытом работы с параллельными и распределенными системами, легко использовать все ресурсы больших распределенных систем.
• Зачем использовать MapReduce?

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

  – Обработка сбоев в работе

  – Работа с различными типами смежных приложений, таких как поиск или реклама. Возможно предварительное вычисление и обработка данных, подсчет количества слов, сортировка терабайт данных и так далее

  – Вычисления автоматически приближаются к источнику ввода-вывода

• MapReduce использует три типа серверов:

  – Master: назначают задания остальным типам серверов, а также следят за процессом их выполнения

  – Map: принимают входные данные от пользователей и обрабатывают их, результаты записываются в промежуточные файлы

  – Reduce: принимают промежуточные файлы от Map-серверов и сокращают их указанным выше способом

• Например, мы хотим посчитать количество слов на всех страницах. Для этого нам необходимо передать все страницы, хранимые в GFS, на обработку в MapReduce. Этот процесс будет происходить на тысячах машин одновременно с полной координацией действий, в соответствии с автоматически составленным расписанием выполняемых работ, обработкой потенциальных ошибок, и передачей данных выполняемыми автоматически.

  – Последовательность выполняемых действий выглядела бы следующим образом: GFS → Map → перемешивание → Reduce → запись результатов обратно в GFS

  – Технология MapReduce состоит из двух компонентов: соответственно map и reduce. Map отображает один набор данных в другой, создавая тем самым пары ключ/значение, которпыми в нашем случае являются слова и их количества.

  – В процессе перемешивания происходит аггрегирование типов ключей.

  – Reduction в нашем случае просто суммирует все результаты и возвращает финальный результат.

• В процессе индексирования Google подвергает поток данных обработке около 20 разных механизмов сокращения. Сначала идет работа над всеми записями и аггрегированными ключами, после чего результат передается следующему механизму и второй механизм уже работает с результатами работы первого, и так далее.
• Программы могут быть очень маленькими, всего лишь от 20 до 50 строк кода.
• Единственной проблемой могут быть “отстающие компьютеры”. Если один компьютер работает существенно медленнее, чем все остальные, это будет задерживать работу всей системы в целом.
• Транспортировка данных между серверами происходит в сжатом виде. Идея заключается в том, что ограничивающим фактором является пропускная способность канала и ввода-вывода, что делает резонным потратить часть процессорного времени на компрессию и декомпрессию данных.

Хранение структурированных данных в BigTable

• BigTable является крупномасштабной, устойчивой к потенциальным ошибкам, самоуправляемой системой, которая может включать в себя терабайты памяти и петабайты данных, а также управлять миллионами операций чтения и записи в секунду.
• BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных и, как следствие, не поддерживает SQL-запросы и операции типа Join.
• Она предоставляет механизм просмотра данных для получения доступа к структурированным данным по имеющемуся ключу. GFS хранит данные не поддающиеся пониманию, хотя многим приложениям необходимы структурированные данные.
• Коммерческие базы данных попросту не могут масштабироваться до такого уровня и, соответственно, не могут работать с тысячами машин одновременно.
• С помощью контролирования своих низкоуровневых систем хранения данных, Google получает больше возможностей по управлению и модификации их системой. Например, если им понадобится функция, упрощающая координацию работы между датацентрами, они просто могут написать ее и внедрить в систему.
• Подключение и отключение компьютеров к функционирующей системе никак не мешает ей просто работать.
• Каждый блок данных хранится в ячейке, доступ к которой может быть предоставлен как по ключу строки или столбца, так и по временной метке.
• Каждая строка может храниться в одной или нескольких таблицах. Таблицы реализуются в виде последовательности блоков по 64 килобайта, организованных в формате данных под названием SSTable.
• В BigTable тоже используется три типа серверов:

  – Master: распределяют таблицы по Tablet-серверам, а также следят за расположением таблиц и перераспределяют задания в случае необходимости.

  – Tablet: обрабатывают запросы чтения/записи для таблиц. Они раделяют таблицы, когда те превышают лимит размера (обычно 100-200 мегабайт). Когда такой сервер прекращает функционирование по каким-либо причинам, 100 других серверов берут на себя по одной таблице и система продолжает работать как-будто ничего не произошло.

  – Lock: формируют распределенный сервис ограничения одновременного доступа. Операции открытия таблицы для записи, анализа Master-сервером или проверки доступа должны быть взаимноисключающими.

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

Оборудование

• Как эффективно организовать большую группу компьютеров с точки зрения издержек и производительности?
• Используется самое обыкновенное ультра-дешевое оборудование и поверх него строится программное обеспечение, способное спокойно пережить смерть любой части оборудования.
• Тысячекратный рост вычислительной мощности может быть достигнут с издержками в 33 раза меньшими, если воспользоваться толерантной к сбоям инфраструктурой, по сравнению с инфраструктурой, построенной на высоконадежных компонентах. Надежность строится поверх ненадежных компонентов.
• Linux, домашнее размещение серверов, материнске платы предназначенные для персональных компьютеров, дешевые средства хранения данных.
• Цена за каждый ватт энергии в расчете на производительность не становится меньше, что ведет к большим проблемам связанным с энергообеспечением и охлаждением.
• Использование совместного размещения в своих и арендуемых датацентрах.

Разное

• Быстрый выпуск изменений более предпочтителен, чем ожидание.
• Библиотеки — превалирующий метод построения программ.
• Некоторые приложения предоставляются в виде сервисов.
• Инфраструктура управляет определением версий приложений таким образом, что они могут выпускать новые продукты, не боясь сломать работу какого-либо компонента системы.

Пути развития

• Поддержка географически распределенных кластеров.
• Создание единого глобального пространства имен для всех данных. На данный момент данные распределены по кластерам.
• Более автоматизированные передача и обработка данных
• Решение вопросов, связанных с поддержанием работоспособности сервисов даже в тех случаях, когда целый кластер отключается от системы в связи с техническими работами или каким-либо сбоем в работе.

Подводим итоги

• Инфраструктура может быть конкурентным преимуществом. Это определенно так для Google. Они могут выпускать новые интернет сервисы быстрее, с меньшими издержками, на таком уровне, что мало кто сможет составить им конкуренцию. Подход многих компаний сильно отличается от подхода Google, эти компании рассматривают инфраструктуру как статью расходов, они обычно используют совсем другие технологии и совсем не задумываются о планировании и организации своей системы. Google позиционирует себя как компанию по построению систем, что является очень современным подходом к разработке программного обеспечения.
• Охватывание нескольких дата центров до сих пор является нерешенной проблемой. Большинство сайтов базируется в одном или двух дата центрах. Полное распределение сайта между несколькими датацентрами является хитрой задачей.
• Взгляните на Hadoop, если у Вас нет времени на собственноручное построение всей архитектуры с нуля. Hadoop явялется opensource воплощением в жизнь многих идей здесь представленных.
• Часто недооцениваемым преимуществом платформенного подхода является тот факт, что даже неопытные разработчики могут быстро и качественно реализовывать трудоемкие приложения на базе платформы. Но если бы каждый проект требовал одинаково распределенной архитектуры, то это создало бы много проблем, так как люди, которые понимают как это делается, являются достаточно большой редкостью.
• Совместная деятельность не всегда является таким уж плохим занятием. Если все части системы работают взаимосвязанно, то улучшение в одной из них сразу и абсолютно прозрачно отразится положительным образом и на остальных компонентах системы. В противном случае такой эффект наблюдаться не будет.
• Построение самоуправляемых систем позволяет более легко перераспределять ресурсы между серверами, расширять систему, отключать некоторые компьютеры и элегантно проводить обновления.
• Производить длительные операции стоит параллельно.
• Всему, что было сделано Google, предшествовало искусство, а не только крупномасштабное развертывание системы.
• Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.

Источники информации

Этот пост является переводом статьи от Todd’а Hoff’а.  Далее привожу источники информации из оригинальной статьи:

• Flickr и PHP (ранний документ)
• Планирование нагрузок на LAMP
• Федерация Flickr: Тур по архитектуре Flickr
• Построение масштабируемых веб-сайтов от Call Handerson’а из Flickr
• История войн баз данных #3: Tim O’Reilly о Flickr
• Cal Henderson’s Talks — много полезных презентаций

Платформа

• PHP
• MySQL
• Сегментирование (прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова “Shards”)
• Memcached для кэширования
• Squid в качестве обратной-прокси для HTML и изображений
• Linux (RedHat)
• Smarty в роли шаблонизатора
• Perl
• PEAR для парсинга e-mail и XML
• ImageMagick для обработки изображений
• Java для узлового сервиса
• Apache
• SystemImager для развертывания систем
• Ganglia для мониторинга распределенных систем
• Subcon хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.
• Cvsup для распространения и обновления коллекций файлов по сети

Статистика

• Более четырех миллиардов запросов в день
• Примерно 35 миллионов фотографий в кэше Squid
• Около двух миллионов фотографий в оперативной памяти Squid
• Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
• 38 тысяч запросов к memcached (12 миллионов объектов)
• 2 петабайта дискового пространства
• Более 400000 фотографий добавляются ежедневно

Архитектура

Симпатичное изображение архитектуры Flickr можно увидеть на этом слайде. Краткое ее описание выглядит следующим образом:
–– Два ServerIron
–––– Squid кэши
–––––– Системы хранения NetApp
–––– Серверы PHP-приложений
–––––– Менеджер хранения данных
–––––– Master-master сегменты
–––––– Центральная база данных, структурированная по принципу Dual Tree
–––––– Memcached кластер
–––––– Поисковая система

– Структура Dual Tree является индивидуальным набором модификаций для MySQL, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.

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

• Использование выделенных серверов для статического контента.
• Все, за исключением фотографий, хранится в базе данных
• Отсутствие состояний заключается в том, что они передают пользователей от сервера к серверу, что облегчает для них создание своего API
• В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения
• Для поиска по определенной части базы данных создается отдельная копия этого фрагмента
• Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему
• Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью PHP
• Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.
• Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.
• Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе “Источники информации”.
• Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:

  – Сегменты системы: Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.

  – Глобальное кольцо: Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.

  – Логика на PHP устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)

• Сегменты:

  – Срез основной базы данных

  – Активная репликация по принципу мастер-мастер: имеет несколько недостатков в MySQL 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре

  – Привязывание новых учетных записей к сегментам системы происходит случайным образом

  – Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий… 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.

• Нажатие на Favorite:

  – Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)

  – Получается информация о моей учетной записи из кэша, более конкретно — мой сегмент (например shard-13)

  – Начинается “распределенная трансакция” для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?

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

  – при каждой загрузке страницы, пользователю предоставляется список серверов

  – если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился — выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.

• Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.
• Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.
• Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.
• В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.
• Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.
• Каждый сегмент содержит данные о более чем 400 тысячах пользователей.

  – Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Трансакции используются для предотвращения рассинхронизации данных: открывается первая трансакция, выполняется запись, открывается вторая трансакция, выполняется запись, подтверждается первая трансакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.

• Поиск:

  - Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!

  - В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.

  - Эту систему стоит рассматривать как аналог Lucene.

• Оборудование:

  - EMT64 под управлением RHEL 4 с 16 GB оперативной памяти.

  - 6 жестких дисков с 15000rpm, объединены в RAID-10.

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

  - Используются 2U корпуса.

• Процедура резервного копирования данных:

  - ibbackup выполняется регулярно посредством cron daemon’а, на каждом сегменте настроен на разное время.

  - Каждую ночь делается снимок со всего кластера баз данных.

  - Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.

  - Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.

• Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.
• Аггрегация данных проходит очень быстро, так как она ограничена пределами сегмента.
• max_connections = 400 соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.
• Тэги:

  - Тэги плохо вписываются в традиционную нормализованную схему реляционной базы данных. Денормализация или активное кэширование — единственные способы сгенерировать облако меток для сотен миллионов тэгов в течении миллисекунд.

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

• Направления для развития: ускорение работы с помощью создания организационного плана для непрерывной работы всей системы на уровне нескольких датацентров, таким образом чтобы все датацентры имели возможность получать запросы на общий уровень данных (как сами БД, так и memcache и прочее) все вместе одновременно. Если все части системы постоянно активны — время простоя оборудования будет сведено к минимуму.

Подводим итоги

• Старайтесь думть о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.
• Отсутствие состояний системы позволяет более выполнять модернизации не моргнув и глазом.
• Реструктуризация базы данных — не самое лучшее занятие.
• Планирование нагрузок должно проводиться уже на ранних этапах развития проекта
• Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.
• Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.
• Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.
• Кэширование и оперативная память может стать ответом на все вопросы.
• Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.
• Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.
• Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.
• Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.
• Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.
• Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.
• Найдите максимальное значения для всех показателей:

  - Какой максимум чего-то, что может выполнять каждый сервер?

  - Как близко параметр находится к максимуму и каковы тенденции?

  - MySQL (дисковый ввод/вывод?)

  - Squid (дисковый ввод/вывод? или процессорное время?)

  - Memcached (процессорное время? или пропускная способность сети?)

• Старайтесь учесть особенности использования Вашего приложения.

  - Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?

  - Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.

  - По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.

• Учтите возможность экспонентациального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
• Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.

This month I present to you the amazingly good videos on scalability and scalable architectures.

They cover real life scalability issues and solutions at YouTube, Twitter, LiveJournal and Wikipedia. Some other videos are on more theoretical aspects of scalability such as design of effective data storage systems and effective algorithms to read and modify the data.
Also I found some video lectures on MySQL tuning, clustering and high availability.

Enjoy!

BigTable: Google’s Distributed Structured Storage System

• Video on BigTable (from Google Video, by Jeff Dean)
• Video on BigTable (alternative, from University of Washington TV)
• Notes on Google BigTable

Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers. Many projects at Google store data in Bigtable, including web indexing, Google Earth, and Google Finance. These applications place very different demands on Bigtable, both in terms of data size (from URLs to web pages to satellite imagery) and latency requirements (from backend bulk processing to real-time data serving). Despite these varied demands, Bigtable has successfully provided a flexible, high-performance solution for all of these Google products. In this paper we describe the simple data model provided by Bigtable, which gives clients dynamic control over data layout and format, and we describe the design and implementation of Bigtable.

MapReduce Used on Large Data Sets

• Video Lecture on MapReduce

MapReduce is a programming model and library designed to simplify distributed processing of huge datasets on large clusters of computers. This is achieved by providing a general mechanism which largely relieves the programmer from having to handle challenging distributed computing problems such as data distribution, process coordination, fault tolerance, and scaling. While working on Google maps, I’ve used MapReduce extensively to process and transform datasets which describe the earth’s geography. In this talk, I’ll introduce MapReduce, demonstrating its broad applicability through example problems ranging from basic data transformation to complex graph processing, all the in the context of geographic data.

Abstractions for Handling Large Datasets

• Video on Handling Large Datasets

MapReduce, BigTable, and Other Distributed System Abstractions for Handling Large Datasets Jeff Dean, Google, Inc. Search is one of the most important applications used on the internet, but it also poses some of the most interesting challenges in computer science. Providing high-quality search requires understanding across a wide range of computer science disciplines, from lower-level systems issues like computer architecture and distributed systems to applied areas like information retrieval, machine learning, data mining, and user interface design. In this talk, I’ll highlight some of the behind-the-scenes pieces of infrastructure that we’ve built in order to operate Google’s services.

Building Large Systems at Google

• Video Lecture on Building Large Systems

Google deals with large amounts of data and millions of users. We’ll take a behind-the-scenes look at some of the distributed systems and computing platform that power Google’s various products, and make the products scalable and reliable.

YouTube Scalability

• Video Presentation on YouTube Scalability

This talk will discuss some of the scalability challenges that have arisen during YouTube’s short but extraordinary history. YouTube has grown incredibly rapidly despite having had only a handful of people responsible for scaling the site. Topics of discussion will include hardware scalability, software scalability, and database scalability.

Blaine Cook on Scaling Twitter

• Video Lecture on Scaling Twitter
• Lecture Slides

Blaine gave this talk on how they scaled Twitter. Twitter is probably the largest Ruby on Rails application in production today, so it was filled with lots of great insights including many not so obvious tips.

Wikipedia and MediaWiki

• Video Lecture on Wikipedia

Over four years, MediaWiki has evolved from a quick hack to run a little-known encyclopedia web site to the monster engine behind a heavily-used public site, while maintaining the simplicity needed for an entry-level intranet wiki. Brion reviews past and future directions for Wikipedia’s software and hardware, and how modern buzzword technologies could power and simplify the wiki world.

Behind the Scenes at LiveJournal: Scaling Storytime

• Video Lecture on Scaling LiveJournal

The history and lessons learned while scaling a community site (LiveJournal.com) from a single server with a dozen friends to hundreds of machines and 10M+ users. What’s worked, what hasn’t, and all the things we’ve had to build ourselves, now in common use thoughout the «Web 2.0″ world, including memcached, MogileFS, Perlbal, and our job dispatch systems.

Lessons In Building Scalable Systems

• Video Lecture on Building Scalable Systems

Since launching Google Talk in the summer of 2005, we have integrated the service with two large existing products: Gmail and orkut. Each of these integrations provided unique scalability challenges as we had to handle a sudden big increase in the number of users. Today, Google Talk supports millions of users and handles billions of packets per day. I will discuss several practical lessons and key insights from our experience that can be used for any project. These lessons will cover both engineering and operational areas. Reza Behforooz is a Staff Engineer at Google and is currently the technical lead for the Google Talk servers. He’s passionate about building large systems and working on communication products in an attempt to make the world a smaller place. While at Google, he has primarily worked on Google Talk, Gmail, orkut, Google Groups, and shared infrastructure used by several Google applications.

Distributed Caching Essential Lessons

• Video Lecture on Distributed Caching

In this presentation, recorded at Javapolis, Cameron Purdy shows how to improve application performance & scalability via caching architectures to reduce load on the database tier and & clustered caching to provide transparent fail-over by reliably sharing live data among clustered JVMs.

Lustre File System

• Video Lecture on Lustre Filesytems

Lustre is a scalable open source Linux cluster file system that powers 6 of the top 10 computers in the world. It is resold by HP, SUN, Dell and many other OEM and storage companies, yet produced by a small powerful technology company, Cluster File Systems, Inc. This lecture will explain the Lustre architecture and then focus on how scalability was achieved. We will address many aspects of scalability mostly from the field and some from future requirements, from having 25,000 clients in the Red Storm computer to offering exabytes of storage. Performance is an important focus and we will discuss how Lustre serves up over 100GB/sec today going to 100TB/sec in the coming years. It will deliver millions of metadata operations per second in a cluster and, write 10′s of thousands of small files per second on a single node.

Scalable Test Selection Using Source Code

• Video Lecture on Scalable Test Selections

As the number of automated regression tests increase, the ability to run all of them in a reasonable amount of time becomes more and more difficult, and simply doesn’t scale. Since we are looking for regressions, it is useful to hone in on the parts of the code that have changed from the last run to help select a small subset of tests that are likely to find the regression. In this way we are only running the tests that need to be run as your system gets larger and the number of possible tests scales outward. We have devised a method to select a subset of tests from an existing test set for scalable regression testing based on source code changes, or deltas. The selection algorithm is a static data mining technique that establishes the relationship between source code deltas and test case execution results. Test selection is then based on the established correlation. In this talk, we will discuss the benefits and also the pitfalls involved in having such an infrastructure. Finally, we will talk about how best to add it to a nightly or continuous test automation infrastructure. Ryan Gerard is currently an SQA Engineer at Symantec. He has a BS in Computer Science and Engineering from UCLA, and is currently pursuing his MS in Information Security. Ryan’s particular specialties are in web technologies and security testing, although his interests span kernel-level technologies to process improvements to data analysis.

SCTPs Reliability and Fault Tolerance

• Video Lecture on SCTP Realiability

Low cost clusters are usually built from commodity parts and use standard transport protocols like TCP/IP. Once systems become large enough, reliability and fault tolerance become an important issue and TCP/IP often requires additional mechanisms to ensure reliability of the application. The Stream Control Transmission Protocol (SCTP) is a newly standardized transport protocol that provides additional mechanisms for reliability beyond that of TCP. The added reliability and fault tolerance of SCTP may function better for MapReduce-like distributed applications on large commodity clusters. SCTP has the following features that provide additional levels of reliability and fault tolerance. Selective acknowledgment (SACK) is built-in to the protocol with the ability to express larger gaps than TCP; as a result, SCTP outperforms TCP under loss. For cluster nodes with multiple interfaces, SCTP supports multihoming, which transparently provides failover in the event of network path failure. SCTP has the stronger CRC32c checksum which is necessary with high data rates and large scale systems. SCTP also allows multiple streams within a single connection, providing a solution to the head- of-line blocking problem present in TCP-based farming applications like Google’s MapReduce. Like TCP, SCTP provides a reliable data stream by default, but unlike TCP, messages can optionally age or reliability can be disabled altogether. The SCTP API provides both a one-to-one (like TCP) and a one-to-many (like UDP) socket style; use of a one-to-many style socket can reduce the number of file descriptors required by an application, making it more scalable.

Building a Scalable Resource Management

• Video Lecture on Building Scalable RM

This talk will describe the architecture and implementation details for building a highly scalable resource management layer that can support a variety of applications and workloads. This technology has evolved from large scale computing grids deployed in production at customers such as Texas Instruments, AMD, JP Morgan, and various government labs. We will show how to build a centralized dynamic load information collection service that can handle up to 5000 nodes/20,000 cpus in a single cluster. The service is able to gather a variety of system level metrics and is extensible to collect up to 256 dynamic or static attributes of a node and actively feed them to a centralized master. A built-in election algorithm ensures timely failover of the master service ensuring high-availability without the need for specialized interconnects. This building block is extended to multiple clusters that can be organized hierarchically to support a single resource management domain that can span multiple data centers. We believe the current architecture could scale to 100,000 nodes/400,000 cpus. Additional services such as a distributed process execution service, and a policy-based resource allocation engine which leverage this core scale-out clustering service are described. The protocols, communication overheads, and various design tradeoffs that were made the development of these services will be presented along with experimental results from various tests, simulations and production environments.

VeriSign’s Global DNS Infrastucture

• Video Lecture on VeriSign’s Global DNS Infrastructure

VeriSign’s global network of nameservers for the .com and .net domains sees 500,000 DNS queries per second during its daily peak, and ten times that or more during attacks. By adding new servers and bandwidth, we’ve recently increased capacity to handle many times that query volume. Name and address changes are distributed to these nameservers every 15 seconds — from a provisioning system that routinely receives one million domain updates in an hour. In this presentation we describe VeriSign’s production DNS implementation as a context for discussing our approach to highly scalable, highly reliable architectures. We will talk about the underlying Advanced Transactional Lookup and Signaling software, which is used to handle database extraction, validation, distribution and name resolution. We also will show the central heads-up display that rolls up statistics reported from each component in the infrastructure.

Scaling Google for Every User

• Video Lecture on Scaling Google for Every User

Marissa Mayer, Vice President, Search Products & User Experience, leads the product management efforts on Google’s search products – web search, images, groups, news, Froogle, the Google Toolbar, Google Desktop, Google Labs, and more. She joined Google in 1999 as Google’s first female engineer and led the user interface and webserver teams at that time.

Scalability and Efficiency on Data Mining Applied to Internet Applications

• Video Lecture on Scalable Data Mining

The Internet went well beyond a technology artefact, increasingly becoming a social interaction tool. These interactions are usually complex and hard to analyze automatically, demanding the research and development of novel data mining techniques that handle the individual characteristics of each application scenario. Notice that these data mining techniques, similarly to other machine learning techniques, are intensive in terms of both computation and I/O, motivating the development of new paradigms, programming environments, and parallel algorithms that support scalable and efficient applications. In this talk we present some results that justify not only the need for developing these new techniques, as well as their parallelization.

Customizable Scalable Compute Intensive Stream Queries

• Video Lecture

GSDM is a data stream management system running on cluster computers. The system is extensible through user-defined data representations and computations. The computations are specified as stream queries continuously computed over windows of data sliding over the streams.Our applications include a virtual radio telescope requiring advanced computations over huge streams of data. The system needs to be highly scalable w.r.t. both data and computations. Rather than providing only built-in distribution strategies, the system allows the user to define distribution templates to specify customized distribution strategies for user functions in stream queries. The distribution templates are shown to provide scalability for stream computations that grow more expensive with larger windows.

Distribution templates can be defined in terms of other distribution templates, enabling specification of large distribution patterns of communicating computing nodes. This also allows optimizing templates that generate new templates based on profiling the computations.

Performance Tuning Best Practices for MySQL

• Video Lecture on MySQL Performance Tuning

Learn where to best focus your attention when tuning the performance of your applications and database servers, and how to effectively find the «low hanging fruit» on the tree of bottlenecks. It’s not rocket science, but with a bit of acquired skill and experience, and of course good habits, you too can do this magic! Jay Pipes is MySQL’s Community Relations Manager for North America.

A Googly MySQL Cluster Talk

• Video Lecture on MySQL Clustering

Introduction to MySQL Cluster The NDB storage engine (MySQL Cluster) is a high-availability storage engine for MySQL. It provides synchronous replication between storage nodes and many mysql servers having a consistent view of the database. In 4.1 and 5.0 it’s a main memory database, but in 5.1 non-indexed attributes can be stored on disk. NDB also provides a lot of determinism in system resource usage. I’ll talk a bit about that.New features in 5.1 including cluster to cluster replication, disk based data and a bunch of other things. anybody that is attending the mysql users conference may find this eerily familiar.

MySQL Scaling and High Availability Architectures

• Video Lecture on MySQL HA (High Availability)

Along the way I found some nice blogs on scalability, here is one with various presentations:
Presentations on scaling websites: twitter, Flickr, Bloglines, Vox and more.

And here is one collecting slides, talks, audios and videos on scalability:
Scalable Web Architecture Library

I would consider adding the following resources as well.

The Scalability Revolution: From Dead End to Open Road

New patterns and middleware architecture needed for true linear scalability?

Lessons from Pat Helland: Life Beyond Distributed Transactions

Полезные линки по теме:

1. хорошее описание внутренностей
2. список рассылки 1 http://dir.gmane.org/gmane.comp.web.nginx.russian (читать обязательно)
3. список рассылки 2 http://www.lexa.ru/nginx-ru/
4. Nginx memcached rails
5. Nginx English Wiki

Сайт программки http://0w.ru/httpd/, свеженькая версия 0.7q вышла недавно…

0W-httpd — производительный и «легкий» web-сервер.

Область применения: сайты со статическим содержимым («картиночные» сервера, файловые архивы), узкоспециализированные сервера (баннерные, счетчиковые системы), акселератор для высоко-загруженных серверов общего назначения. Фактически производительность ограничена возможностями сетевой карты и жесткого диска.

Основные преимущества и возможности:

• низкая требовательность к ресурсам (память и CPU)
• быстрая реакция на запросы (до нескольких тысяч запросов в секунду)
• поддержка большого количества одновременных соединений (до нескольких тысяч)
• возможность работы в качестве акселератора для более универсальных серверов (Apache)
• поддержка средств повышения производительности протокола http: keep-alive запросы, pipelined-запросы, «докачка»
• использование эффективных механизмов Linux (RealTime signals, sendfile) и FreeBSD (kqueue, sendfile), для других ОС: poll, mmap, read/write.

ОС: Linux, FreeBSD
Текущая версия: 0.7q (описание файла конфигурации)
Список изменений (1 ноября 2007)

Library

This is a collection of Slides, presentations and videos on topics related to designing of high throughput, scalable, highly available websites I’ve been collecting for a while.