Ростелеком ТВ 

Веб ориентированное. Семь принципов создания современных веб-приложений. Реакция на изменение данных

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

Статья о планах обучения пользователей работе в СЭД поможет вам не допускать ошибок в работе.

Несомненными преимуществами веб-ориентированной системы являются следующие факты:

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

Учитывая, что в настоящее время браузеры не зависят от конкретной операционной системы пользователя, веб-ориентированные системы можно смело назвать кроссплатформенными (или межплатформенными).

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

Можно работать и в офисе, и дома, и в командировке, как со стационарного ПК, так и с ноутбука или планшета.

  1. Низкая совокупная стоимость владения . Стоимость владения веб-ориентированной системой фактически заключена в разработке, поддержке и развитии серверной части (веб-сервера и сервера приложений) и владении сервером базы данных системы.

Стоимость системы управления базами данных зависит от выбора технологии разработки веб-приложения: использования открытой полностью кроссплатформенной или конкретной платформы для создания веб-приложений, например, Microsoft ASP.NET, что в свою очередь может наложить требования к СУБД, но, в тоже время, имеет и ряд своих преимуществ.

Как и любые другие, веб-ориентированные системы в тоже время имеют свои недостатки:

  1. Для работы с системой необходимо подключение к сети Интернет.

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

2. Не все СЭД могут быть заменены на веб-ориентированные по причине ограниченности функциональных возможностей интернет-браузеров.

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

3. Вся информация, включая личную информацию пользователя, хранится на сервере.

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

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

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

Целю данной работы явлется анализ веб-ориентированных информационных систем для выделения общих подходов к их разработке.

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

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

Первичная аутентификация пользователя выполняется пользователем, путем ввода своего имени и пароля.

Автоматическая аутентификация. После первичной аутентификации пользователю передается идентификатор сессии (токен). При последующих запросах этот токен автоматически аутентифицирует пользователя.

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

Определение прав текущего пользователя;

Становка прав пользователей;

Автоматическое изменение прав при возникновении определенных событий.

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

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

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

Данная концепция закладывает мощный фундамент саморазвития информационной системы.

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

1. Брауде Э. Д Технология разработки программного обеспечения. – С-Пб.: Питер, 2004, – 656 с.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Подобные документы

    Обоснование выбора используемого программного обеспечения. Входная и выходная информация. Реляционная модель базы данных предметной области. Создание модели информационной системы с помощью Run All Fusion Process Modeler r7. Результаты тестовых испытаний.

    курсовая работа , добавлен 12.04.2014

    Рассмотрение структуры предприятия, обзор современного программного обеспечения. Описание информационной системы учета кадров. Создание информационной системы для работы с персоналом на основе выполненного анализа программных продуктов этого направления.

    дипломная работа , добавлен 03.07.2015

    Проектирование автоматизированных систем обработки информации и управления. Анализ структуры и деятельности предприятия, создание моделей "Как есть". Определение проблемных областей предприятия. Требования к структуре и функционированию системы.

    курсовая работа , добавлен 29.12.2012

    Цель создания информационной системы. Автоматизированная информационная система "Строительное предприятие". Использование вычислительной техники и программного обеспечения для создания автоматизированной информационной системы управления на предприятии.

    курсовая работа , добавлен 04.01.2011

    Ознакомление с основами работы ООО "Мир Компьютеров". Описание информационной системы предприятия. Разработка объектно-ориентированной модели подсистемы средствами Rational Rose и функциональной модели подсистемы средствами AllFusion Process Modeler.

    курсовая работа , добавлен 13.01.2015

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

    дипломная работа , добавлен 30.08.2010

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

    дипломная работа , добавлен 29.06.2011

    Обоснование необходимости совершенствования информационной системы (ИС) ООО "Мехсервис". Анализ системы учета деятельности авторемонтного предприятия. Разработка концепции построения автоматизированной ИС. Описание продукта информационной технологии.

    дипломная работа , добавлен 22.05.2012

Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.

Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Веб-сервера Apache также имеется возможность выполнять Веб-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects ).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

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

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки ( WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений , поддерживающим спецификаци ю J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" ( B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Веб-приложений c данными и приложениями партнеров с целью реализации схемы "предприятие-предприятие" ( B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

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

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [ , ]:

  • отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет автоматически реализовать клиентскую часть на всех платформах;
  • возможность подключения практически неограниченного количества клиентов;
  • благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных;
  • доступность при работоспособности сервера и каналов связи;
  • недоступность при отсутствии работоспособности сервера или каналов связи;
  • достаточно низкая скорость Веб сервера и каналов передачи данных;
  • относительно объема данных – архитектура Веб систем не имеет существенных ограничений.

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рис. 5.9 .


Рис. 5.9.

5.1.8. Сервис-ориентированная архитектура

Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP . Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс UDDI .

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

(SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами .

OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом ( OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.

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

Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)

Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).

Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются :

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

Принципы SOA:

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

Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.

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

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

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE , могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

, , Терминал , Сервер приложений , Сервер базы данных , Архитектура распределенных систем , , Сервис-ориентированная архитектура .

Я решил изменить это и написал статью-перевод-обзор об одном из докладов с конференции NoSQL прошедшей 5 октября в Нью-Йорке. В этой статье будет говорится о системе Riak, с которой мне довелось иметь счастье работать последнее время.

Что такое Riak? Многие модные слова популярные сейчас, можно отнести к Riak. Riak — это документно-ориентированная база данных. Riak — это децентрализованное key-value хранилище данных, с поддержкой стандартных операций — get , put и delete . Riak — это распределенное, масштабируемое, отказоустойчивое решение для хранения информации. А так же Riak — это система с открытым исходным кодом и поддержкой обращений с помощью HTTP, JSON и REST. Ну и конечно RIAK — это NoSQL.

Если копнуть глубже, можно увидеть, что на Riak оказало сильное влияние Amazon Dynamo , теорема CAP (C onsistency, A vailability and P artition Tolerance) Эрика Бревера (Eric Brewer), сама система Интернета в целом, а так же опыт команды разработки Basho в разработке сетевых сред. Мы начали разрабатывать Riak осенью 2007 года, для использования в двух приложениях для Basho, которые были запущенны на Riak и работали на нем большую часть времени.

Чтобы понять почему Riak настолько мощный, требуется рассказать немного теории. Вначале поговорим об Amazon Dynamo.В документе описывающем Amazon Dynamo есть три термина для описания поведения распределенной системы хранения данных: N , R и W . N — это количество реплик каждого значения в хранилище. R — количество данных реплик для выполнения операции чтения. W — количество реплик необходимых для выполнения операции записи. Цель Riak — перенести N , R , и W в логику приложения. Это позволяет Riak адаптироваться к требованиям отдельных приложений.

N для каждого сегмента (bucket ). Например все объекты в сегменте «artist» будут иметь одинаковое значение N , а объекты в сегменте «album» совсем другое. Система использует непротиворечивый алгоритм хеширования для выбора места сохранения N количества реплик ваших данных. Когда поступает запрос, Riak использует хеширование для преобразования текстового ключа в 160-битное число. Когда узел кластера добавляется в Riak, он получает части от 160-битного пространства ключей. Узел имеющий ближайшее значение хэша от ключа (160-битное число) и содержит в себе первую реплику. Остальные N реплик сохранены на узлах с другими N-1 частями 160-битного пространства ключей.Непротиворечивый алгоритм кэширования очень важен — он позволяет каждому узлу Riak выполнить любой запрос. Поскольку любой узел может вычислить, с какими именно другими узлами необходимо связаться, чтобы выполнить запрос, любой узел может выступать в качестве организатора для любого клиента. Тут нет управляющего сервера , нет единой точки для сбоя в системе.

Riak использует разные значения R для каждого запроса. Каждый раз когда вы делаете запрос на получение данных, вы можете использовать разное значение R . Значение R определяет количество узлов, которым необходимо вернуть успешный ответ, перед тем как Riak вернет запрашивающему клиенту ответ. Riak пытается прочитать все возможные реплики (N ), но когда будет достигнуто значение R , данные будут отправлены обратно клиенту.

Riak использует разные значения W для каждого запроса. Значение W определяет количество узлов, которым необходимо вернуть успешный ответ, перед тем как Riak вернет запрашивающему клиенту ответ. Riak пытается записать все возможные реплики (N ) данных, но когда будет достигнуто значение W , результат будет отправлен обратно клиенту.

Предоставление клиенту возможности для указания значений R и W во время запроса, означает, что во время запроса приложение может указать точно, сколько узлов могут выйти из строя. Это очень просто: для каждого запроса, N-R (для чтения) или N-W (для записи) узлов может быть недоступно, однако кластер и данные будут по-прежнему вполне доступны.

Итак, в примере который мы использовали с N=3 и R=W=2 , мы можем иметь 3-2=1 узел недоступным в кластере, но кластер по прежнему будет предоставлять данные. Для особо важных данных, мы можем увеличить значение N до 10, и если мы все ещё будем использовать значение R или W равное 2, мы можем иметь 8 недоступных узлов в кластере, но запросы на чтение и запись будут проходить успешно. Riak дает возможность изменять значения N/R/W так как это хороший способ улучшить поведение приложения при использовании теоремы CAP .

Если вы знакомы с теоремой CAP Эрика Бревера, вы знаете, что есть три аспекта, которые необходимо учитывать при рассуждениях о хранении данных: целостность данных, доступность данных в хранилище, и устойчивость к разделению. Если вы знакомы с исследованием, вы также знаете, что невозможно реализовать систему отвечающую всем трем условиям.

Поскольку вы не можете реализовать все три условия, большинство систем хранения данных используют два. Riak позволяет, не только выбрать любые из них, но и разные приложения могут выбрать различные объемы каждого. Вероятнее всего вы выберите доступность и устойчивость к разделению. Однако вы разрабатываете аппликации которые работают на реальных машинах и вы хотите чтобы они были доступны в любое время для пользователей. Структура Riak реализована для поддержки этой возможности (мы хотим чтобы наши приложения работали все время). Это означает, что вы готовы пожертвовать целостностью данных. Есть много советов как выв можете гарантировать целостность данных (например read-your-writes) в документе описывающем Amazon Dynamo и я советую вам перечитать этот документ.

Вот простой пример как может быть решен вопрос с целостностью данных. Давайте посмотрим на кластер который уже работает и имеет документ с версией 0.

Вдруг в сети происходит сбой. Узлы 0 и 2 находятся в Нью-Йорке, узлы 1 и 3 в Лос-Анджелесе и трансконтинентальная связь рвется. Как поведет себя каждая часть кластера? Если вы установили значения N/R/W надлежащим образом, обе части кластера по сути будут предоставлять версию 0 документа, как и раньше. Клиенты не будут знать о сбое. Теперь предположим что клиент внес изменения в документ, хранящийся в половине кластера находящегося в Нью-Йорке (вы же указали N/R/W так, чтобы это было разрешено?). Этот клиент ввел некоторое несоответствие. Теперь клиенты присоединившиеся к части кластера находящегося в Нью-Йорке получат версию 1 документа, в то время как клиенты присоединившееся к части находящейся в Лос-Анджелесе получат версию 0 этого документа. Теперь предположим что трансконтинентальная связь восстанавливается и обе половины кластера работают вместе. Что должен сделать Riak с двумя разными версиями документа?

В этом случае Riak использует алгоритм вектора времени , для определения какая версия документа более корректная. Алгоритм вектора времени это специальная реализация алгоритма временных меток Лампорта (Lamport clocks / Lamport timestamps). В отличии от обычных временных меток, система временных меток Лампорта построена таким образом, что происхождение и преемственность, может быть определена путем простого сравнения. Каждый раз когда данные сохраняются в Riak, их вектор времени увеличивается, и когда кластер восстановиться Riak сможет определить какие данные сохранить. В нашем случае Riak определит что версия 1 является приемником версии 0, и версия 0 будет заменена версией 1, и данные снова будут целостны.

Все становится немного более интересно, если в то время как части не связанны, клиенты внесут изменения в обоих частях кластера. Теперь когда кластер восстановится, вектор времени покажет, что ни одна из версий является преемницей другой версии. Riak не может определить какая из версий должна быть выбрана, поэтому в этом случае как и с возможностью изменить значения N/R/W, Riak переносит возможность урегулирования конфликта в приложение. Вместо реализации произвольного правила выбора версии как это сделано в других системах, Riak возвращает оба значения приложению предоставляя возможность выбора более верного варианта. Конечно если вы хотите использовать просто правило — данные пришедшие последними и используются, в Riak есть простой флаг для включения такого поведения (allow_mult свойство сегмента)

После всей этой теории как насчет нескольких примеров кода для демонстрации как легко работать с Riak?

Так как Riak написан на Erlang, давайте начнем с Erlang.

Первая строка кода описывает присоединение нашего клиента к кластеру Riak. Вторая строка создает новый объект (документ, пара ключ/значение). Третья строка сохраняет объект в Riak. Четвертая возвращает объект обратно из Riak. последние две строки изменяют значение нашего объекта и сохраняют его снова в кластер Riak.

Если вы не хотите использовать Erlang, Riak так же поставляется с библиотеками для Python…


…Riak так же имеет библиотеки для Ruby…


… Java…

… PHP…


… JavaScript…


…но на самом деле все эти библиотеки работают с Riak с помощью стандартного RESTful HTTP, и это позволяет использовать Riak на любой системе поддерживающей HTTP — например используя инструменты командной строки такие как curl или wget .


Это хорошо когда вам нужно отправить или получить данные из Riak, но что делать когда вы хотите сделать запрос по нескольким объектам одновременно? Это же NoSQL, ведь так? Как насчет небольшого Map/Reduce?


Система Map/Reduce Riak имеет много общего с другими системами Map/Reduce. Функция Map происходит на узле где находятся данные, увеличивая локальность данных одновременно с распределением вычислений в кластере. Часть Map/Reduce Riak которая более всего отличается от других решений заметна в том, что Riak не запускает метод Map над всеми данными в сегменте (bucket). Вместо этого Riak дает возможность клиенту предоставить список ключей объектов на которых должен быть запущен метод Map. Методы Map могут предоставлять больше ключей для более поздних фаз выполнения методов Map, но список ключей для метода Map должен быть определен всегда. Конечно вы можете указать любое количество ключей которое вы хотите, например если вы хотите выполнить метод Map по всем значениям в сегменте, достаточно включить их все в запрос Map/Reduce (функции list_keys или list_bucket могут быть полезны в таких случаях).

Различия в реализации Map/Reduce Riak при сравнении с другими системами обусловлены сильным желанием поддержки ссылок в Riak. Первый вопрос при переходе из мира RDBMS это — «Как я могу организовать связи между моими данными?» Было решено что лучший ответ на этот вопрос — ссылки.


Например если вы хотите организовать связи между записью исполнителя и несколькими записями альбомов, вы хотите создавать ссылки к альбомам в записи исполнителя. Аналогично вы можете создать ссылки в записи альбома к записям композиций входящим в этот альбом. Как только вы добавите ссылки и определите как Riak может получить эти ссылки из ваших объектов, вы получите доступ к новому синтаксису Map/Reduce. Например в данном примере вы можете видеть простой синтаксис позволяющий нам сказать — «Начни с исполнителя REM, потом следуй ко всем альбомам с которым связан исполнитель, потом следуй ко всем композициям с которыми связан альбом, потом извлеки имена этих композиций." Результатом этого запроса будут имена всех композиций REM которые были когда-либо выпущены.

Разработчики решили что link-walking (переход по ссылкам) настолько полезный, что даже реализовали URL синтаксис для него. Вверху вы можете видеть ссылку похожую на URL, и выполнение GET запроса по этому URL вернет вам список всех объектов композиций, который ранее мы получили в примере с Map/Reduce.

Можно ещё много чего рассказать про Riak, включая как создавать подключаемые бэкэнды, как использовать систему событий, как отслеживать состояние кластеров Riak и как реализовать межкластерную репликацию. Но это подождет до другой презентации.

Если вы заинтересованы в получении дополнительной информации, вы можете посетить сайт