Друга хвиля розробки Java-додатків: Бази даних типу NoSQL

1. Серія контенту:
2. Цей контент є частиною серії: Друга хвиля розробки Java-додатків
3. Про цю серії
4. NoSQL: Чи потрібен новий погляд на світ?
5. Масштабованість у них в крові
6. Сутності та зв'язку
7. Лістинг 1. Збереження об'єкта в базі даних за допомогою Entity
8. Комерційні споруди
9. змагання
10. Малюнок 1. Змагання і їх учасники
11. Масштабування і Шардена
12. Базовий клас Model
13. Лістинг 2. Простий варіант базового класу Model
14. Прийоми програмування на Groovy
15. Дочірній клас Race
16. Лістинг 3. Дочірній клас Race
17. Лістинг 4. Створення примірника Race і збереження його в базі даних Google App Engine
18. Малюнок 2. Перегляд створеного екземпляра Race
19. Лістинг 5. Простий пошуковий метод для знаходження об'єкта за значенням властивості name
20. Лістинг 6. Пошук всіх об'єктів по імені
21. Лістинг 7. Приклад використання пошукових методів
22. об'єкти Runner
23. Лістинг 8. Клас Runner дуже простий
24. Моделювання інформації без схеми
25. Лістінг 9. Додавання и відалення екземплярів Runner
26. Лістинг 10. Створення об'єкта Entity за його ідентифікатором
27. Лістинг 11. Новий конструктор
28. Лістинг 12. Спортсмени та їх змагання
29. Створення змагань і учасників
30. Лістинг 13. Учасники та змагання
31. Малюнок 3. Перегляд властивості runners змагання
32. Малюнок 4. Перегляд нового списку учасників
33. Малюнок 5. Учасник без змагань
34. Малюнок 6. Спортсмен і його змагання
35. Плюси і мінуси NoSQL
36. продуктивність
37. Висновок
38. Ресурси для скачування

Друга хвиля розробки Java-додатків

Управління даними без реляційних схем за допомогою Bigtable і бібліотеки Gaelyk в Groovy

Серія контенту:

Цей контент є частиною # з серії # статей: Друга хвиля розробки Java-додатків

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Вторая+волна+разработки+java-приложений

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Друга хвиля розробки Java-додатків

Слідкуйте за виходом нових статей цієї серії.

Реляційні СУБД займають лідируючі позиції вже більше 30 років, однак ця ситуація може змінитися у зв'язку зі зростаючою популярністю баз даних, які не мають реляційних схем даних (або баз даних типу NoSQL). РСУБД надають надійні засоби зберігання даних в системах з традиційною клієнт-серверної архітектурою, які, на жаль, не завжди легко і дешево масштабируются шляхом додавання нових обчислювальних вузлів. Це стає вельми серйозним обмеженням в епоху таких Web-додатків, як Facebook і Twitter, яким хороша масштабованість вкрай необхідна.

Про цю серії

Характерні риси розробки на Java істотно змінилися з моменту виходу першого релізу платформи. Завдяки зрілості відкритих інфраструктур та оренди надійних середовищ розгортання, є можливість збирати, тестувати і підтримувати Java-додатка без серйозних тимчасових і грошових витрат. В цій серії Ендрю Гловер описує ряд технологій, що лежать в основі нової парадигми створення додатків на Java.

Проблему масштабованості не вдалося вирішити раннім альтернативам реляційних СУБД (пам'ятаєте об'єктно-орієнтовані бази даних?). На відміну від них СУБД NoSQL, подібні Bigtable і SimpleDB (від Google і Amazon відповідно), проектувалися саме в розрахунку на високу масштабованість Web-додатків. NoSQL цілком можуть виявитися рішенням критично важливої ​​проблеми масштабованості, яка буде ставати все більш актуальною в міру розвитку Web 2.0.

У цій статті серії Друга хвиля розробки Java-додатків наводиться введення в проектування баз даних без використання схем, що представляє собою одну з головних труднощів при переході на NoSQL для розробників, які раніше працювали з реляційними СУБД. Ви побачите, що найголовніше в цьому процесі - почати проектування зі створення моделі предметної області, а не реляційної моделі. При роботі з Bigtable (як в прикладах нижче) ви можете розраховувати на допомогу Gaelyk - легковагій інфраструктури, яка розширює можливості платформи Google App Engine.

NoSQL: Чи потрібен новий погляд на світ?

Розмірковуючи про нереляційних базах даних, багато розробників в першу чергу згадують про необхідність зміни свого світогляду. Однак, на мій погляд, це залежить від їхнього улюбленого підходу до створення моделей даних. Якщо ви звикли починати розробку програми зі створення структури бази даних, зокрема з опису таблиць і зв'язків між ними, то проектування нереляційних сховища даних, наприклад на основі Bigtable, зажадає від вас зміни вашого підходу в цілому. Якщо ж ви зазвичай починаєте створення додатків з моделювання предметної області, то нереляційних структура Bigtable повинна виглядати більш природно.

Масштабованість у них в крові

Проблеми, пов'язані з потребами високомасштабіруемих Web-додатків, привели до появи нових рішень. Зокрема, Facebook не може покладатися на реляційну БД для зберігання інформації. Замість цього в ній використовується сховище пар типу "ключ-значення", тобто фактично - високопродуктивна хеш-таблиця. Створене на її основі рішення (проект Cassandra) в даний час також використовується сервісами Twitter і Digg, а недавно було передано організації Apache Software Foundation. Іншим прикладом компанії, чий зріст вимагав альтернативних підходів до зберігання даних, є Google, в якому була створена технологія Bigtable.

У нереляційних базах даних не використовується з'єднання таблиць, первинні або вторинні ключі (ключі присутні, але в менш суворому вигляді). Таким чином, ви будете сильно розчаровані, спробувавши застосувати реляционное моделювання при створенні моделі даних для бази даних NoSQL. Набагато простіше почати з опису предметної області. При цьому особисто мені приносить задоволення гнучкість нереляційних структури БД, що лежить в основі моделі предметної області.

Таким чином, складність переходу на нереляційних модель даних залежить від вашого підходу до проектування додатків, а саме: починаєте ви з реляційної схеми або опису предметної області. Почавши використовувати СУБД, подібну CouchDB або Bigtable, вам доведеться розпрощатися зі зручними інфраструктурами зберігання даних, наприклад Hibernate. C іншого боку, перед вами відкриються широкі можливості для самостійного створення такої технології для своїх потреб. А в процесі її створення ви познайомитеся з тонкощами баз даних NoSQL.

Сутності та зв'язку

Нереляційні СУБД дозволяють проектувати модель предметної області у вигляді набору об'єктів, причому ця можливість спрощується такими сучасними рішеннями, як Gaelyk. На наступному етапі вам належить відобразити створену модель на структуру бази даних, що в разі використання Google App Engine не представляє ніяких труднощів.

Раніше, в статті Інфраструктура Gaelyk в додатках для Google App Engine , Ви познайомилися з Gaelyk - Groovy-бібліотекою, яка спрощує роботу зі сховищем даних Google. У цій статті чимало уваги буде приділятися об'єкту Entity в Google. У лістингу 1 наведено приклад з попередньої статті, що демонструє роботу з сутностями (entity) в Gaelyk.

Лістинг 1. Збереження об'єкта в базі даних за допомогою Entity

def ticket = new Entity ( "ticket") ticket.officer = params.officer ticket.license = params.plate ticket.issuseDate = offensedate ticket.location = params.location ticket.notes = params.notes ticket.offense = params.offense

Комерційні споруди

Перевага об'єктної, а не реляційної моделі при проектуванні бази даних простежується в сучасних інфраструктурах додатків, таких як Grails і Ruby on Rails. Ці платформи приділяють підвищену увагу саме створення моделі, беручи на себе генерацію фізичної схеми бази даних.

Подібний підхід до збереження даних цілком прийнятний, однак легко помітити, що він стає трудомістким при інтенсивній роботі з квитками, наприклад, якщо їх доводиться створювати або шукати в різних сервлетах. Частково це завдання можна полегшити за допомогою загального сервлету (або грувлета), але є більш логічне рішення - створення об'єкта Ticket. Воно буде розглянуто нижче.

змагання

Замість того щоб повернутися до прикладу з повідомленнями з першої статті про Gaelyk, ми розглянемо новий додаток, що ілюструє методи, які обговорюються в цій статті. Воно буде маніпулювати даними про змагання та їх учасників, причому, як випливає з малюнка 1, в одному старті (Race) беруть участь кілька спортсменів (Runner), а один спортсмен може бути учасником багатьох стартів.

Малюнок 1. Змагання і їх учасники

При моделюванні цих відносин в реляційної базі даних нам потрібні були б три таблиці - третя мала б служити для зв'язування змагань і учасників за принципом "багато-до-багатьох". На щастя, нам цього робити не доведеться. Замість цього ми будемо використовувати Gaelyk в Groovy для відображення цієї моделі на структуру Bigtable, що надається платформою Google App Engine. Наше завдання істотно спрощується завдяки тому, що Gaelyk дозволяє працювати з сутностями як з асоціативними таблицями (Map).

Масштабування і Шардена

Шардінг - це варіант декомпозиції бази даних, при якому відбувається реплікація таблиць і логічні розподіл інформації по обчислювальним вузлам. Наприклад, на одному вузлі можуть зберігатися дані про всі облікові записи користувачів в США, а на іншому - жителів Європи. Складнощі шардінга обумовлені наявністю зв'язків між даними, розміщеними на різних вузлах. Це серйозна і складна проблема, яка в ряді випадків не вирішується (в розділі ресурси наведено посилання на мою дискусію з Максом Россом з Google (Max Ross) на тему шардінга і складнощів масштабованості реляційних баз даних).

Однією з привабливих рис нереляційних моделей даних є те, що вам не потрібно продумувати всі деталі заздалегідь - наступні зміни можуть вноситися набагато простіше, ніж в реляційну схему. Врахуйте, я не маю на увазі, що реляционную схему змінити не можна. Це, безумовно, можливо, але завдання спрощується при відсутності схеми. В даний момент часу ми не будемо описувати властивості об'єктів предметної області - про них подбає динамічний мову Groovy (зокрема, він дозволяє використовувати об'єкти в якості проксі при роботі з Entity). Замість цього ми розглянемо сценарії пошуку об'єктів в базі даних і зв'язку між ними. В даний час СУБД NoSQL і різні інфраструктури не надають вбудованих можливостей для реалізації подібної функціональності.

Базовий клас Model

Ми почнемо з створення базового класу, об'єкти якого будуть зберігати екземпляри Entity. Його дочірні класи повинні мати динамічний набір властивостей, які будуть додаватися до відповідного екземпляр Entity за допомогою зручного методу setProperty в Groovy. Цей метод викликається при встановленні значення кожної властивості, для якого немає set-методу (це може здатися дивним, але не турбуйтеся - скоро все стане на свої місця).

У лістингу 2 показаний перший варіант класу Model демонстраційного додатки.

Лістинг 2. Простий варіант базового класу Model

package com.b50.nosql import com.google.appengine.api.datastore.DatastoreServiceFactory import com.google.appengine.api.datastore.Entity abstract class Model {def entity static def datastore = DatastoreServiceFactory.datastoreService public Model () {super ( )} public Model (params) {this. @ entity = new Entity (this.getClass (). simpleName) params.each {key, val -> this.setProperty key, val}} def getProperty (String name) {if ( name.equals ( "id")) {return entity.key.id} else {return entity. "$ {name}"}} void setProperty (String name, value) {entity. "$ {name}" = value} def save () {this.entity.save ()}}

Зверніть увагу на конструктор цього абстрактного класу, в який передається асоціативний масив (Map) властивостей. Завжди можна додати додаткові конструктори, що ми і зробимо нижче. Подібний підхід досить зручний для різних інфраструктур Web-додатків, яким часто доводиться працювати з параметрами, отриманими через Web-форми. Gaelyk і Grails елегантно представляють такі параметри у вигляді об'єкта під ім'ям params. Конструктор перебирає елементи Map і викликає метод setProperty для кожної пари типу "ключ-значення".

Якщо поглянути на метод setProperty, то стає ясно, що ключем є ім'я властивості entity, а значенням - значення даного властивості.

Прийоми програмування на Groovy

Як згадувалося вище, динамічна природа Groovy дозволяє звертатися до властивостей, для яких не існує методів get і set. Таким чином, дочірнім класами Model не обов'язково оголошувати власні методи властивостей - вони можуть делегувати всі звернення до властивостей об'єкту entity.

У лістингу 2 слід зазначити кілька моментів, характерних для мови Groovy. По-перше, метод при зверненні до властивості можна не вказувати, досить лише додати @ перед іменем властивості. Це робиться при створенні об'єкта entity в конструкторі, оскільки інакше довелося б викликати метод setProperty, що на даному етапі, зрозуміло, неможливо, оскільки змінна entity в цей момент дорівнює null.

По-друге, за допомогою виклику this.getClass (). SimpleName конструктор задає "тип" сутності. Значенням властивості simpleName є ім'я конкретного дочірнього класу без префікса пакета (при зверненні до simpleName фактично викликається метод getSimpleName, оскільки Groovy дозволяє звертатися до властивостей без явної вказівки get-методу класу JavaBean).

Нарешті, при зверненні до властивості id викликається метод getProperty. При роботі з платформою Google App Engine ключі сутностей генеруються автоматично.

Дочірній клас Race

Клас Race, успадкований від Model, дуже простий (лістинг 3).

Лістинг 3. Дочірній клас Race

package com.b50.nosql class Race extends Model {public Race (params) {super (params)}}

Примірник сутності створюється в пам'яті в момент інстанціірованія дочірнього класу з використанням списку параметрів (асоціативного масиву пар типу "ключ-значення"). Для збереження суті в базі даних необхідно викликати метод save.

Лістинг 4. Створення примірника Race і збереження його в базі даних Google App Engine

import com.b50.nosql.Runner def iparams = [:] def formatter = new SimpleDateFormat ( "MM / dd / yyyy") def rdate = formatter.parse ( "04/17/2010") iparams [ "name"] = "Charlottesville Marathon" iparams [ "date"] = rdate iparams [ "distance"] = 26.2 as double def race = new Race (iparams) race.save ()

У лістингу 4 показаний грувлет, в якому створюється екземпляр Map (змінна iparams), що містить значення трьох властивостей - name, date і distance. Зверніть увагу, що в Groovy порожній Map инициализируется за допомогою конструкції [:]. Після створення новий екземпляр Race зберігається в базі даних за допомогою методу save.

Вміст бази даних можна переглядати за допомогою консолі Google App Engine, щоб переконатися, що дані були успішно збережені (малюнок 2).

Малюнок 2. Перегляд створеного екземпляра Race

Пошук збережених об'єктів

Після збереження примірника Entity було б корисно мати можливість вибірки його з бази даних. Для цього служать пошукові методи. В даному випадку ми додамо статичний метод, який буде шукати екземпляри Race за назвою (тобто по властивості name). Інші пошукові методи завжди можна буде додати пізніше.

Крім того, ми встановимо таку конвенцію про іменування пошукових методів: всі методи, в назві яких відсутнє слово all, повертатимуть один збережений екземпляр. Решта методи, наприклад findAllByName, можуть повертати Collection або List примірників. Код методу findByName приведений в лістингу 5.

Лістинг 5. Простий пошуковий метод для знаходження об'єкта за значенням властивості name

static def findByName (name) {def query = new Query (Race.class.simpleName) query.addFilter ( "name", Query.FilterOperator.EQUAL, name) def preparedQuery = this.datastore.prepare (query) if (preparedQuery. countEntities ()> 1) {return new Race (preparedQuery.asList (withLimit (1)) [0])} else {return new Race (preparedQuery.asSingleEntity ())}}

У цьому методі використовуються класи Query і PreparedQuery для пошуку сутності типу "Race", що має вказане властивість name. Якщо таких сутностей кілька, метод поверне тільки перше з них, оскільки вказана конструкція withLimit (1), що обмежує число результатів.

Метод findAllByName виглядає дуже схоже, але йому потрібен додатковий параметр, який вказує число необхідних результатів (лістинг 6).

Лістинг 6. Пошук всіх об'єктів по імені

static def findAllByName (name, pagination = 10) {def query = new Query (Race.class.getSimpleName ()) query.addFilter ( "name", Query.FilterOperator.EQUAL, name) def preparedQuery = this.datastore.prepare ( query) def entities = preparedQuery.asList (withLimit (pagination as int)) return entities.collect {new Race (it as Entity)}}

Як і раніше, цей метод знаходить екземпляри Race по властивості name, проте повертає всі екземпляри, що задовольняють умові. Зверніть увагу, наскільки зручний метод collect в Groovy: з його допомогою можна позбутися від циклу створення екземплярів Race на основі знайдених об'єктів Entity. Крім того, врахуйте, що Groovy дозволяє використовувати значення за замовчуванням при виклику методів, тому якщо не передати другий параметр, то пошук буде обмежений 10 результатами.

Лістинг 7. Приклад використання пошукових методів

def nrace = Race.findByName ( "Charlottesville Marathon") assert nrace.distance == 26.2 def races = Race.findAllByName ( "Charlottesville Marathon") assert races.class == ArrayList.class

методи в лістингу 7 працюють в точності так, як очікується: findByName повертає один екземпляр, а findAllByName - набір примірників (якщо, звичайно, в базі даних є декілька змагань з назвою "Charlottesville Marathon").

об'єкти Runner

Реалізувавши функціональність для створення і пошуку примірників Race, можна переходити до класу Runner. Він створюється так само просто, як і Race: досить успадкувати клас від Model, як показано в лістингу 8.

Лістинг 8. Клас Runner дуже простий

package com.b50.nosql class Runner extends Model {public Runner (params) {super (params)}}

Отже, наше додаток практично завершено. Все, що залишилося, - це описати зв'язок між змаганнями і учасниками. Зрозуміло, це буде зв'язок типу "багато-до-багатьох", оскільки наші спортсмени повинні бути здатні брати участь в декількох змаганнях.

Моделювання інформації без схеми

Абстракція бази даних Bigtable, пропонована Google App Engine, не є об'єктно-орієнтованої: ви не можете зберігати зв'язку, проте можете використовувати загальні ключі. Відповідно для моделювання відносини між змаганнями і учасниками ми будемо зберігати список примірників Runner всередині кожного примірника Race і навпаки.

Нам доведеться додати трохи логіки до нашого механізму загальних ключів, щоб API виглядав природно: зокрема, повинна бути можливість отримання списку саме спортсменів, а не їх ідентифікаторів (ключів). На щастя, в цьому немає нічого складного.

У лістингу 9 показані два нових методи класу Race. При передачі примірника Runner в метод addRunner його ідентифікатор (id) додається в колекцію runners об'єкта entity. Якщо ця колекція вже існує, то новий ключ додається в кінець; в іншому випадку створюється новий об'єкт Collection, після чого ключ додається в нього.

Лістінг 9. Додавання и відалення екземплярів Runner

def addRunner (runner) {if (this. @ entity.runners) {this. @ Entity.runners << runner.id} else {this. @ Entity.runners = [runner.id]}} def getRunners () {return this. @ Entity.runners.collect {new Runner (this.getEntity (Runner.class.simpleName, it))}}

Колекція примірників Runner створюється на основі збереженої в базі даних колекції ідентифікаторів в момент виклику методу getRunners (див. Лістинг 9). Для цього потрібен новий метод getEntity в класі Model. Його код приведений в лістингу 10.

Лістинг 10. Створення об'єкта Entity за його ідентифікатором

def getEntity (entityType, id) {def key = KeyFactory.createKey (entityType, id) return this. @ datastore.get (key)}

Метод getEntity використовує клас KeyFactory для генерації ключів, які потім можуть застосовуватися для пошуку примірників сутностей в базі даних.

Останнє, що необхідно зробити - це додати новий конструктор класу Model, який бере на вхід екземпляр сутності будь-якого типу (лістинг 11).

Лістинг 11. Новий конструктор

public Model (Entity entity) {this. @ entity = entity}

Як видно з лістингів 9 , 10 и 11 , А також об'єктної моделі, показаної на малюнку 1 , Ви можете додавати екземпляри Runner в будь-який об'єкт Race і запитувати список примірників Runner у об'єктів Race. Аналогічні методи можна також додати в клас Runner, як показано в лістингу 12.

Лістинг 12. Спортсмени та їх змагання

def addRace (race) {if (this. @ entity.races) {this. @ entity.races << race.id} else {this. @ entity.races = [race.id]}} def getRaces () {return this. @ entity.races.collect {new Race (this.getEntity (Race.class.simpleName, it))}}

Таким чином, моделюється зв'язок типу "багато-до-багатьох" в базі даних без реляційної схеми.

Створення змагань і учасників

Тепер нам залишилося тільки створити екземпляр Runner і додати його в Race. Якщо ви хочете, щоб зв'язок був двобічної (див. малюнок 1 ), То можете також додати екземпляри Race в об'єкти Runner, як показано в лістингу 13.

Лістинг 13. Учасники та змагання

def runner = new Runner ([fname: "Chris", lname: "Smith", date: 34]) runner.save () race.addRunner (runner) race.save () runner.addRace (race) runner.save ( )

Після додавання нового Runner в змагання і виклику методу Race.save в базі даних повинен бути збережений список ідентифікаторів, показаний на малюнку 3.

Малюнок 3. Перегляд властивості runners змагання

При детальному вивченні даних в Google App Engine стає зрозуміло, що новий екземпляр сутності Race містить список примірників типу Runner (рисунок 4).

Малюнок 4. Перегляд нового списку учасників

Аналогічним чином, властивість races не існує до моменту додавання нового змагання в щойно створений екземпляр Runner. Приклад показаний на малюнку 5.

Малюнок 5. Учасник без змагань

Після додавання примірника Race в об'єкт Runner база даних буде зберігати список ідентифікаторів змагань, в яких бере участь цей спортсмен (рисунок 6).

Малюнок 6. Спортсмен і його змагання

Гнучкість нереляційних баз даних вражає, зокрема, тим, що властивості можуть автоматично додаватися в БД за потребою. При цьому розробникам не доведеться змінювати схему, не кажучи вже про її розгортанні.

Плюси і мінуси NoSQL

Зрозуміло, нереляційні моделі даних мають як переваги, так і недоліки. Одним з переваг, які були продемонстровані на прикладі нашого застосування, є гнучкість. Якщо нам буде потрібно додати нову властивість в клас Runner, наприклад номер соціального страхування (SSN), то це не зажадає серйозних зусиль. Досить буде просто включити його в список параметрів конструктора. При цьому нічого страшного не станеться з раніше створеними об'єктами, просто їх властивість (SSN) буде містити null.

продуктивність

Швидкість виконання операцій дуже важлива при порівнянні РСУБД і NoSQL. Для сучасних Web-сайтів, які маніпулюють даними мільйонів користувачів (в Facebook зараз близько 400 млн користувачів і їх число постійно збільшується) реляційна модель виявляється занадто повільної і дорогий. У свою чергу, читання даних в СУБД NoSQL виконується неймовірно швидко.

З іншого боку, в нашому прикладі узгодженість бази даних явно принесена в жертву ефективності. Поточна модель даних програми не накладає ніяких обмежень; наприклад, можна створити необмежену кількість примірників одного і того ж об'єкта. Завдяки автогенерации ключів в Google App Engine всі екземпляри матимуть унікальні ключі, але все інше буде ідентично. Крім того, не підтримується можливість каскадного видалення, тому якщо застосувати той же підхід до зберігання відносин типу "один-ко-многим", то можлива ситуація, при якій батьківський об'єкт буде видалений, а дочірні залишаться в базі даних. Зрозуміло, ніщо не заважає вам реалізувати власну схему забезпечення узгодженості, але в цьому-то і криється проблема: вам доведеться робити це самостійно (приблизно так само, як ми реалізовували іншу функціональність).

Таким чином, робота з нереляціоннимі базами даних вимагає певної дисципліни. Якщо почати створювати різні типи змагань, деякі з назвами, деякі без них, одні - з властивістю date, інші - c race_date, то це призведе до головного болю і для вас самих, і для інших розробників, які будуть використовувати ваш код.

Зрозуміло, з базами даних в Google App Engine можна працювати за допомогою JDO і JPA. При цьому, маючи досвід спілкування як з реляційними, так і NoSQL-моделями в ряді проектів, я можу сказати, що низькорівневий API Gaelyk є найбільш гнучким і цікавим. Ще одним його перевагою є те, що ви ближче познайомитеся з особливостями Bigtable і загальними принципами нереляційних баз даних.

Висновок

Химерні нові технології постійно з'являються і зникають, і іноді безпечніше їх ігнорувати (це моя порада як успішного в фінансовому сенсі людини). Однак NoSQL не виглядає як якась примха і цілком може стати основою для створення високомасштабіруемих Web-додатків. При цьому NoSQL не замінять РСУБД, а скоріше, доповнять їх. Для реляційних баз даних існують тисячі бібліотек і утиліт, тому їх популярності нічого не загрожує.

NoSQL є своєчасною альтернативою об'єктно-реляційної моделі даних. Таким чином, було продемонстровано, що можливо рішення, яке краще себе веде в деяких дуже істотних сценаріях використання. Бази даних NoSQL найбільш підходять для Web-додатків, які розгорнуті на декількох вузлах і яким необхідні висока масштабованість і швидкість читання даних. Крім того, завдяки цим СУБД розробники усвідомлюють підхід до моделювання даних, який починається з опису предметної області, а не проектування таблиць.

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

Схожі тими

• Оригінал статті: Java development 2.0: NoSQL (Ендрю Гловер, developerWorks, травень 2010 р.) (EN)
• У серії статей Друга хвиля розробки Java-додатків розглядаються технології та інструменти, що змінюють принципи створення додатків на Java, в тому числі Gaelyk (Грудень 2009 року), Google App Engine (Серпень 2009 р) і CouchDB (Листопад 2009 року).
• прочитайте статтю шаблони NoSQL (Ріккі Хо, Ricky Ho, Pragmatic Programming Techniques, листопад 2009 року), в якій наводиться огляд і перелік СУБД NoSQL, а також докладний розгляд їх загальних архітектурних принципів. (EN)
• у статті Saying Yes to NoSQL; Going Steady with Cassandra (Джон Куїнн, John Quinn, Digg Blogs, березень 2010 року) віце-президент Digg пояснює мотиви, за якими було вирішено перейти з MySQL на Cassandra. (EN)
• Шардінг з Максом Россом (Трансляція JavaWorld, июль 2008 г.): Ендрю Гловер обговорює з Максом Россом з Google технологію шардінга, а також проект Hibernate Shards. (EN)
• прочитайте статтю Приречені чи реляційні бази даних? (Тоні Бейн, Tony Bain, ReadWriteEnterprise, лютий 2009 р). В даний час нереляційні СУБД набирають популярність як в традиційних, так і хмарних додатках. Стає ясно, що "якщо вам потрібна висока масштабованість на вимогу, то слід зробити вибір на користь нереляційних СУБД". (EN)
• Ознайомтеся зі статтею Bigtable - розподілене сховище структурованих даних (Фей Чен і інші, Fay Chang et al., Google, листопад 2006 року), в якій розглядається Bigtable - база даних, яка проектувалася з урахуванням необхідності високої масштабованості (до петабайт даних, розподілених по різних серверах). (EN)
• у статті В'єтнамська війна в інформатиці (Тед Ньюворд, Ted Neward, червень 2006 року) розглядаються шляхи вирішення проблем, пов'язаних з відображенням об'єктів на реляційні моделі. (EN)
• Gaelyk : Познайомтеся з легковажною інфраструктурою створення додатків на Groovy для платформи Google App Engine. (EN)

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів