В первой части этой серии мы рассмотрели реляционные базы данных и отличия NoSQL от реляционных баз данных. В этой части мы рассмотрим « хранилище данных Google App Engine », которое является одним из вариантов хранения ваших данных с помощью Google App Engine. Среди других вариантов первым является Google Cloud SQL — реляционная БД в облаке, основанная на MySQL. Второй вариант — Google Cloud Storage, который представляет собой сервис для хранения файлов и объектов размером до терабайт.

Google App Engine Datastore

Datastore — это бесконечно масштабируемое хранилище объектов без схемы, которое находится в вашем распоряжении. Он обрабатывает данные, несколько отличающиеся от СУБД, поэтому он предоставляет решения для многих недостатков СУБД. В то же время он поставляется с собственным набором ограничений и различными способами моделирования и построения уровня доступа к данным вашего приложения. Давайте рассмотрим некоторые функции хранилища данных Google App Engine.

Schemaless

Хранилище данных не требует фиксированной схемы для ваших данных. Это хранилище объектов, вы можете бросать объекты в него, и оно будет хранить их. Давайте поговорим о практическом примере. Допустим, нам нужно хранить информацию о визитной карточке для приложения. Имя, фамилия и адрес электронной почты являются обязательными полями, и есть дополнительные поля, такие как номер мобильного телефона, URL LinkedIn, дескриптор Twitter. Теперь, когда мы храним сущность типа «Бизнес», нам, конечно же, необходимо указать обязательные поля, но необязательные поля могут храниться только тогда, когда они доступны. Таким образом, у одной сущности может быть сохранен хэндл твиттера, а у другой может быть хэндл твиттера и номер мобильного телефона. Давайте посмотрим на JSON-представление объекта, чтобы понять, как выглядит сущность:

Сущность 1

{

  "firstName": "Джон",
 «Фамилия»: «Тейлор»,
 «Электронная почта»: «[email protected]»,
 "twitter_id": "john_t"
 } 

Сущность 2

{

  "firstName": "Том",
 «Фамилия»: «Роджерс»,
 "Электронная почта": "[email protected]",
 "twitter_id": "trogers",
 "mobileNumber": "567 555 1256"
 } 

Давайте сравним, как это будет моделироваться в реляционной БД. Будет создана таблица со столбцами всех обязательных и всех необязательных полей. Для сущностей, которые не имеют никакого значения для необязательного поля, будет заполнен «ноль». Любое новое поле, добавляемое к объекту, будет означать изменение структуры таблицы и заполнение значения этого поля для всех объектов.

Бесконечно масштабируемый

Вы можете хранить столько данных в хранилище данных, сколько пожелаете (оставив на минуту стоимость в ГБ в стороне), ни один из ваших запросов не замедлится. С точки зрения производительности, выборка пяти объектов из 50 ничем не отличается от выборки пяти объектов из 50 миллионов. Время выполнения запроса будет увеличиваться только в зависимости от размера набора результатов, а не от набора данных для сканирования.

Если вы вспомните обсуждение, которое мы провели в первой части этой серии, вы быстро спросите себя, как хранилище данных может автоматически разделяться, а RDBMS — нет. Это удивительное свойство связано с тем, как данные моделируются в хранилище данных. Вместо распределения атрибутов по нескольким отношениям вся информация об одном объекте хранится в одном месте. Затем все объекты упорядочиваются по их уникальному идентификатору. Простой алгоритм теперь может разделять этот список сущностей по их идентификаторам и сохранять полученные фрагменты на отдельных машинах. Тот же алгоритм теперь можно использовать для маршрутизации каждого запроса на соответствующий компьютер.

Сильная последовательность против возможной последовательности

Хранилище данных будет гарантировать только строгую согласованность для операций чтения и «запросов предков», каждый последующий запрос будет в конечном итоге согласованным. Таким образом, существует небольшая вероятность того, что пользователь может не увидеть самую последнюю версию сущности, когда она была совсем недавно обновлена. Это не имеет большого значения для многих вариантов использования («Черт возьми! Этот твит появился только сейчас, когда он был опубликован две секунды назад!»). Есть способы обменивать производительность на сильную согласованность, но я не буду вдаваться в них здесь (возьмем это за отправную точку).

Нарушение идеальной согласованности означает, что нет необходимости немедленно синхронизировать все машины, СУБД придется ждать, пока каждая машина не завершит обновление данных. Хранилище данных также не будет проверять ссылочную целостность, потому что это будет означать необходимость считывания данных с других компьютеров для обеспечения корректного обновления. Еще одним преимуществом возможности горизонтального масштабирования является то, что хранилище данных впечатляюще отказоустойчиво. Многие машины в вашем центре обработки данных могут выйти из строя, и ваши данные, скорее всего, будут обслуживаться без колебаний.

Моделирование ваших данных

В хранилище данных вам нужно будет смоделировать данные на основе запросов, которые вы хотите выполнить в своем приложении. Поскольку все данные для одной сущности должны храниться в одном месте, хранилище данных должно будет создать индекс для каждого запроса, прежде чем такие запросы будут обслуживаться. Это подразумевает, что Ad-Hoc запросы не будут опцией для хранилища данных. App Engine предоставляет (отличные) инструменты, такие как MapReduce, для обработки огромных наборов данных и выполнения аналитических задач, но такие задачи потребуют значительно больше времени для реализации, чем элегантный оператор SQL, к которому вы привыкли.

Выбор между хранилищем данных SQL и NoSQL

Подведем итоги обсуждения

«Хранилище данных предоставляет способ сохранения« тупых »данных, которые приложение превращает в информацию, а СУБД — способ сохранения структурированных данных, которые приложение может использовать напрямую».

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

Давайте рассмотрим некоторые сценарии и варианты использования и попытаемся оценить, является ли СУБД лучшим решением или NoSQL

1. Может ли один сервер обеспечить необходимую нам производительность? Может быть, с помощью кэширования? В этом случае RDBMS — это путь. Посмотрите, например, на Cloud SQL , чисто реляционное предложение AppEngine.
2. Планируете ли вы наращивать мультиприкладную среду, работающую на том же наборе данных? В зависимости от вашего объема, RDBMS может быть тем, что вам нужно, потому что она очень строго отделяет слой базы данных от приложения.
3. Вам нужны специальные запросы? С точки зрения гибкости запросов, SQL является явным победителем.
4. Вам требуется идеальная последовательность? Несмотря на то, что в Datastore есть способы добиться строгой согласованности, это не то, для чего он был разработан. Опять же, RDBMS — лучший выбор.
5. Вы ожидаете миллионы операций чтения и записи в секунду? Datastore обеспечивает автоматическое масштабирование до бесконечности и за ее пределами, и вы сможете использовать его с AppEngine.
6. Вам нужен простой, масштабируемый способ сохранения сущностей с переменными атрибутами? Даже если вам придется самостоятельно обрабатывать согласованность и агрегирование данных, хранилище данных без схемы должно быть именно тем, что вам нужно. И он интегрирован прямо в AppEngine, так что это идеальный выбор для быстрых прототипов с изменяющимися сущностями.

Выбор правильной базы данных — это обширная тема, но с двумя отличными вариантами (CloudSQL и Datastore) вам, по крайней мере, не придется отказываться от App Engine. Я надеюсь, что эта статья облегчила вам решение, и я желаю вам всего наилучшего с любым замечательным приложением, которое вы имеете в виду.

дальнейшее чтение

• SQL против NoSQL — Битва бэкэндов : очень информативная и несколько занимательная презентация на Google I / O 2012
• Отличная документация AppEngine : предоставляет много информации обо всем, что связано с хранилищем данных
• Подробнее о NoSQL — моделирование данных
• Google App Engine: стратегии базы данных

Заключительные слова

Выбор правильного хранилища данных для вашего приложения и понимание NoSQL — обе важные темы. То, что мы рассмотрели в этой серии из двух частей, является лишь верхушкой айсберга. Любые пропущенные упоминания о главном или начинающем игроке в этом пространстве являются чисто случайными. Мы в CloudSpring надеемся, что в ближайшем будущем мы расскажем об этой замечательной теме.