Ресурс 12Ресурс 33Ресурс 37Ресурс 26Ресурс 31Ресурс 7Ресурс 17Ресурс 9Ресурс 45Ресурс 48Ресурс 10Ресурс 52Ресурс 53Ресурс 51Ресурс 19Ресурс 8Ресурс 39Ресурс 27Ресурс 38Ресурс 18Ресурс 28Ресурс 44Ресурс 32Ресурс 46Ресурс 34

   Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?

   Платформа:

   . Apache

   . Python

   . Linux (SuSe)

   . MySQL

   . psyco, динамический компилятор Python ? C lighttpd для видео

 

   Статистика
 
   Поддержка обработки более 100 миллионов видеороликов в сутки
 
   Сервис был запущен в феврале 2005 года
 
   В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
 
   К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
 

   Над проектом работают: 
 
   2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных
 
   Рецепт управления огромными темпами роста
 
while (true)
{
   identify_and_fix_bottlenecks();
   drink();
   sleep();
   notice_new_bottleneck();
}
 
   Этот цикл проходит далеко не одну итерацию ежедневно.
 
   Базы данных
 
   Раньше: — MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее.?— Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков;?— Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день.?— Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре.
 
   Сейчас:
— Используются распределенные базы данных;
— Сегментированная система (прим.: по аналогии с Flickr);
— Распределенные чтение и запись;
— Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками;
— Такая архитектура привела к 30%-й экономии на оборудовании;
— Задержки в реплицировании сведены к нулю;
— Размеры базы данных могут расти практически неограниченно
 
   Стратегия размещения в датацентрах
 
   Поначалу использовались хостинг-провайдеры, предоставляющие услуги colocation. Подобный подход нельзя было избежать на начальном этапе, несмотря на всю его неэкономичность.
 
   Хостинг-провайдеры не могут поспеть за темпами роста подобного проекта. Поскольку не всегда получается своевременно получить контроль над необходимым оборудованием или сделать необходимые дополнительные соглашения о предоставлению сетевых услуг – данный вариант размещения не подходит.
 
   Решением этой проблемы для YouTube стало создание собственной базы для размещения оборудования. С внедрением этого подхода появилась возможность настраивать абсолютно все необходимое в кратчайшие сроки и подписывать уже собственные контракты такого рода.
 
   Было использовано 5 или 6 разных датацентров в дополнение к CDN. Их параллельное взаимоувязанное использование дало возможность ресурсу прогрессировать.
 
   В настоящее время процесс осуществляется следующим образом: Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным — он перемещается в CDN.
 
   Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи. 
 
   Что касается изображений – для них более актуальны задержки, особенно если на одной странице должно быть размещено около 60 изображений. Репликация изображений производится средствами BigTable. В этом случае используются различные способы для определения ближайшего места, откуда можно получить необходимые данные.