|
|
|||||||||||||||||||||||||||||
|
Вторая волна разработки Java-приложений: Базы данных типа NoSQLИсточник: ibm
Эндрю Гловер, президент компании, Stelligent Incorporated.
Реляционные СУБД занимают лидирующие позиции уже более 30 лет, однако эта ситуация может измениться в связи с растущей популярностью баз данных, не имеющих реляционных схем данных (или баз данных типа NoSQL). РСУБД предоставляют надежные средства хранения данных в системах с традиционной клиент-серверной архитектурой, которые, к сожалению, не всегда легко и дешево масштабируются путем добавления новых вычислительных узлов. Это становится весьма серьезным ограничением в эпоху таких Web-приложений, как Facebook и Twitter, которым хорошая масштабируемость крайне необходима. Проблему масштабируемости не удалось решить ранним альтернативам реляционных СУБД (помните объектно-ориентированные базы данных?). В отличие от них СУБД NoSQL, подобные Bigtable и SimpleDB (от Google и Amazon соответственно), проектировались именно в расчете на высокую масштабируемость Web-приложений. NoSQL вполне могут оказаться решением критически важной проблемы масштабируемости, которая будет становиться все более актуальной по мере развития Web 2.0. В этой статье серии Вторая волна разработки Java-приложений приводится введение в проектирование баз данных без использования схем, что представляет собой одну из главных трудностей при переходе на NoSQL для разработчиков, ранее работавших с реляционными СУБД. Вы увидите, что самое главное в этом процессе - начать проектирование с создания модели предметной области, а не реляционной модели. При работе с Bigtable (как в примерах ниже) вы можете рассчитывать на помощь Gaelyk - легковесной инфраструктуры, расширяющей возможности платформы Google App Engine. Об этой серии. NoSQL: Нужен ли новый взгляд на мир?Рассуждая о нереляционных базах данных, многие разработчики в первую очередь упоминают о необходимости изменения своего мировоззрения. Однако, на мой взгляд, это зависит от их любимого подхода к созданию моделей данных. Если вы привыкли начинать разработку приложения с создания структуры базы данных, в частности с описания таблиц и связей между ними, то проектирование нереляционного хранилища данных, например на основе Bigtable, потребует от вас изменения вашего подхода в целом. Если же вы обычно начинаете создание приложений с моделирования предметной области, то нереляционная структура Bigtable должна выглядеть более естественно. Масштабируемость у них в крови. В нереляционных базах данных не используется соединение таблиц, первичные или вторичные ключи (ключи присутствуют, но в менее строгом виде). Таким образом, вы будете сильно разочарованы, попробовав применить реляционное моделирование при создании модели данных для базы данных NoSQL. Гораздо проще начать с описания предметной области. При этом лично мне доставляет удовольствие гибкость нереляционной структуры БД, лежащей в основе модели предметной области. Таким образом, сложность перехода на нереляционную модель данных зависит от вашего подхода к проектированию приложений, а именно: начинаете вы с реляционной схемы или описания предметной области. Начав использовать СУБД, подобную CouchDB или Bigtable, вам придется распрощаться с удобными инфраструктурами хранения данных, например Hibernate. C другой стороны, перед вами откроются широкие возможности для самостоятельного создания такой технологии для своих нужд. А в процессе ее создания вы познакомитесь с тонкостями баз данных NoSQL. Сущности и связиНереляционные СУБД позволяют проектировать модель предметной области в виде набора объектов, причем эта возможность упрощается такими современными решениями, как Gaelyk. На следующем этапе вам предстоит отобразить созданную модель на структуру базы данных, что в случае использования Google App Engine не представляет никаких трудностей. Ранее, в статье Инфраструктура Gaelyk в приложениях для Google App Engine, вы познакомились с Gaelyk - Groovy-библиотекой, которая упрощает работу с хранилищем данных Google. В настоящей статье немало внимания будет уделяться объекту
Объектное проектирование. Подобный подход к сохранению данных вполне приемлем, однако легко заметить, что он становится трудоемким при интенсивной работе с билетами, например, если их приходится создавать или искать в различных сервлетах. Частично эту задачу можно облегчить при помощи общего сервлета (или грувлета), но есть более логичное решение - создание объекта СоревнованияВместо того чтобы вернуться к примеру с извещениями из первой статьи о Gaelyk, мы рассмотрим новое приложение, иллюстрирующее методы, которые обсуждаются в этой статье. Оно будет манипулировать данными о соревнованиях и их участниках, причем, как следует из рисунка 1, в одном старте ( При моделировании этих отношений в реляционной базе данных нам потребовались бы три таблицы - третья должна была бы служить для связывания соревнований и участников по принципу "многое-ко-многим". К счастью, нам этого делать не придется. Вместо этого мы будем использовать Gaelyk в Groovy для отображения этой модели на структуру Bigtable, предоставляемую платформой Google App Engine. Наша задача существенно упрощается благодаря тому, что Gaelyk позволяет работать с сущностями как с ассоциативными таблицами ( Масштабирование и шарды. Одной из привлекательных черт нереляционных моделей данных является то, что вам не требуется продумывать все детали заранее - последующие изменения могут вноситься гораздо проще, чем в реляционную схему. Учтите, я не имею в виду, что реляционную схему изменить нельзя. Это, безусловно, возможно, но задача упрощается при отсутствии схемы. В данный момент времени мы не будем описывать свойства объектов предметной области - о них позаботится динамический язык Groovy (в частности, он позволяет использовать объекты в качестве прокси при работе с Мы начнем с создания базового класса, объекты которого будут хранить экземпляры В листинге 2 показан первый вариант класса Листинг 2. Простой вариант базового класса Model
Обратите внимание на конструктор этого абстрактного класса, в который передается ассоциативный массив ( Если взглянуть на метод Приемы программирования на Groovy Как упоминалось выше, динамическая природа Groovy позволяет обращаться к свойствам, для которых не существует методов В листинге 2 следует отметить несколько моментов, характерных для языка Groovy. Во-первых, метод при обращении к свойству можно не указывать, достаточно лишь добавить Во-вторых, при помощи вызова Наконец, при обращении к свойству Класс
Экземпляр сущности создается в памяти в момент инстанциирования дочернего класса с использованием списка параметров (ассоциативного массива пар типа "ключ-значение"). Для сохранения сущности в базе данных необходимо вызвать метод
В листинге 4 показан грувлет, в котором создается экземпляр Содержимое базы данных можно просматривать при помощи консоли Google App Engine, чтобы убедиться, что данные были успешно сохранены (рисунок 2). Рисунок 2. Просмотр созданного экземпляра RaceПосле сохранения экземпляра Кроме того, мы установим следующее соглашение об именовании поисковых методов: все методы, в названии которых отсутствует слово all , будут возвращать один сохраненный экземпляр. Остальные методы, например
В этом методе используются классы Метод
Как и ранее, этот метод находит экземпляры
Методы в листинге 7 работают в точности так, как ожидается: Реализовав функциональность для создания и поиска экземпляров
Итак, наше приложение практически завершено. Все, что осталось, - это описать связь между соревнованиями и участниками. Разумеется, это будет связь типа "многие-ко-многим", поскольку наши спортсмены должны быть способны участвовать в нескольких соревнованиях. Моделирование информации без схемыАбстракция базы данных Bigtable, предлагаемая Google App Engine, не является объектно-ориентированной: вы не можете сохранять связи, однако можете использовать общие ключи. Соответственно для моделирования отношения между соревнованиями и участниками мы будем сохранять список экземпляров Нам придется добавить немного логики к нашему механизму общих ключей, чтобы API выглядел естественно: в частности, должна быть возможность получения списка именно спортсменов, а не их идентификаторов (ключей). К счастью, в этом нет ничего сложного. В листинге 9 показаны два новых метода класса
Коллекция экземпляров
Метод Последнее, что необходимо сделать - это добавить новый конструктор класса
Как видно из листингов 9, 10 и 11, а также объектной модели, показанной на рисунке 1, вы можете добавлять экземпляры
Таким образом, моделируется связь типа "многие-ко-многим" в базе данных без реляционной схемы. Создание соревнований и участников. Теперь нам осталось только создать экземпляр
После добавления нового При подробном изучении данных в Google App Engine становится понятно, что новый экземпляр сущности Аналогичным образом, свойство После добавления экземпляра Гибкость нереляционных баз данных впечатляет, в частности, тем, что свойства могут автоматически добавляться в БД по необходимости. При этом разработчикам не придется изменять схему, не говоря уже о ее развертывании. Плюсы и минусы NoSQLРазумеется, нереляционные модели данных имеют как преимущества, так и недостатки. Одним из преимуществ, которые были продемонстрированы на примере нашего приложения, является гибкость. Если нам потребуется добавить новое свойство в класс Производительность. С другой стороны, в нашем примере согласованность базы данных явно принесена в жертву эффективности. Текущая модель данных приложения не накладывает никаких ограничений; например, можно создать неограниченное число экземпляров одного и того же объекта. Благодаря автогенерации ключей в Google App Engine все экземпляры будут иметь уникальные ключи, но все остальное будет идентично. Кроме того, не поддерживается возможность каскадного удаления, поэтому если применить тот же подход к хранению отношений типа "один-ко-многим", то возможна ситуация, при которой родительский объект будет удален, а дочерние останутся в базе данных. Разумеется, ничто не мешает вам реализовать собственную схему обеспечения согласованности, но в этом-то и кроется проблема: вам придется делать это самостоятельно (примерно так же, как мы реализовывали остальную функциональность). Таким образом, работа с нереляционными базами данных требует определенной дисциплины. Если начать создавать различные типы соревнований, некоторые с названиями, некоторые без них, одни - со свойством Разумеется, с базами данных в Google App Engine можно работать при помощи JDO и JPA. При этом, имея опыт общения как с реляционными, так и NoSQL-моделями в ряде проектов, я могу сказать, что низкоуровневый API Gaelyk является наиболее гибким и интересным. Еще одним его преимуществом является то, что вы ближе познакомитесь с особенностями Bigtable и общими принципами нереляционных баз данных. ЗаключениеПричудливые новые технологии постоянно появляются и исчезают, и иногда безопаснее их игнорировать (это мой совет как успешного в финансовом смысле человека). Однако NoSQL не выглядит как некая причуда и вполне может стать основой для создания высокомасштабируемых Web-приложений. При этом NoSQL не заменят РСУБД, а скорее, дополнят их. Для реляционных баз данных существуют тысячи библиотек и утилит, поэтому их популярности ничего не угрожает. NoSQL является своевременной альтернативой объектно-реляционной модели данных. Таким образом, было продемонстрировано, что возможно решение, которое лучше себя ведет в некоторых весьма существенных сценариях использования. Базы данных NoSQL наиболее подходят для Web-приложений, которые развернуты на нескольких узлах и которым необходимы высокая масштабируемость и скорость чтения данных. Кроме того, благодаря этим СУБД разработчики осознают подход к моделированию данных, который начинается с описания предметной области, а не проектирования таблиц. Оригинал статьи: Java development 2.0: NoSQL (Эндрю Гловер, developerWorks, май 2010 г.). (EN) Ссылки по теме
|
|