Анализ социальных сетей


АННОТАЦИЯ

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

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

ИСТОРИЯ СОЦИАЛЬНЫХ СЕТЕЙ

Одноклассники - Проект был запущен в марте 2006 года. Создатель сайта, Попков Альберт Михайлович (фото сверху), живущий в Лондоне и работающий в сфере телекоммуникаций, принимал участие в создании подобных проектов в других европейских странах. С марта по ноябрь 2006 проект существовал как хобби и в коммерческом плане упоминался только в дружественном рекламном агентстве как новая площадка для размещения рекламы. Количество пользователей, зарегистрировавшихся на сайте, росло в геометрической прогрессии, поэтому основателем проекта было принято решение о создании отдельного юридического лица.

Вконтакте - С начала лета 2006 года функционировала альфа-версия проекта. С сентября началась стадия бета-тестирования. 1 октября 2006 года на ООО «В Контакте» было зарегистрировано доменное имя vkontakte.ru. Официальным днем основания считается 10 октября 2006 года, когда появились первые функции сайта. 22 ноября на форуме студентов СпбГУ — spbgu.ru, владельцем которого тоже был Павел Дуров ( фото выше ), было объявлено о запуске «закрытого приложения к … форуму». Проект на тот момент являлся закрытым: регистрация по-прежнему была доступна для всех без исключения студентов по приглашениям и при обязательном указании настоящих имени и фамилии.

В конце ноября была открыта свободная регистрация, потребовавшая модернизации серверной части. Одновременно с этим была запущена рекламная кампания по привлечению новых пользователей. Наиболее активным промоутерам вручались призы — продукция Apple: iPod video,iPod nano, iPod shuffle.

ФейсБук - 28 октября 2003 года Марк Цукерберг (фото выше), будучи студентом-второкурсником, написал интернет-сайт Facemash, в которой использовались фотографии, размещенные по парам, с целью выбрать, кто из двух людей более привлекателен.

Чтобы достичь этого, Цукерберг взломал охраняемые разделы компьютерной сети Гарвардского университета и скопировал частные фото. Гарвард в то время не имел студенческого «альбома» (каталог с фотографиями и основной информацией). Facemash привлекла 450 посетителей и 22 000 фото-просмотров в течение первых двух часов работы.

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

В следующем семестре, в январе 2004 года, Цукерберг начал писать код для нового веб-сайта. Он был вдохновлён, по его словам, редакционной статьёй в Harvard Crimson об инциденте Facemash. 4 февраля 2004 года Цукерберг запустил TheFacebook по адресу thefacebook.com. Идея названия Facebook, скорее всего, связана с годами учёбы Марка Цукерберга в старшей школе. В престижной Phillips Exeter Academy, в которой он учился, каждому поступившему выдавался справочник студентов, содержащий фотографии, адреса и телефоны всех одноклассников. Оригинальное название справочника было "The Photo Address Book", но все студенты называли его просто "The Facebook".

Через шесть дней после запуска сайта три гарвардских старшекурсника — Камерон Уинклвосс, Тайлер Уинклвосс и Дивья Нарендра — обвинили Цукерберга в том, что он преднамеренно вводил их в заблуждение, будто поможет им создать социальную сеть HarvardConnection.com, но вместо этого Марк, используя их идеи, построил конкурирующий продукт. Они пожаловались в университетскую газету Harvard Crimson, и она начала расследование. Впоследствии был подан иск в суд против Цукерберга.

Членство в социальной сети изначально было ограничено студентами Гарвардского колледжа, и в течение первого месяца в ней было зарегистрировано более половины студентов Гарварда. Вскоре к Цукербергу присоединились Эдуардо Саверин (финансовый директор),Дастин Московиц (программист), Эндрю Мак-Коллум (художник) и Крис Хьюз, чтобы помочь в продвижении сайта. В марте 2004 года Facebook был расширен до Стэнфорда, Колумбийского университета и Йеля. Позже он открылся других университетах Лиги Плюща, Бостонском университете, Нью-Йоркском университете, Массачусетском технологическом институте, а затем и в большинстве университетов Канады иСША.

В июне 2004 года компания The Facebook переехала в Пало-Альто(Калифорния) В том же месяце она получила свои первые инвестиции от сооснователя системы PayPal Питера Тила. Компания убрала из своего названия артикль The после покупки доменного имени facebook.com в 2005 году за $ 200 000.

С 26 сентября 2006 года доступ в сеть стал открыт для каждого пользователя интернета старше 13 лет, имеющего адрес электронной почты.

24 октября 2007 года Microsoft объявила о приобретении 1,6% акций Facebook за 240 млн $, тем самым оценив всю компанию в 15 миллиардов долларов. Microsoft получила права размещать международные объявления на Facebook. В октябре2008 года Facebook объявила об открытии своей международной штаб-квартиры в Дублине. В сентябре2009 года впервые было объявлено о получении прибыли. В ноябре 2010 года, на основе данных SecondMarket Inc, стоимость компании составила 41 млрд $ (что немного выше, чем у eBay). Таким образом, Facebook стала третьей по величине интернет-компанией в США (после Google и Amazon). 2-го января 2011 года, по данным газеты The New York Times, стоимость Facebook достигла 50 миллиардов долларов США. Согласно этим же данным, к 2012 году планируется проведение IPO компании.

Трафик Facebook устойчиво рос после 2009 года. 13 марта 2010 года Facebook посетили больше людей, чем Google. Facebook также стал лучшей социальной сетью в восьми отдельных рынках в Филиппинах, Австралии, Индонезии, Малайзии, Сингапуре, Новой Зеландии, Гонконге и Вьетнаме, в то время как другие бренды держали лидирующие позиции лишь на отдельных рынках, в их числе принадлежащий Google Orkut в Индии,Mixi.j в Японии, CyWorld в Южной Корее, и продукт Yahoo! Wretch.cc на Тайване.

АРХИТЕКТУРА СОЦИАЛЬНЫХ СЕТЕЙ

Одноклассники - Код проекта в целом написан на Java, но есть исключения в виде модулей для кэширования на C и C++.
Java был выбран так как он является удобным языком для разработки, доступно множество наработок в различных сферах, библиотек и opensource проектов. Архитектура проекта имеет традиционную многоуровневую структуру:

• презентационный уровень - Используем собственный фреймворк, позволяющий строить композицию страниц на языке Jаvа, с использованием собственные GUI фабрик (для оформления текста, списков, таблиц и портлетов). Страницы состоят из независимых блоков (обычно портлетов), что позволяет обновлять информацию на них частями с помощью AJAX запросов. При данном подходе одновременно обеспечивается минимум перезагрузок страниц для пользователей с включенным JavaScript, так и полная работоспособность сайта для пользователей, у которых он отключен. Google Web Toolkit используется для реальзации функциональные компонент, таких как Сообщения, Обсуждения и Оповещения, а также все динамических элементов (меню шорткатов, метки на фотографиях, сортировка фотографий, ротация подарков и.т.д.). В GWT используются UIBinder и HTMLPanel для создания интерфейсов. Кешируются все внешние ресурсы (Expires и Cache-Control заголовки). CSS и JavaScript файлы минимизируются и сжимаются (gzip). Для уменьшения количества HTTP запросов с браузера, все JavaScript и CSS файлы объединяются в один. Маленькие графические изображения объединяются в спрайты. При загрузке страницы скачиваются только те ресурсы, которые на самом деле необходимы для начала работы. Никаких универсальных CSS селекторов. Стараются не использовать типовые селекторы (по имени тэга), что повышает скорость отрисовки страниц внутри браузера. Если необходимы CSS expressions, то пишутся «одноразовые». По возможности избегаются фильтры. Кешируется обращения к DOM дереву, а так же свойства элементов, приводящие к reflow. Обновляется DOM дерево в «оффлайне».

• уровень бизнес-логики - На уровне бизнес логики располагаются около 25 типов серверов и компонентов, общающихся между собой через удаленные интерфейсы. Каждую секунду происходит около 3 миллионов удаленных запросов между этими модулями.
  Сервера на уровне бизнес логики разбиты на группы. Каждая группа обрабатывает различные события. Есть механизм маршрутизации событий, то есть любое событие или группу событий можно выделить и направить на обработку на определенную группу серверов. При общении серверов между собой используется свое решение, основанное на JBoss Remoting.
• уровень кэширования - Для кэширования данных используется самописный модуль odnoklassniki-cache. Он предоставляет возможность хранения данных в памяти средствами Java Unsafe. Кэшируются все данные, к которым происходит частое обращение, например: профили пользователей, списки участников сообществ, информация о самих сообществах, граф связей пользователей и групп, праздники, мета информация о фотографиях и многое другое.Для хранения больших объемов данных в памяти используется память Java off heap memory для снятия ненужной нагрузки с сборщика мусора. Кеши могут использовать локальный диск для хранения данных, что превращает их в высокопроизводительный сервер БД. Кеш сервера, кроме обычных операций ключ-значение, могут выполнять запросы по данным, хранящимся в памяти, минимизируют таким образом передачу данных по сети. Используется map-reduce для выполнения запросов и операций на кластере. В особо сложных случаях, например для реализации запросов по социальному графу, используется язык C. Это помогает повысить производительность. Данные распределяются между кластерами кеш серверов, а также используется репликация партиций для обеспечения надежности. Иногда требования к быстродействию настолько велики, что используются локальные короткоживущие кеши данных полученных с кеш серверов, расположенные непосредственно в памяти серверов бизнес логики. Для примера, один сервер, кэширующий граф связей пользователей, в час пик может обработать около 16 600 запросов в секунду. Процессоры при этом заняты до 7%, максимальный load average за 5 минут — 1.2. Количество вершин графа — более 85 миллионов, связей 2.5 миллиарда. В памяти граф занимает 30 GB.
• уровень баз данных - Суммарный объем данных без резервирования составляет 160Тб. Используются два решения для хранения данных: MS SQL и BerkeleyDB. Данные хранятся в нескольких копиях, в зависимости от их типа от двух до четырех. Полное резервное копирование всех данных осуществляется раз в сутки, плюс каждые 15 минут делаются резервные копии новых данных. В результате максимально возможная потеря данных составляет 15 минут. Сервера с MS SQL объединены в failover кластера, при выходе из строя одного из серверов, находящийся в режиме ожидания сервер берет на себя его функции. Общение с MS SQL происходит посредством JDBC драйверов. Используются как вертикальное, так и горизонтальное разбиение данных, т.е. разные группы таблиц располагаются на разных серверах (вертикальное партиционирование), а данные больших таблицы дополнительно распределяются между серверами (горизонтальное партиционирование). Встроенный в СУБД аппарат партиционирования не используется — весь процесс реализован на уровне бизнес-логики. Распределенные транзакции не используются — всё только в пределах одного сервера. Для обеспечения целостности, связанные данные помещаются на один сервер или, если это невозможно, дополнительно разработывается логика обеспечения целостности данных. В запросах к БД не используются JOIN даже среди локальных таблиц для минимизации нагрузки на CPU. Вместо этого используется денормализация данных или JOIN происходят на уровне бизнес сервисов, что позволяет осуществлять JOIN как с данными из баз данных, так и с данными из кэша. При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры. Опять же для снижения потребления вычислительных ресурсов на серверах баз данных.
  SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция. Данные удаляются чаще всего через маркер: запись сначала отмечается как удаленная, а потом удаляется окончательно с помощью фонового процесса. Широко используются индексы, как обычные, так и кластерные. Последние для оптимизации наиболее высокочастотных запросов в таблицу. Используется C реализация BerkleyDB версии 4.5. Для работы с BerkleydDB используется своя библиотека, позволяющая организовывать двухнодовые master-slave кластера с использованием родной BDB репликация. Запись происходит только в master, чтение происходит с обеих нод. Данные хранятся в tmpfs, transaction логи сохраняются на дисках. Резервная копия логов делается каждые 15 минут. Сервера одного кластера размещены на разных лучах питания дабы не потерять обе копии одновременно. Помимо прочего, BerkleyDB используется и в роли очереди заданий. Внутри системы используется взвешенный round robin, а также вертикальное и горизонтальное разбиение данных как на уровне СУБД, так и на уровне кэширования. В разработке новое решение для хранения данных, так как необходим еще более быстрый и надежный доступ к данным.
• уровень инфраструктуры (логирование, конфигурация и мониторинг) - Для агрегации статистики используется собственная библиотека, основанная на log4j. Сохраняется такая информация, как количество вызовов, среднее, максимальное и минимальное время выполнения, количество ошибок. Данные сохраняются во временные базы, но раз в минуту данные переносятся из них в общий склад данных (data warehouse), а временные базы очищаются. Сам склад реализован на базе решений от Microsoft: MS SQL 2008 и сиситема генерации отчетов Reporting Services. Он расположен на 13 серверах, находящихся в отдельной от production среде. Некоторые из них отвечают за статистику в реальном времени, а некоторые за ведение и предоставление доступа к архиву. Общий объем статистических данных составляет 13Тб. Планируется внедрение многомерного анализа статистики на основе OLAP. Управление сервисами происходит через самописную централизованную систему конфигурации. Через веб-интерфейс доступно изменение расположения портлетов, конфигурацим кластеров, измениние логики сервисов и прочее. Вся конфигурация сохраняется в базе данных. Каждый из серверов периодически проверяет, есть ли обновления для приложений, которые на нем запущены, и, если есть, применяет их.

Мониторинг логически разделен на две части:

1. Мониторинг сервисов и компонентов
2. Мониторинг ресурсов, оборудования и сети

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

Вконтакте — самым значимым отличием от архитектуры многих других крупных интернет-проектов является тот факт, что сервера Вконтакте многофункциональны. Т.е. Нет четкого разделения на серверы баз данных, файловые серверы и т.д. - они одновременно используются в нескольких ролях. При этом перераспределение ролей происходит в полуавтоматическом режиме с участием системных администраторов. С одной стороны, это оптимизирует эффективность использования системных ресурсов, что хорошо, но с другой стороны — повышает вероятность конфликтов на уровне операционной системы в рамках одного сервера, что влечет за собой проблемы стабильности, Впрочем, несмотря на использование серверов в разных ролях, вычислительные мощности проекта обычно используются менее чем на 20%. Балансировка нагрузки между серверами происходит по многоуровневой схеме, которая включает в себя балансировку на уровне DNS(домен обслуживают с помощью 32 IP-адресов), а также маршрутизацию запросов внутри системы, причем разные сервера используются для разных типов запросов. Например генерация страниц с новостями работает по хитрой схеме, использующей возможности протокола memcached по параллельной отправке запросов на получение данных по большому количеству ключей. В случае отсутствия данных в кеше, аналогичный запрос отправляется системе хранения данных, а полученные результаты подвергаются сортировке, фильтрации и отбрасыванию лишнего уже на уровне PHP-кода.

В проекте используются достаточно мощное оборудование, примечательно, что сервера не брендированны, а собираются специализированной российской компанией. Сейчас оборудование компании Вконтакте расположено в четырех датацентрах в Санкт-Петербурге и Москве, причем вся основная база данных располагается в одном датацентре в Санкт-Петербурге, а в Москве хостится только аудио и видео. В планах сделать репликацию базы данных с другим датацентром в Ленинградской области, а так же использовать Content Delivery Network для повышения скорости скачивания медийного контента в регионах.

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

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

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

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

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

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

ОБОРУДОВАНИЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

1. Операционные системы

• Однноклассники - windows, Linux Дистрибутив OpenSUSE;
• Вконтакте — Linux Дистрибутив Debian;
• ФейсБук — Linux.

1. Основные языки программирования

• Однноклассники - Java;
• Вконтакте — PHP+надстройка;
• ФейсБук — PHP+надстройка.

1. Используемые Базы Данных

• Однноклассники - MSSQL2005 и 2008;
• Вконтакте — Собственная СУБД и MySQL;
• ФейсБук — MySQL.

1. Вспомогательные Базы Данных

• Однноклассники - BerKleyDB;
• Вконтакте — memcached;
• ФейсБук — memcached.

1. Сервера

• Однноклассники - 4 ядерный процессор по 2 на сервер, 48 Гб оперативной памяти;
• Вконтакте — 8 ядерный процессор по 2 на сервер, 64 Гб оперативной памяти;
• ФейсБук — 25 ТБ оперативной памяти на несколько тысяч серверов.

ПОЛЬЗОВАТЕЛИ И СОТРУДНИКИ

1. Количество зарегистрированных пользователей

• Однноклассники - 50 000 000 чел;
• Вконтакте — 100 000 000 чел;
• ФейсБук — 500 000 000 чел.

1. Штат

• Однноклассники - 70 чел;
• Вконтакте — 100 чел;
• ФейсБук — 500 чел.

1. Количество разработчиков

• Однноклассники - 40 чел;
• Вконтакте — 40 чел;
• ФейсБук — 400 чел.

АНАЛИЗ

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

Как видно по данным опубликованным выше, то проект Одноклассники совсем уж отстает, но если взглянуть на статистику тех лет до того как компания Mail Group выкупила Одноклассники, то темпы роста шли стремительно успешно, вообще не мало перспективных проектов данная компания уже затормозила выкупив их. Если рассматривать одноклассники по производительности относительно двух других проектов, то можно сказать не вооруженным глазом, что проект хромает, клиентские компьютеры потребляют огромное количество ресурсов для работы с данным сайтом, но взглянув на данный представленные выше становится ясно по чему так происходит. Огромное количество криво написанного JavaScript кода с таким же количеством передачи по AJAX различных данных, не могут остаться бесследными. Так же серверный язык (я конечно ничего не имею против) но не очень рентабелен для такого рода проектов, вот взгляните на Вконтакте и ФейсБук их разработчики вышли очень из положения очень креативными решениями в доработке PHP, а ФейсБук даже разработал HipHop который переводит PHP код в оптимизированный код C++ что увеличивает производительность. Такая же проблема с базами данных, например Вконтакте вообще разработала на С собственную базу данных в разработке которой принимали участие лучшие умы России, ФейсБук доработала MySQL а Одноклассники опять же позади, воспользовались базой MSSQL2005, что очень сильно уступает двум предыдущим базам данных. Разницу в производительности можно заметить например при первой загрузке страницы, процесс очень долгий, разработчики данной проекта решили обойтись максимальным кэшированием для наименьшего обращения к базам данных. Вообще глядя на все эти архитектуры складывается такое впечатление, что одноклассники такие хрупкие как карточный домик и стоит лишь подуть сильному ветру он рухнет.

Думаю этой информации достаточно, для понимания устройства и выбора наиболее устойчивой социальной сети (вообще дело религии) для себя.