 |
API (application programming interface) - это интерфейс прикладного программирования.
|
|
|
|
Google App Engine — сервис хостинга сайтов и web-приложений на серверах Google с бесплатным именем <имя_сайта>.appspot.com, либо с собственным именем, задействованным с помощью служб Google.
Google App Engine – система разработки облачных приложений от Google, созданная на основе инструментов, которые используются самой Google в инфраструктуре своих приложений. App Engine позволяет разработчикам создавать на языках Python и Java масштабируемые приложения, не задумываясь о низкоуровневой архитектуре.
В то же время, App Engine обладает важными архитектурными ограничениями: создавать приложения можно только на языках Python и Java (также доступны реализации нескольких других языков, которые выполняются поверх Java), вместо традиционной СУБД с SQL-синтаксисом предоставляется СУБД с синтаксисом GQL, где, в частности, не поддерживается оператор JOIN, позволяющий объединять таблицы в базе данных. Доступ к файловой системе возможен в режиме "только для чтения".
Пользоваться Google App Engine можно бесплатно – но только в том случае, если приложение укладывается в заданные Google квоты. Во-первых, для хранения данных выделяется только 1 ГБ дискового пространства. Во-вторых, установлены пределы по суточному объему используемых ресурсов: 1 ГБ входящего и до 1 ГБ исходящего трафика, до 6,5 часов процессорного времени, до 1,3 млн HTTP-запросов, до 10 млн запросов к API базы данных Datastore и до 2000 исходящих электронных писем.
Приложения, разворачиваемые на базе App Engine, должны быть написаны на Python либо Java. Среда исполнения включает в себя полную реализацию возможностей самого Python, большинство функций стандартной библиотеки языка, ограниченную версию Django, и т. д.
Предлагается набор API для сервисов хранилища, datastore API (en), аккаунтов Google, загрузки данных по URL, электронной почты, и т. д.
|
|
|
Предоставлена возможность использовать планировщик задач cron как для приложений реализованных на Python, так и на Java. Разрешено планирование не более 20-ти заданий.
Использование службы аккаунтов Google позволяет быстро начать работу с приложением, нет необходимости проводить отдельную регистрацию учётных данных на каждом сайте. Это также позволяет разработчику не заботиться о реализации ещё одной системы регистрации пользователей специально для своего приложения.
Ограничения
Среда выполнения платформы Google App Engine позволяет разработчику контролировать лишь часть параметров операционной системы, что может представлять проблему для разработки приложений.
Нет доступа на запись в файловую систему сервера. Единственный способ сохранять данные — внутреннее хранилище, нереляционная, высокомасштабируемая база данных. Хранилище отличается от реляционных СУБД MySQL и PostgreSQL, которые используются на большинстве сайтов.
Системы управления сессиями, использующие файловую систему, не будут работать. Google предоставляет альтернативный вариант — Memcache API. Есть возможность организовать авторизацию пользователей через аккаунты Google.
Google широко использует в своих приложениях технологию MapReduce, высокоскоростной интерфейс для параллельных вычислений, проводимых на множестве узлов кластера, её поддержка, вероятно, будет добавлена к возможностям платформы.
20. Облачные технологии. Google App Engine. Хранение данных.
ACID: Атомарность - Чтобы быть "атомарной", транзакция должна быть реализована таким образом, чтобы обеспечить принцип "все или ничего, когда выполняются либо все операции, либо ни одна из них" [88]. Транзакция либо завершается полностью (подтверждается, commit), либо отменяется (откатывается, rollback).
Согласованность - Предполагается, что транзакции выполняют корректные преобразования состояния абстрактной системы - т. е. база данных должна оставаться в согласованном состоянии после завершения транзакции, независимо от того, была ли она подтверждена или отменена. Концепция транзакции предполагает, что программисты имеют механизм, позволяющий им объявлять и проверять правила согласованности. Стандарты SQL для реализации этих механизмов на сервере предоставляют триггеры, ограничения ссылочной целостности и ограничения CHECK.
|
|
|
Изолированность - В то время как транзакция изменяет совместно используемые данные, система должна создать для каждой транзакции иллюзию, что она выполняется изолированно; ей должно казаться, что все другие транзакции выполнялись или до того, как она началась, или после того, как она завершилась. В процессе перехода данных из начального согласованного состояния в конечное согласованное состояние может существовать несогласованное состояние базы данных, но никакие данные не могут быть подвержены изменениям со стороны других транзакций, пока не будут подтверждены изменения данной транзакции.
Устойчивость - Когда транзакция завершается, ее изменения должны быть устойчивыми - т. е. новое состояние всех объектов, видимых другим транзакциям после подтверждения, будет сохранено и будет постоянным, независимо от наличия ошибок в оборудовании или краха программного обеспечения.
Проблемы традиционного подхода:
● один сервер — производительность ограничена аппаратными ресурсами;
● репликация — поддержка согласованности между серверами;
● шардинг (вертикальный и горизонтальный) — управление блокировками и транзакциями.
Согласованность:
● строгая согласованность (Strong consistency);
● «согласованность в конечном счете» (Eventual consistency).
Репликация и шардинг позволяют масштабировать БД, но:
● строгая согласованность реляционных БД замедляет работу;
● операции JOIN являются «дорогими».
Bigtable — масштабируемое, распределённое, высоко доступное (high
available), структурированное хранилище (не поддерживает запросы).
Bigtable предоставляет широкие возможности масштабирования.
Согласованность:
● строгая для строки;
● «согласованность в конечном счете» на уровне множества строк.
Одновременная запись в множество дата-центров (High Replication Datastore).
|
|
|
