Традиционные системы предпринимательства имеют хорошо разработанные схемы и стратегии для реляционных баз данных. Продукты реляционных баз данных хорошо разработаны не только с точки зрения согласованности данных (ACID), но и с точки зрения администрирования баз данных. Базы данных хранятся дома или поставляются компетентному поставщику, у которого есть хорошо разработанный процесс резервного копирования, миграции и безопасности.
В отличие от этого, новые облачные технологии чаще всего используют структуру базы данных без SQL. База данных поддерживается в инфраструктуре облачного провайдера. Администрирование базы данных, особенно процедуры резервного копирования, определены слабо и пока не сформировались и развиваются с течением времени. Если бизнес переходит от традиционной реляционной БД к облачной БД, этот переход может быть довольно сложным, если принять во внимание все эти факторы.
Знание правильных инструментов и знание рисков делает стратегию базы данных для облака выгодной для облачных вычислений. Давайте рассмотрим, какие у нас варианты с GAE сегодня. Мы не будем вдаваться в подробности уровня разработки в этой статье, но должны понять сценарий на высоком уровне.
Стратегия реализации: SQL & NO SQL!
Если вы планируете перевести существующее приложение в GAE, и в вашем приложении есть слои JPA / JDO, задача довольно проста. Интерфейсы JPA / JDO позволяют хранить данные объекта в базе данных без специального кода базы данных. Он работает с базой данных другого типа, что упрощает перенос вашего приложения в хранилище другого типа. Эта стратегия хороша даже для разработки новых приложений, особенно если вы хотите сохранить возможность вернуться к традиционной модели / базе данных на более позднем этапе. В GAE, безусловно, есть некоторые ограничения или «неподдерживаемые функции», такие как «отношения многие-ко-многим» или «объединения в запросах», и вам придется учитывать изменение модели, если это случай перехода из существующего приложения.
Для полного подхода NO-SQL у вас есть больше возможностей. Хотя вы можете использовать хранилище данных Google напрямую с API, предоставленными GAE, вам придется иметь дело с некоторыми вещами, которые могут потребовать дополнительной работы, например, хранилище данных Google работает с сущностями, в то время как ваше приложение может использовать POJO. Кроме того, управление транзакциями с помощью API хранилища данных GAE немного сложнее. Вам также придется иметь дело с нетипизированными ключами и т. Д. Но к нашему спасению, есть несколько фреймворков, которые могут помочь нам, такие как Objectify, twig и slim
Хотя Google анонсировал версию базы данных SQL для работы с механизмом приложений Google, она все еще остается функцией «Лаборатории». Если вы решите перейти на SQL, вам будет проще принять решение на основе существующих моделей предприятия. Вы бы вписались в среду ORM, используя JDO / JPA или аналогичные структуры между базой данных и приложением.
Миграция и резервное копирование
Платформы миграции для Google App Engine до сих пор не достигли желаемого уровня зрелости. Конечно, есть одна возможность — иметь собственные программы, которые могут работать как «Очередь задач» и периодически экспортировать данные в файл, который вы можете импортировать в свою БД. Существуют фреймворки, такие как AppRocket, которые предлагают резервное копирование БД в приложениях на основе Python, и AppScale, которые, среди прочего, реализуют API-интерфейсы GAE и работают как виртуальные машины, предлагая различные задачи.
Но все вышеперечисленные подходы кажутся ненадежными, когда размер базы данных становится действительно большим! И это область пробела, которая требует некоторой работы.
Доступность, последовательность
Движок приложения предлагает хранение в двух вариантах на основе гарантии доступности и согласованности. Хранилище с высокой репликацией обеспечивает более высокую доступность чтения и записи за счет более высокой задержки записи и более высокой стоимости. Данные реплицируются в нескольких центрах обработки данных, но в конечном итоге большинство запросов являются согласованными.
Опция главного подчиненного хранилища данных использует одно главное хранилище и одно подчиненное хранилище данных. Данные реплицируются асинхронно и, следовательно, согласованность гарантируется. Но поскольку используется только одно хранилище данных, доступность может быть «только для чтения» во время проблем в хранилище данных или запланированных простоев. В этом случае вам также необходимо спроектировать приложение, которое будет поддерживать «только для чтения без записи» в хранилище данных.
Последнее слово: производительность
Ни одна тема в базе данных не обходится без разговоров о производительности! Хотя подробное описание работы потребует отдельного обсуждения. Хранилище данных GAE не является традиционной реляционной базой данных и нуждается в приложениях, разработанных по-разному, в разных методах индексации и, что самое важное, в хорошем понимании того, какой тип магазина вы выбираете.
Например, все сущности, обновляемые в одной транзакции в главном-подчиненном хранилище, должны принадлежать к одной и той же группе сущностей, хотя это не требуется для хранилища данных с высокой репликацией. Проект приложения должен быть хорошо продуман с другой точки зрения хранилища данных, чтобы использовать масштаб и инфраструктуру!
Итачи Учиха изображения с Shutterstock