![]() | |||||||||||||
Вторая волна разработки 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) |