Java development 2.0: Вторая волна разработки Java-приложений.: Play и Amazon RDS

Реляционное управление данными как услуга? Почему нет?

Сервис поддержки реляционных баз данных Amazon Relational Database Service (RDS) перекладывает задачу поддержки базы данных на Amazon Web Services, что существенно упрощает расширение или выгрузку хранилища данных вашего приложения. В этом месяце Эндрю Гловер вновь обращается к своему облачному приложению для приема данных о местоположении с мобильных телефонов и заменяет исходное хранилище NoSQL традиционной системой СУРБД. Интегрированная среда Play и консоль AWS позволяют сделать это без труда.

Эндрю Гловер, президент компании, Stelligent Incorporated

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



04.07.2012

Об этой серии

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

Пару месяцев назад в этой серии статей я познакомил вас с Amazon Elastic Beanstalk — сервисом PaaS (платформа как услуга), предназначенным для разработки приложений на Java. Тогда я продемонстрировал, что Beanstalk очень гибок и позволяет разработчикам использовать практически любую комбинацию средств для достижения поставленной цели. Кроме быстрой разработки Web-приложений с помощью Play, я смог воспользоваться для управления своими экземплярами MongoDB еще одним сервисом PaaS — MongoHQ. Применение этих двух инфраструктур PaaS освободило меня от большей части работы по поддержанию приложений, и я смог сфокусироваться на создании потрясающего приложения, объединяющего облачную среду с мобильными телефонами.

Сервис MongoHQ PaaS отлично справился с этим проектом, но что если бы я предпочел хранить свои данные в традиционной СУРБД? В конце концов большинство разработчиков Java чувствуют себя более комфортно, программируя традиционные базы данных. Следует также признать, что не каждый проект может позволить себе отказаться от ACID-подхода, чего требуют многие хранилища NoSQL.

DB2 pureScale

Масштабирование реляционных баз данных по требованию - далеко не новая идея. DB2 pureScale компании IBM во многом напоминает RDS в том смысле, что вы можете автоматически масштабировать распределенные экземпляры DB2, одновременно обеспечивая высокую надежность своих данных. Сервис pureScale поддерживает быстрый рост объемов данных за счет неограниченной емкости, непрерывной доступности и прозрачности приложений (т.е. вам не понадобится вносить изменения в свое приложение). Дополнительную информацию о pureScale можно найти в Ресурсах.

В этом месяце я расскажу вам о сервисе Amazon Relational Database Service (RDS), еще одном превосходном и гибком продукте семейства Amazon Web Services. Работа с Amazon RDS ненамного сложнее запуска экземпляров MongoDB, размещенных в MongoHQ. Управлять реляционными свойствами этой СУБД совсем несложно, хотя и могут возникать некоторые интересные проблемы, связанные с масштабированием. Нам просто понадобится уделить некоторое время созданию схемы, и мы будем готовы отправиться в путь.

Amazon RDS

Amazon Relational Database Service представляет собой PaaS-услугу, предлагающую масштабируемый по требованию облачный экземпляр MySQL, предназначенный для разработки приложений. Впрочем, если бы RDS была всего лишь экземпляром MySQL, работающим в облаке, то я бы всего этого не писал. В конце концов, я еще в 2009 году показал, как пользоваться образом Amazon EC2 с работающим MySQL (см. Ресурсы).

Реляционное масштабирование

Масштабирование — одна из основных причин, почему подходу NoSQL удалось набрать популярность. Одна из причин роста популярности NoSQL заключается в том, что традиционные реляционные системы довольно сложно масштабируются в горизонтальном направлении за пределами узла, хотя и предпринимались попытки использовать такие методы, как шардинг. Не то чтобы вы не могли распределять данные по узлам в реляционной системе, — просто эта операция связана с дополнительными сложностями и/или затратами. В RDS, которая представляет собой систему управления реляционными базами данных, масштабирование осуществляется копированием во все узлы всей базы данных, а не ее частей. Это, в свою очередь, может создать проблемы с избыточностью данных. (Подробную информацию о хранилище NoSQL и шардинге СУРБД можно найти в Ресурсах).

Что делает RDS достойной внимания — это то, что она представляет собой PaaS, управляемый компанией Amazon, который предлагает практически те же услуги и гибкость, что и Elastic Beanstalk. Amazon поддерживает резервное копирование, репликацию и даже установку заплат. Но, самое главное, система RDS полностью масштабируема — вы можете увеличить емкость хранилища своего приложения несколькими щелчками мыши. Кроме того, Amazon позволяет реплицировать RDS по зонам доступности, так что если одна из зон отключится или в ней будет выполняться плановая профилактика, вы по-прежнему сможете работать со своими данными. Вы можете даже создать экземпляры своей базы данных, доступные только для чтения, обеспечив высокую скорость чтения для приложений, работающих с большими объемами данных.

Приложения, изначально рассчитанные на работу с MySQL, могут сразу же воспользоваться преимуществами RDS, а поскольку база данных находится в облаке, в вашем приложении ничего не нужно менять. И, наконец, как и все остальное в AWS, услуга RDS основана на модели pay-as-you-go («платишь за то, что используешь»). Вам не придется заранее оплачивать оборудование или лицензии. Вы платите за емкость, хранилище и полосу по мере их потребления.


Создание и настройка RDS

AWS позволяет развертывать различные услуги либо через командную строку, либо через консоль управления AWS. Я предпочитаю консоль, поскольку она показывает опции, доступные для различных аспектов RDS. Итак, мы начнем с того, что выберем вкладку RDS в консоли управления AWS и выберем Launch Instance (Запустить экземпляр).

Подписка на RDS

Как и для всех остальных услуг в Amazon Web Services, чтобы включиться в игру, надо создать учетную запись. Как только вы это сделаете, вы сможете подписаться на Amazon RDS. Не забывайте, что все услуги Amazon оплачиваются по мере потребления!

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

Как видно на рисунке 1, вам нужно указать имя схемы базы данных, имя администратора и пароль:

Рисунок 1. Создание экземпляра RDS
Configuring the MySQL database instance.

Нажав кнопку Continue (продолжить), вы окажетесь в другом диалоговом окне, позволяющем настроить общие параметры базы данных, — начиная с ее имени, которое является частью адреса JDBC. Кроме того, можно изменить порт, который будет прослушивать MySQL, и выбрать зону доступности для базы данных, как показано на рисунке 2:

Рисунок 2. Настройка экземпляра RDS
A screen for selecting the database availability zones.

Далее нужно настроить параметры управления, определяющие, как AWS будет создавать резервные копии ваших данных и когда будут выполняться плановые профилактики, как показано на рисунке3:

Рисунок 3. Опции управления RDS
Launching and configuring database management via the AWS console.

Щелкнув по кнопке Continue (продолжить) и проверив конфигурацию, вы можете запустить свой экземпляр RDS. Это может занять несколько минут, так что у вас будет время выпить кофе или заглянуть в Твиттер. Когда RDS запустится, все будет работать быстро!

Система безопасности RDS

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

Система безопасности RDS достаточно мощна и позволяет указать один IP адрес или ряд адресов, которым позволено работать с RDS; однако для этой статьи я хочу несколько все упростить и разрешить подключение к моему экземпляру с любого IP-адреса. Для этого я перейду на панель RDS DB Security Group (Группа безопасности RDS DB) и заменю значение CIDR/IP на 0.0.0.0/0, что разрешает подключение с любого IP-адреса. Этот шаг показан на рисунке 4:

Рисунок 4. Рисунок 4. Настройки безопасности RDS
A screenshot of the RDS DB Security Group pane on AWS.

Завершив этот шаг, перегрузите свой экземпляр RDS. (Щелкните правой кнопкой по экземпляру на панели управления AWS и выберите перезагрузку (reboot).)

Если вы выберете работающий экземпляр RDS, то увидите панель описания (показанную на рисунке 5), которая содержит несколько важных деталей. В данный момент наибольший интерес представляет параметр endpoint (конечная точка), который представляет собой URL, с помощью которого вы будете подключаться к своему экземпляру MySQL.

Рисунок 5. Рисунок 5. Панель RDS
A screenshot of the RDS dashboard on the AWS console.

Теперь вы можете взять свой любимый инструмент управления базами данных (или, если хотите, воспользоваться командной строкой) и направить его на свой экземпляр RDS. Я буду использовать Sequel Pro, который, подобно всем графическим средствам, предлагает удобный интерфейс для просмотра таблиц и данных и имеет консоль запросов. Для подключения вам понадобятся имя пользователя базы данных, пароль и адрес конечной точки.


Magnus в стиле СУРБД

Если вы читали мое введение в Amazon Elastic Beanstalk (см. Ресурсы), вы уже знакомы с Magnus, облачным приложением для работы с мобильными телефонами, которое я написал для этой статьи. Для Magnus я создал в MongoDB два набора: Account (учетная запись) и Location (местоположение). (Заметьте, что я мог бы с той же легкостью создать один набор под названием Account, так чтобы каждый документ содержал вложенный документ набора Location). Наличие двух наборов позволяет сохранять местоположения учетных записей, которые в моем сценарии будут поступать с мобильных телефонов из разных точек мира.

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

Чтобы связать Magnus с миром SQL, мне нужно сначала определить реляционные таблицы, которые (вполне предсказуемо) я назову account и location. Это показано в листинге 1:

Листинг 1. Таблица учетных записей
CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) DEFAULT NULL,
  PRIMARY KEY (`id`)
)

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

Листинг 2. Таблица местоположений
CREATE TABLE `location` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `account_id` int(11) DEFAULT NULL,
  `latitude` double DEFAULT NULL,
  `longitude` double DEFAULT NULL,
  `date_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `name` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `account_id` (`account_id`),
  FOREIGN KEY (`account_id`) REFERENCES `account` (`id`)
)

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


Настройка Play

Интегрированная среда Play для создания Web-приложений (см. Ресурсы) так же хорошо работает в Amazon RDS, как и в Elastic Beanstalk, поэтому я снова буду использовать ее для создания своего приложения. Play позволяет очень легко переключаться между разными хранилищами и с самого начала поддерживает JPA. Для переключения с реализации MongoHQ на реализацию, использующую Amazon RDS, потребуется внести в мою модель лишь несколько изменений. Прежде всего, поскольку в Play встроена поддержка JPA, мне придется изменить файл application.conf в Magnus и указать ссылки на мой экземпляр RDS, как показано в листинге 3:

Листинг 3. Таблица местоположений
db.url=jdbc:mysql://magnus.cp3pl5vineyp.us-east-1.rds.amazonaws.com/magnus_locations
db.driver=com.mysql.jdbc.Driver
db.user=admin
db.pass=g3tf0kl

Здесь нет ничего особенного: листинг 3 — это 100-процентный JDBC!

Моделирование взаимосвязей

Как и почти во всех библиотеках СУРБД ORM, я собираюсь смоделировать свои таблицы в отношении один-к-одному с объектами Java верхнего уровня: одним типа Account и одним типа Location. Мой Location будет ссылаться назад на Account.

Происхождение от типа Model среды Play дает мне несколько готовых бонусов. Прежде всего я получаю такие средства? как поиск, а также типичные CRUD-методы save (сохранить) и delete (удалить).

Мой класс Account использует две аннотации JPA. Показанная в листинге 4 аннотация Table необходима для ссылки на мою переименованную (в нижний регистр) таблицу account.

Листинг 4. Тип Account
package models;

import play.db.jpa.Model;
import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name = "account") //required otherwise table is Account
public class Account extends Model {
 public String name;
}

Мой POJO Location (в следующем листинге 5) несколько сложнее. Мне нужно добавить в него две дополнительные аннотации, чтобы создать взаимосвязь много-к-одному между Location и Account.

Листинг 5. Определение класса Location с помощью JPA
package models;

import play.db.jpa.Model;
import javax.persistence.*;
import java.math.BigDecimal;
import java.sql.Timestamp;

@Entity
@Table(name = "location")
public class Location extends Model {

 public BigDecimal latitude;
 public BigDecimal longitude;
 public String name;
 @Column(name = "date_time")
 public Timestamp timestamp;

 @ManyToOne
 @JoinColumn(name="account_id", nullable = false)
 public Account account;

}

И, наконец, в листинге 6 я обновляю метод saveLocation моего контроллера Application. (Не забывайте, что в предыдущей версии Magnus я направил все HTTP PUT в /location/ в этот метод.) Метод saveLocation просто создает новый объект Location (и соответствующую запись) и привязывает этот экземпляр Location к существующему Account. Поскольку до этого я расширил объект Model среды Play, я получаю также удобный метод findById.

Листинг 6. Обновления данных о местоположении в RDS
public static void saveLocation(String id, JsonObject body) throws Exception {
 String eventname = body.getAsJsonPrimitive("name").getAsString();
 double latitude = body.getAsJsonPrimitive("latitude").getAsDouble();
 double longitude = body.getAsJsonPrimitive("longitude").getAsDouble();

 Location loc = new Location();
 loc.longitude = new BigDecimal(longitude);
 loc.latitude = new BigDecimal(latitude);
 loc.name = eventname;
 loc.account = Account.findById(new Long(id));

 loc.save();

 renderJSON(getSuccessMessage());
}

Проверка с помощью RESTClient

Я могу проверить работу моего обновленного сервиса местоположений с помощью RESTClient. Так же, как я делал это для Magnus, я создам несколько документов JSON и выполню их отправку.

Рисунок 6. Проверка с помощью RESTClient
A screenshot of the RESTClient interface.

Когда мой метод успешно сохраняет новую запись Location, назад отправляется ответ JSON с подтверждением. Поскольку мой любимый графический интерфейс позволяет просматривать данные в СУРБД, я просто проверяю таблицу location, и что вы думаете? Я вижу новые записи Magnus, отправленные в облако через RDS!

Рисунок 7. О, места, что ты увидишь!
Magnus in the cloud, as displayed on the AWS console.

Заключение

Услуги PaaS очень полезны программистам, ищущим средства быстрой разработки и внедрения Web-приложений. В этой статье я представил Amazon RDS, решение PaaS, размещающее в облаке реляционную базу данных (в данном случае MySQL, хотя RDS также поддерживает базы данных Oracle). Amazon RDS создается очень легко и работает так же, как и различные СУРБД, с которыми вы, вероятно, уже давно знакомы. Важное отличие заключается в том, что поддержкой базы за вас занимается Amazon.

Ресурсы

Научиться

Получить продукты и технологии

  • Сервис поддержки реляционных баз данных Amazon: этот Web-сервис на Java из семейства Web-сервисов Amazon позволяет создавать масштабируемые реляционные базы данных в облаке.
  • Интегрированная среда Play: эта среда, позиционируемая как Java-инфраструктура, созданная разработчиками Web-страниц, нацелена на повышение продуктивности разработки и работу с архитектурами RESTful.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=824142
ArticleTitle=Java development 2.0: Вторая волна разработки Java-приложений.: Play и Amazon RDS
publish-date=07042012