Семантические веб-сервисы

Онтология

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

Современные онтологии обычно состоят из экземпляров, понятий, атрибутов и отношений.

Для описания онтологий Веб был разработан специальный язык - OWL (Web Ontology Language), построенный на основе XML. Язык OWL может быть использован для описания классов и отношений между ними. В основе языка — представление действительности в модели данных "объект — свойство". Язык применим не только для описания веб-страниц, но и любых объектов действительности и рассматривается в качестве одной из фундаментальных технологий, необходимых для построения Семантической веб-сети.

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

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

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

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

 

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

 

Одноклассники - Код проекта в целом написан на 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. Управление сервисами происходит через самописную централизованную систему конфигурации. Через веб-интерфейс доступно изменение расположения портлетов, конфигурацим кластеров, измениние логики сервисов и прочее. Вся конфигурация сохраняется в базе данных. Каждый из серверов периодически проверяет, есть ли обновления для приложений, которые на нем запущены, и, если есть, применяет их.

 

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

Мониторинг сервисов и компонентов

Мониторинг ресурсов, оборудования и сети

Система мониторинга сервисов также самописная и основывается на оперативных данных с упомянутого выше склада. Мониторинг ресурсов и здоровья оборудования же онован на 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 лицензией.