Технологии социальных сетей

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

Фильм "Социальная сеть" хорошо иллюстрирует феномен развития Facebook’а, сумевшего за рекордный срок собрать баснословную, немыслимую ранее аудиторию.
Однако за кадром осталась еще одна составляющая проекта — то, как он работает изнутри. Его техническое устройство.

Что такое Facebook сейчас? Лучше всего это демонстрируют сухие цифры:

• 500 000 000 активных пользователей (месячная аудитория);
• 200 000 000 000 просмотров страниц в месяц;
• 150 000 000 обращений к кэшу в секунду;
• 2 000 000 000 000 объектов в кэше;
• 20 000 000 000 фотографий в 4-х разрешениях. Их хватило бы, чтобы
  покрыть поверхность земли в 10 слоев — это больше, чем на всех других
  фоторесурсах вместе взятых;
• более 1 000 000 000 сообщений в чате каждый день;
• более 100 000 000 поисковых запросов ежедневно;
• более 400 000 разработчиков сторонних приложений;
• около 500 разработчиков и системных администраторов в штате;
• более 1 000 000 активных пользователей на одного инженера;
• десятки тысяч серверов, десятки гигабит трафика.

Как же все это работает?

Масштабируемость, простота, открытость

Можно по-разному относиться к социальным сетям вообще и к Facebook’у в частности, но с точки зрения технологичности это один из самых интересныхпроектов. Особенно приятно, что разработчики никогда не отказывались делиться опытом создания ресурса, выдерживающего подобные нагрузки. В этом есть большаяпрак тическая польза. Ведь в основе системы лежат общедоступные компоненты, которые можешь использовать ты, могу использовать я — они доступны каждому. Более того, многие из тех технологий, которые разрабатывались внутри Facebook’а, сейчас опубликованы с открытыми исходниками. И использовать их, опять же, может любой желающий. Разработчики социальной сети по возможности использовали лишь открытые технологии и философию Unix: каждый компонент системы должен быть максимально простым и производительным, при этом решение задач достигается путемих комбинирования. Все усилия инженеров направлены на масштабируемость, минимизацию количества точек отказа и, что самое важное, простоту. Чтобы не быть голословным, укажу основные технологии, которые сейчас используются внутри
Facebook:

• Операционная система — Linux;
• основной язык программирования — PHP + надстройка;
• агрессивное кэширование объектов — memcached;
• хранилище данных в виде пар "ключ-значение" — MySQL;
• универсальная система сбора и агрегации данных с рабочих серверов —
  Scribe.

Балансировщик нагрузки выбирает php-сервер для обработки каждого запроса, где HTML генерируется на основе различных источников (таких как MySQL, memcached) и специализированных сервисов. Таким образом, архитектура Facebook имеет традиционный трехуровневый вид:

• веб-приложение;
• распределенный индекс;
• постоянное хранилище.

Полагаю, что наиболее интересно будет услышать, как в проекте удалось использовать самые привычные технологии. И тут действительно есть немало
нюансов.

Что обычно происходит за 20 минут на Facebook?

• Люди публикуют 1 000 000 ссылок;
• Отмечают друзей на 1 323 000 фотографий;
• Приглашают 1 484 000 знакомых на мероприятия;
• Отправляют 1 587 000 сообщений на стену;
• Пишут 1 851 000 новых статусов;
• 2 000 000 пар людей становятся друзьями;
• Загружается 2 700 000 фотографий;
• Появляется 10 200 000 комментариев;
• Отправляется 4 632 000 личных сообщений.

Facebook Проект на PHP

Напрашивается вопрос: почему именно PHP? Во многом – просто "исторически сложилось". Он хорошо подходит для веб-разработки, легок в изучении и работе, для программистов доступен огромный ассортимент библиотек. К тому же существует огромное международное сообщество. Из негативных сторон можно назвать высокий расход оперативной памяти и вычислительных ресурсов. Когда объем кода стал слишком велик, к этому списку добавились слабая типизация, линейный ростизде ржек при подключении дополнительных файлов, ограниченные возможности для статичного анализа и оптимизации. Все это стало создавать большие трудности. По этой причине в Facebook была реализована масса доработок к PHP, в том числе оптимизация байт-кода, улучшения в APC (ленивая загрузка, оптимизация блокировок, "подогрев" кэша) и ряд собственных расширений (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной
обработки событий).

Схема формирования новостной ленты

Особого внимания заслуживает проект HipHop – это трансформатор исходного кода из PHP в оптимизированный C++. Принцип простой: разработчики пишут на PHP, который конвертируется в оптимизированный C++. В надстройке реализованы статический анализ кода, определение типов данных, генерация кода и многое другое. Также HipHop облегчает разработку расширений, существенно сокращает расходы оперативной памяти и вычислительных ресурсов. У команды из трех программистов ушло полтора года на разработку этой технологии, в частности была переписана большая часть интерпретатора и многие расширения языка PHP. Сейчас
коды HipHop опубликованы под opensource лицензией, пользуйся на здоровье.

Культура разработки Facebook

• Двигаться быстро и не бояться ломать некоторые вещи;
• большое влияние маленьких команд;
• быть откровенным и инновационным;
• возвращать инновации в opensource сообщество.

Доработки MySQL

Теперь о базе данных. В отличие от подавляющего большинства сайтов, MySQL в Facebook используется как простое хранилище пар "ключ-значение". Большое количество логических баз данных распределено по физическим серверам, но репликация используется только между датацентрами. Балансировка нагрузки осуществляется перераспределением баз данных по машинам. Так как данные распределены практически случайным образом, никакие операции типа JOIN, объединяющие данные из нескольких таблиц, в коде не используются. В этом есть смысл. Ведь наращивать вычислительные мощности намного проще на веб-серверах,
чем на серверах баз данных.

В Facebook используется практически не модифицированный исходный код MySQL, но с собственными схемами партиционирования по глобально-уникальным идентификаторам и архивирования, основанного на частоте доступа к данным. Принцип очень эффективен, поскольку большинство запросов касаются самой свежей информации. Доступ к новым данным максимально оптимизирован, а старые записи автоматически архивируются. Помимо этого используются свои библиотеки для доступа к данным на основе графа, где объекты (вершины графа) могут иметь лишь ограниченный набор типов данных (целое число, строка ограниченной длины, текст),
а связи (ребра графа) автоматически реплицируются, образуя аналог распределенных внешних ключей.

Использование Memcached

Как известно, memcached — высокопроизводительная распределенная хэш-таблица. Facebook хранит в ней "горячие" данные из MySQL, что существенно снижает нагрузку на уровне баз данных. Используется более 25 Тб (только вдумайся в цифру) оперативной памяти на нескольких тысячах серверов при среднем времени отклика менее 250 мкс. Кэшируются сериализованные структуры данных PHP, причем из-за отсутствия автоматического механизма проверки консистенции данных между memcach d и MySQL приходится делать это на уровне программного кода. Основным способом использования memcache является множество multi-get запросов,используемых для получения данных на другом конце ребер графа.

Facebook очень активно занимаются доработкой проекта по вопросам производительности. Большинство из описанных ниже доработок были включены в opensource версию memcached: порт на 64-битную архитектуру, сериализация, многопоточность, компрессия, доступ к memcache через UDP (уменьшает расход памяти благодаря отсутствию тысяч буферов TCP-соединений). В дополнение были внесены некоторые изменения в ядро Linux для оптимизации работы memcache. Насколько это действенно? После вышеперечисленных модификаций memcached способен выполнять до 250 000 операций в секунду по сравнению со стандартными 30 000 — 40
000 в оригинальной версии.

Фреймворк Thrift

Еще одной инновационной разработкой Facebook является проект Thrift. По сути, это механизм построения приложений с использованием нескольких языковпрограммирования. Основная цель — предоставить технологию прозрачного взаимодействия между разными технологиями программирования. Thrift предлагает разработчикам специальный язык описания интерфейсов, статический генератор кода, а также поддерживает множество языков, в том числе C++, PHP, Python, Java, Ruby, Erlang, Perl, Haskell. Возможен выбор транспорта (сокеты, файлы, буферы в памяти) и стандарта сериализации (бинарный, JSON). Поддерживаются различные типы серверов: неблокирующие, асинхронные, как однопоточные, так и многопоточные. Альтернативными технологиями являются SOAP, CORBA, COM, Pillar, Protocol Buffers, но у всех есть свои существенные недостатки, и это вынудило Facebook разработать свою собственную. Важное преимущество Thrift’а заключается в производительности. Он очень и очень быстрый, но даже это не главный его плюс. С появлением Thrift на разработку сетевых интерфейсов и протоколов уходит куда меньше времени. В Facebook технология входит в общий инструментарий, который знаком любому программисту. В частности, благодаря этому, удалось ввести четкое разделение труда: работа над высокопроизводительными серверами теперь ведется отдельно от работы над приложениями. Thrift, как и многие другие разработки Facebook, сейчас
находится в открытом доступе.

Возвращение инноваций

Возвращение инноваций общественности — важный аспект разработки в
Facebook. Компанией были опубликованы свои проекты:
Thrift,
Scribe,
Tornado,
Cassandra,
Varnish,
Hive,
xhprof.
Помимо этого были сделаны доработки для PHP, MySQL, memcached.

Информация о взаимодействии Facebook с opensource-сообществом этих и
других проектов расположена на

странице, посвященной opensource.

Хранение фотографий

Закончив на этом рассказывать об используемых технологиях, хочу привести подробности решения интересной задачки внутри социальной сети, а именно — организации хранения фотографий. Многих фотографий. Громадного количества фотографий. Это довольно интересная история. Сначала фотоальбомы пользователей были организованы по самому тривиальному сценарию:

• при загрузке на сервер приложение принимает изображение, создает
  миниатюры в нужных разрешениях, сохраняет в NFS;
• при загрузке с сервера изображения отдаются напрямую из NFS через HTTP.

Такой простой подход был необходим, чтобы сначала проверить, что продукт востребован пользователями, и они действительно будут активно загружать фотографии. Новая фича, как известно, "поперла". Но на практике оказалось, что файловые системы непригодны для работы с большим количеством небольших файлов. Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме. Ограничивающим фактором является ввод-вывод, а не плотность хранения. Первым шагом по оптимизации стало кэширование. Наиболее часто используемые миниатюры изображений кэшировались в памяти на оригинальных серверах для масштабируемости и производительности, а также распределялись по CDN (географически распределенной сетевой инфраструктуре) для уменьшения сетевых задержек. Это дало результат. Позже оказалось, что можно сделать еще лучше. Изображения стали хранить в больших бинарных файлах (blob), предоставляя приложению информацию о том, в каком файле и с каким отступом (по сути, идентификатором) от начала расположена каждая фотография. Такой сервис в Facebook получил название Haystack и оказался в десять раз эффективнее "простого" подхода и в три раза эффективнее "оптимизированного". Как говорится, все гениальное просто!

Принцип работы поиска в Facebook

Google изнутри

Каждый хоть раз слышал о Google благодаря их всеобъемлющему, «умному» и быстрому поисковому сервису, но ни для кого не секрет, что они не ограничиваются только им. Их платформа для построения масштабируемых приложений позволяет выпускать множество удивительно конкурентноспособных интернет-приложений, работающих на уровне всего Интернета вцелом. Они ставят перед собой цель постоянно строить все более и более производительную и масштабируемую архитектуру для поддержки своих продуктов. Как же им это удается?

Google File System (GFS)— собственная файловая система, рассчитаная на работу в условиях, когда аппаратные и сетевые сбои являются нормой, а не чрезвычайной ситуацией. То есть они отказались от стандартных NFS и AFS.

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

Сразу хочу сказать, что эта запись является переводом с английского, автороригинальной версии — 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 — большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации
• Зачем строить что-либо самим вместо того, чтобы просто взять это с полки? Они контролируют абсолютно всю систему и именно эта платформа отличает их от всех остальных. Она предоставляет:

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

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

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

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

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

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

  – Мастер-сервера хранят метаданные для всех файлов. Об этом говорит сайт https://intellect.icu . Сами данные хранятся блоками по 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, предшествовало искусство, а не только крупномасштабное развертывание системы.
• Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.

Архитектура Google была одной из первых статьей на Insight IT. Именно она дала толчок развитию проекта: после ее публикации посещаемость блога увеличилась в десятки раз и появились первые сотни подписчиков. Прошли годы, информация устаревает стремительно, так что пришло время взглянуть на Google еще раз, теперь уже с позиции конца 2011 года. Что мы увидим нового в архитектуре интернет-гиганта?

Статистика

рис гиперинформационнная эпока вызванная развитием социальных сетей

• Общее
  • Ежедневная аудитория Google составляет около 1 миллиарда человек
    • По данным Alexa больше половины аудитории интернета каждый день пользуются Google
    • По данным IWS аудитория интернета составляет 2.1 миллиарда человек
  • Используется более 900 тысяч серверов
    • Планируется расширение до 10 миллионов серверов в обозримом будущем
  • 12 основных датацентров в США, присутствие в большом количестве точек по всему миру (более 38)
  • Около 32 тысяч сотрудников в 76 офисах по всему миру
• Поиск
  • За последние 14 лет среднее время обработки одного поискового запроса уменьшилось с 3 секунд до менее 100 миллисекунд, то есть в 30 раз
  • Более 40 миллиардов страниц в индексе, если приравнять каждую к листу А4 они бы покрыли территорию США в 5 слоев
  • Более 1 квинтиллиона уникальных URL (10 в 18 степени); если распечатать их в одну строку, ее длина составит 51 миллион километров, треть расстояния от Земли до Солнца
  • В интернете встречается примерно 100 квинтиллионов слов, чтобы набрать их на клавиатуре одному человеку потребовалось бы примерно 5 миллионов лет
  • Проиндексировано более 1.5 миллиардов изображений, чтобы их сохранить потребовалось бы 112 миллионов дискет, которые можно сложить в стопку высотой 391 километр
• Gmail
  • Активных пользователей более 170 миллионов
  • Второй по популярности почтовый сервис в США, третий в мире (по данным comScore)
  • При текущем темпе роста аудитории GMail и конкурентов, он станет лидером рынка через 2-3 года
• Google+
  • Более 40 миллионов пользователей на октябрь 2011, при запуске в июне 2011
  • 25 миллионов пользователей за первый месяц
  • 70:30 примерное соотношение мужчин и женщин
  • Себестоимость разработки больше полумиллиарда долларов
• YouTube
  • Загружается более 13 миллионов часов видео в год
  • Каждую минуту загружается 48 часов видео, что соответствует почти 8 годам контента или 52 тысячам полнометражных фильмов в день
  • Более 700 миллиардов просмотров видео в год
  • Месячная аудитория составляет 800 миллионов уникальных посетителей
  • Несколько тысяч полнометражных фильмов в YouTube Movies
  • Более 10% всех видео в формате HD
  • 13% просмотров (400 миллионов в день) происходит с мобильных устройств
  • До сих пор работает в убыток, лишь 14% просмотров видео приносят выручку с рекламы
• Финансы
  • Выручка порядка 36 миллиардов долларов в год
  • Прибыль после налогов порядка 10 миллиардов долларов в год
  • Капитализация порядка 200 миллиардов долларов

Архитектура соц сетей

Google — огромная интернет-компания, неоспоримый лидер на рынке поиска в Интернет и владелец большого количества продуктов, многие из которых также добились определенного успеха в своей нише.

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

Все продукты Google основываются на постоянно развивающейся программной платформе, которая спроектирована с учетом работы на миллионах серверов, находящихся в разных датацентрах по всему миру.

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

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

В традиционных датацентрах потребление электричества серверами примерно равно его потреблению остальной инфраструктурой, Google же удалось снизить процент использования дополнительной электроэнергии до 14%. Таким образом суммарное энергопотребление датацентром Google сравнимо с потреблением только серверов в типичном датацентре и вдвое меньше его общего энергопотребления. Основные концепции, которые используются для достижения этого результата:

• Точное измерение потребления электроэнергии всеми компонентами позволяет определить возможности по его уменьшению;
• В датацентрах Google тепло, что позволяет экономить на охлаждении;
• При проектировании датацентра уделяется внимание даже незначительным деталям, позволяющим сэкономить даже немного — при таком масштабе это окупается;
• Google умеет охлаждать датацентры практически без кондиционеров, с использованием воды и ее испарения (см. как это реализовано в Финляндии).

В Google активно пропагандируют максимальное использование возобновляемой энергии. Для этого заключаются долгосрочные соглашения с ее поставщиками (на 20 и более лет), что позволяет отрасли активно развиваться и наращивать мощности. Проекты по генерации возобновляемой энергии, спонсируемые Google, имеют суммарную мощность более 1.7 гигаватт, что существенно больше, чем используется для работы Google. Этой мощности хватило бы для обеспечения электричеством 350 тысяч домов.

Если говорить о жизненном цикле оборудования, то используются следующие принципы:

• Уменьшение транспортировки: там, где это возможно, тяжелые компоненты (вроде серверных стоек) закупаются у местных поставщиков, даже если в других местах аналогичный товар можно было бы купить дешевле.
• Повторное использование: прежде, чем покупать новое оборудование и материалы, рассматриваются возможности по использованию уже имеющихся. Этот принцип помог избежать покупки более 90 тысяч новых серверов.
• Утилизация: в тех случаях, когда повторное использование невозможно, оборудование полностью очищается от данных и продается на вторичном рынке. То, что не удается продать, разбирается на материалы (медь, сталь, алюминий, пластик и.т.п.) для последующей правильной утилизации специализированными компаниями.

Google известны за свои эксперименты и необычные решения в области серверного оборудования и инфраструктуры. Некоторые запатентованы; какие-то прижились, какие-то — нет. Подробно останавливаться на них не буду, лишь вкратце о некоторых:

• Резервное питание, интегрированное в блок питания сервера, обеспеченное стандартными 12V батарейками;
• «Серверный сендвич», где материнские платы с двух сторон окружают водяную систему теплоотвода в центре стойки;
• Датацентр из контейнеров.

В заключении этого раздела хотелось бы взглянуть правде в глаза: идеального оборудования не бывает. У любого современного устройства, будь то сервер, коммутатор или маршрутизатор, есть шанс прийти в негодность из-за производственного брака, случайного стечения обстоятельств или других внешних факторов. Если умножить этот, казалось бы, небольшой шанс на количество оборудования, которое используется в Google, то окажется, что чуть ли не каждую минуту из строя выходит одно, или несколько, устройств в системе. На оборудование полагаться нельзя, по-этому вопрос отказоустойчивости переносится на плечи программной платформы, которую мы сейчас и рассмотрим.

Платформа

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

Основными задачами в ранние годы была минимизация точек отказа и обработка больших объемов слабоструктурированных данных. Решением этих задач стали три основных слоя платформы Google, работающие один поверх другого:

• Google File System: распределенная файловая система, состоящая из сервера с метаданными и теоретически неограниченного количества серверов, хранящих произвольные данные в блоках фиксированного размера.
• BigTable: распределенная база данных, использующая для доступа к данным две произвольных байтовых строки-ключа (обозначающие строку и столбец) и дату/время (обеспечивающие версионность).
• MapReduce: механизм распределенной обработки больших объемов данных, оперирующий парами ключ-значение для получения требуемой информации.

Такая комбинация, дополненная другими технологиями, довольно долгое время позволяла справляться с индексацией Интернета, пока… скорость появления информации в Интернете не начала расти огромными темпами из-за «бума социальных сетей». Информация, добавленная в индекс даже через полчаса, уже зачастую становилась устаревшей. В дополнение к этому в рамках самого Google стало появляться все больше продуктов, предназначенных для работы в реальном времени.

Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы Google, потребовали фундаментальной смены архитектуры индексации и поиска, который около года назад был представлен публике под кодовым названием Google Caffeine. Новые, переработанные, версии старых «слоев» также окрестили броскими именами, но резонанса у технической публики они вызвали намного меньше, чем новый поисковый алгоритм в SEO-индустрии.

Google Colossus

Новая архитектура GFS была спроектирована для минимизации задержек при доступе к данным (что критично для приложений вроде GMail и YouTube), не в ущерб основным свойствам старой версии: отказоустойчивости и прозрачной масштабируемости.

В оригинальной же реализации упор был сделан на повышение общей пропускной способности: операции объединялись в очереди и выполнялись разом, при таком подходе можно было прождать пару секунд еще до того, как первая операция в очереди начнет выполняться. Помимо этого в старой версии было большое слабое место в виде единственно мастер-сервера с метаданными, сбой в котором грозил недоступностью всей файловой системы в течении небольшого промежутка времени (пока другой сервер не подхватит его функции, изначально это занимало около 5 минут, в последних версиях порядка 10 секунд) — это также было вполне допустимо при отсутствии требования работы в реальном времени, но для приложений, напрямую взаимодействующих с пользователями, это было неприемлемо с точки зрения возможных задержек.

Основным нововведением в Colossus стали распределенные мастер-сервера, что позволило избавиться не только от единственной точки отказа, но и существенно уменьшить размер одного блока с данными (с 64 до 1 мегабайта), что в целом очень положительно сказалось на работе с небольшими объемами данных. В качестве бонуса исчез теоретический предел количества файлов в одной системе.

Детали распределения ответственности между мастер-серверами, сценариев реакции на сбои, а также сравнение по задержкам и пропускной способности обоих версий, к сожалению, по-прежнему конфиденциальны. Могу предположить, что используется вариация на тему хэш-кольца с репликацией метаданных на ~3 мастер-серверах, с созданием дополнительной копии на следующем по кругу сервере в случае в случае сбоев, но это лишь догадки. Если у кого-то есть относительно официальная информация на этот счет — буду рад увидеть в комментариях.

По прогнозам Google текущий вариант реализации распределенной файловой системы «уйдет на пенсию» в 2014 году из-за популяризации твердотельных накопителей и существенного скачка в области вычислительных технологий (процессоров).

Google Percolator

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

Ключевые архитектурные решения, лежащие в основе MapReduce, не позволяли повлиять на эту особенность и в итоге система индексации была построена заново с нуля, а MapReduce продолжает использоваться в других проектах Google для аналитики и прочих задач, по прежнему не связанных с реальным временем.

Новая система получила довольно своеобразное название Percolator, попытки узнать что оно значит приводит к различным устройствам по фильтрации дыма, кофеваркам и непойми чему еще. Но наиболее адекватное объяснение мне пришло в голову, когда я прочитал его по слогам: per col — по колонкам.

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

Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения в остальной базе осуществляются посредством механизма »обозревателей». Если говорить в терминах реляционных СУБД, то обозреватели — что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (наC++), который исполняется в случае возникновении изменений в определенных колонкахBigTable (откуда, видимо, и пошло название). Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore.

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

В качестве бонуса в этой схеме удалось избежать еще двух недостатков MapReduce:

• Проблемы «отстающих»: когда один из серверов (или одна из конкретных подзадач) оказывался существенно медленнее остальных, что также значительно задерживало общее время завершения работы кластера.
• Пиковая нагрузка: MapReduce не является непрерывным процессом, а разделяется на работы с ограниченной целью и временем исполнения. Таким образом помимо необходимости ручной настройки работ и их типов, кластер имеет очевидные периоды простоя и пиковой нагрузки, что ведет к неэффективному использованию вычислительных ресурсов.

Но все это оказалось не бесплатно: при переходе на новую систему удалось достичь той же скорости индексации, но при этом использовалось вдвое больше вычислительных ресурсов. Производительность Percolator находится где-то между производительностью MapReduce и производительностью традиционных СУБД. Так как Percolator является распределенной системой, для обработки фиксированного небольшого количества данных ей приходится использовать существенно больше ресурсов, чем традиционной СУБД; такова цена масштабируемости. По сравнению с MapReduce также пришлось платить дополнительными потребляемыми вычислительными ресурсами за возможность случайного доступа с низкой задержкой.

Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте TPC-E). Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.

Google Spanner

Spanner представляет собой единую систему автоматического управления ресурсамивсего парка серверов Google.

Основные особенности:

• Единое пространство имен:
  • Иерархия каталогов
  • Независимость от физического расположения данных
• Поддержка слабой и сильной целостности данных между датацентрами
• Автоматизация:
  • Перемещение и добавление реплик данных
  • Выполнение вычислений с учетом ограничений и способов использования
  • Выделение ресурсов на всех доступных серверах
• Зоны полу-автономного управления
• Восстановление целостности после потерь соединения между датацентрами
• Возможность указания пользователями высокоуровневых требований, например:
  • 99% задержек при доступе к этим данным должны быть до 50 мс
  • Расположи эти данные на как минимум 2 жестких дисках в Европе, 2 в США и 1 в Азии
• Интеграция не только с серверами, но и с сетевым оборудованием, а также системами охлаждения в датацентрах

Проектировалась из расчета на:

• 1-10 миллионов серверов
• ~10 триллионов директорий
• ~1000 петабайт данных
• 100-1000 датацентров по всему миру
• ~1 миллиард клиентских машин

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

Прочие компоненты платформы

Платформа Google в конечном итоге сводится к набору сетевых сервисов и библиотек для доступа к ним из различных языков программирования (в основном используются C/C++, Java, Python и Perl). Каждый продукт, разрабатываемый Google, в большинстве случаев использует эти библиотеки для осуществления доступа к данным, выполнения комплексных вычислений и других задач, вместо стандартных механизмов, предоставляемых операционной системой, языком программирования или opensource библиотеками.

Вышеизложенные проекты составляют лишь основу платформы Google, хотя она включает в себя куда больше готовых решений и библиотек, несколько примеров из публично доступных проектов:

• GWT для реализации пользовательских интерфейсов на Java;
• Closure — набор инструментов для работы с JavaScript;
• Protocol Buffers — не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;
• LevelDB — высокопроизводительная встраиваемая СУБД;
• Snappy — быстрая компрессия данных, используется при хранении данных в GFS.

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

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

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

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

Поправки и уточнения приветствуются

• Official Google Data Centers Site
• Challenges in Building Large-Scale Information Retrieval Systems (Jeff Dean, WCDMA '09)
• Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean, Ladis '09)
• Google Percolator official paper
• Google Megastore official paper
• Google Percolator
• Google Caffeine Explained
• Google Spanner
• Google Software Infrastructure Dubbed Obsolete by ex-Employee
• Google Moves Off the Google File System
• Google Internet Stats
• Google Statistics
• Google Plus — Killer Facts and Statistics
• YouTube statistics
• Alexa on Google
• Internet World Stats
• Google Inc. financials
• Hotmail still on top worldwide; Gmail gets bigger
• Google Server Count
• Google Envisions 10 Million Servers
• Google Data Center FAQ

Бонус: типичный первый год кластера в Google

• ~½ перегрева (большинство серверов выключаются в течении 5 минут, 1-2 дня на восстановление)
• ~1 отказ распределителя питания (~500-1000 резко пропадают, ~6 часов на восстановление)
• ~1 передвижение стойки (много передвижений, 500-100 машин, 6 часов)
• ~1 перепрокладка сети (последовательной отключение ~5% серверов на протяжении 2 дней)
• ~20 отказов стоек (40-80 машин мгновенно исчезают, 1-6 часов на восстановление)
• ~5 стоек становится нестабильными (40-80 машин сталкиваются с 50% потерей пакетов)
• ~8 запланированных технических работ с сетью (при четырех могут случаться случайные получасовые потери соединения)
• ~12 перезагрузок маршрутизаторов (потеря DNS и внешних виртуальных IP на несколько минут)
• ~3 сбоя маршрутизаторов (восстановление в течении часа)
• Десятки небольших 30-секундных пропаданий DNS
• ~1000 сбоев конкретных серверов (~3 в день)
• Много тысяч сбоев жестких дисков, проблем с памятью, ошибок конфигурации и т.п.

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

Не секрет, что стек LAMP эффективен и пригоден для создания самых сложных систем, но при этом далеко не идеален. Конечно, PHP+MySQL+Memcache решают большинство задач, но далеко не все. Каждый крупный проект сталкивается с тем, что:

• PHP не может хранить состояния;
• PHP не самый производительный язык;
• все данные находятся удаленно.

Facebook’у (да и любым другим крупным проектам) приходится разрабатывать собственные внутренние сервисы, чтобы компенсировать недостатки основных технологий, перенести исполняемый код ближе к данным, сделать ресурсоемкие части кода более эффективными, реализовать преимущества, которые доступны только в определенных языках программирования. Молниеносная обработка запросов от чудовищного количества пользователей достигается за счет комплексного подхода к распределению запросов по тысячам серверов и непрерывной работе над устранением узких мест в системе. В компании есть много небольших команд с полномочиями принимать важные решения, что в совокупности с короткими циклами разработки позволяет очень быстро двигаться вперед и оперативно решать все проблемы.
Результат проверить несложно. Открой facebook.com.

Дополнительный инструментарий

Для управления такой огромной системой в Facebook’е были созданы различные дополнительные сервисы. Всего их более пятидесяти, приведу несколько примеров:

• SMC (консоль управления сервисами) — централизованная конфигурация,
  определение, на какой физической машине работает логический сервис;
• ODS — инструмент для визуализации изменений любых статистических
  данных, имеющихся в системе — удобен для мониторинга и оповещений;
• Gatekeeper — разделение процессов развертывания и запуска, A/B-тестирования
  (метод, позволяющий определить, какая версия страницы лучше уговаривает
  посетителей совершить то или иное действие).

Вау!! 😲 Ты еще не читал? Это зря!

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

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