Содержание


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

Play и Amazon RDS

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

Comments

Серия контента:

Этот контент является частью # из серии # статей: Java development 2.0: Вторая волна разработки Java-приложений.

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Java development 2.0: Вторая волна разработки Java-приложений.

Следите за выходом новых статей этой серии.

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

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

В этом месяце я расскажу вам о сервисе 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 (см. Ресурсы).

Что делает 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 (Запустить экземпляр).

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

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

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

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

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

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

Рисунок 3. Опции управления RDS
Launching and configuring database management via the AWS console.
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.
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.
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.
Magnus in the cloud, as displayed on the AWS console.

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

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