Хранение данных в Google App Engine

За основу данной статьи взята запись в блоге Ника Джонсона (Nick Johnson). В дополнение к ней приведено немного цифр, актуальных на данный момент и добавлены некоторые заметки.

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

Хранилище данных (datastore)

Самое известное, используемое и гибкое хранилище данных. Datastore — это нереляционная база данных App Engine, она предоставляет надёжное долговременное хранилище, а также обеспечивает максимальную гибкость в хранении, получении и обработке данных.

• Достоинства:
  
  • Надёжно — данные сохраняются всерьёз и надолго.
  • Чтение и запись — приложения могут как считывать, так и записывать данные в datastore. Также, datastore обеспечивает механизм транзакций для обеспечения целостности.
  • Согласованно — вид хранилища одинаков для всех инстансов приложения.
  • Гибко — запросы (queries) и индексирование обеспечивают много способов запроса и получения данных
• Недостатки:
  • Скорость — так как datastore хранит данные на диске и обеспечивает гарантированную надёжность, процесс записи требует ожидания подтверждения того, что данные сохранены, а процесс чтения вынужден брать данные с диска.
• Как и где использовать:
  
  Специально обученное описание datastore находится здесь.
  Использовать datastore следует везде, где необходимо надёжно сохранить данные, в будущем используемые приложением.
  
  
• Где лучше не использовать:
  
  Зачастую разработчики пишут в базу отладочную и техническую информацию, необходимую только им. Для таких случаев гораздо лучше подходят встроенные логи App Engine, речь о них пойдёт ниже.
  

Memcache

Memcache известен как механизм «вторичного» хранения данных. API memcache предоставляет приложениям возможность оптимистично кэшировать данные во избежание дорогостоящих операций. Memcache часто используется в качестве уровня кэширования для других API, таких как datastore, или для кэширования результатов любых вычислений.

• Достоинства:
  • Быстро — время доступа к memcache обычно составляет несколько миллисекунд
  • Согласованно — вид хранилища одинаков для всех инстансов приложения. Кроме того, memcache обеспечивает атомные операции, так что приложения могут гарантировать целостность хранимых в нём данных.
• Недостатки:
  • Ненадёжно — данные могут быть удалены из memcache в любой момент.
  • Не всегда доступно — в периоды обслуживания App Engine memcache недоступен.
• Как и где использовать:
  
  В качестве кэша datastore, urlfetch или результатов вычислений.
  
  
• Где лучше не использовать:
  
  Для хранения важных данных, не стоит забывать, что из memcache они могут пропасть в любой момент.

Память инстанса

Инстансы приложения тоже могут кэшировать данные с помощью использования глобальных переменных или членов класса. Этот способ обеспечивает наивысшую скорость, но обладает некоторыми недостатками.

• Достоинства:
  • Быстро — буквально, настолько быстро, насколько это возможно, так как данные хранятся в том же процессе, что их запрашивает.
  • Удобно — нет необходимости в API, данные просто хранятся в глобальных переменных или в членах класса.
  • Гибко — данные могут храниться в любом формате, в котором Ваша программа может их обрабатывать. Нет необходимости в их сериализации/десериализации.
• Недостатки:
  • Ненадёжно — инстансы могут запуститься или остановиться в любой момент, поэтому приложениям следует использовать память инстанса только в качестве кэша.
  • Несогласованно — у каждого инстанса своё окружение среды и, следовательно, свои глобальные переменные. Изменения в одном инстансе не отразятся в других инстансах.
  • Ограниченная вместимость — у инстансов есть ограничение потребляемой памяти, после превышения которого они уничтожаются. Предельный объём для данных в памяти инстанса около 50Мб — при использовании большего объёма инстансы будут уничтожаться очень часто.
• Как и где использовать:
  
  Для кэширования часто используемых и редко изменяемых данных — информации о сессиях, настроек приложения, гостевых страниц и т.д. Особенно удобно использование памяти инстанса в переменных dict — можно создать своеобразные хранилища «ключ-данные» для различных видов данных.
  
  
• Где лучше не использовать:
  
  Для кэширования часто изменяемых данных или данных, с которыми взаимодействует пользователь. Разные запросы одного пользователя могут обрабатываться разными инстансами и кэширование в таком случае внесёт существенную путаницу.
  

Blobstore

Хранилище BLOB-ов позволяет легко и эффективно хранить и отдавать большие объёмы данных, загруженных пользователем.

• Достоинства:
  • Поддерживает большие файлы — до 2-х Гб на blob.
  • Избавляет от необходимости написания обработчиков.
  • Предоставляет механизм для высокопроизводительного обслуживания blob-ов, особенно изображений.
  • Приложения могут читать содержимое blob-ов как если бы это были локальные файлы.
• Недостатки:
  • Только чтение — приложение не может создавать blob-ы или изменять уже загруженные. 30 марта 2011 в App Engine появился Files API — теперь данные в blobstore можно изменять.
  • Для использования blobstore необходимо включить биллинг.
• Как и где использовать:
  
  Для хранения пользовательских изображений, файлов и прочих больших объектов.
  
  
• Где лучше не использовать:
  
  Для небольших файлов, с которыми планируется взаимодействие приложения лучше подходит BlobProperty в datastore.
  

Локальные файлы

Приложение может читать любые файлы, загруженные с приложением и не отмеченные как статический контент, используя стандартные операции файловой системы. Так добавляются данные только для чтения, которые могут понадобиться приложению.

• Достоинства:
  • Быстро — чтение локальных файлов задействует только стандартные дисковые операции на той машине, на которой запущен инстанс приложения, так что скорость почти такая же, как у memcache.
  • Надёжно — если приложение работает, то локальные файлы всегда доступны.
  • Гибко — можно использовать любой формат или механизм доступа к локальным файлам.
• Недостатки:
  • Только чтение — приложения не могут модифицировать файлы.
  • Ограниченный размер — ограничения составляют 10Мб на файл и 150Мб на приложение.
• Как и где использовать:
  
  Хранение настроек приложения, шаблонов и т.д.
  
  
• Где лучше не использовать:
  
  Противопоказаний не замечено
  

Нагрузка очереди задач (Task queue payloads)

Это не хранилище в его традиционном понимании, к задачам из taskqueue могут прикрепляться данные, которые могут устранить необходимость использования других систем хранения.

• Достоинства:
  • Быстро — данные отправляются задаче тогда, когда она запускается, так что для получения данных не требуется дополнительных вызовов API.
  • При правильном использовании позволяет избежать необходимости хранения данных где-то ещё.
• Недостатки:
  • Только для одной задачи — нагрузка полезна только как хранилище для данных, отправляемых задаче taskqueue
  • Ограниченный размер — размер задач, включая нагрузку, не должен превышать 10Кб
• Как и где использовать:
  
  Фоновая обработка данных, отправка почты, обновление кэша — любые работы, перенесение которых в фоновое исполнение позволит ускорить оптравку ответа пользователю и не влияет на полученный пользователем ответ сервера.
  
  
• Где лучше не использовать:
  
  Обработка более 10Кб данных потребует использования других способов хранения. Также следует не забывать, что в некоторых случаях задачи из taskqueue могут выполняться с существенной задержкой.
  

Электронная почта

В App Engine электронную почту можно использовать не только для общения с пользователями, но и в технических целях. В данном случае способ передачи данных похож на использование taskqueue payload, однако использование электронной почты предоставляет больше возможностей, например, передача данных другому приложению App Engine.

• Достоинства:
  • Гибко — можно отправлять большие объёмы с помощью отправки «обычной» почты или отправлять «админскую» почту, не затрагивая почтовые квоты.
  • Удобно — письмо с данными приходит как POST-запрос, для удобства обработки которого имеется стандарнтый InboundMailHandler.
  • Возможность обмена данными между приложениями.
• Недостатки:
  • Спам — на адрес приложения могут приходить незапланированные письма, необходима дополнительная проверка входящих данных.
  • При отправке необходимо пользоваться разными методами в зависимости от объёма данных — администраторам можно отправлять письма не больше, чем 16Кб, а отправка обычных писем стоит относительно дорого.
  • Для полноценной работы с «админской» почтой желательно включать биллинг. Приложение с включенным биллингом может отправить администраторам 3 492 979 писем в сутки, в то время, как с отключенным всего 5 000.
  • Нетривиальный процесс подключения адреса приложения в качестве администраторского — необходим временный обработчик для заведения аккаунта Google на данный адрес и включения его в список администраторов.
• Как и где использовать:
  
  Передача небольших объёмов данных (до 16Кб) между приложениями.
  
  
• Где лучше не использовать:
  
  Частая передача больших объёмов данных быстро израсходует почтовую квоту — для этих целей больше подойдёт URLFetch.
  

URLFetch

API получения данных по URL позволяет получать информацию от других хостов с помощью HTTP и HTTPS-запросов.

• Достоинства:
  • Возможность получить данные с других приложений/серверов.
  • Асинхронность — при получении данных асинхронно во время ожидания можно выполнять другие вычисления.
  • Размер — приложение может получить до 32Мб за один запрос, однако отправить через этот API можно не более 1Мб.
• Недостатки:
  • Скорость зависит от скорости другого хоста.
  • Трафик — для службы URLFetch и пользователей единая квота трафика. Слишком активное использование URLFetch может привести к отказам в обслуживании пользователей.
• Как и где использовать:
  
  Фоновая загрузка и обработка данных, например RSS. Взаимодействие со сторонними приложениями, например с reCaptcha.
  
  
• Где лучше не использовать:
  
  Получение данных для пользователя, когда это возможно осуществить более быстрыми методами.
  

Логи приложения

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

• Достоинства:
  • Быстро — запись в лог занимает несколько миллисекунд.
  • Удобное разделение сообщений по приоритету.
• Недостатки:
  • Только запись — приложение не имеет доступа к логам.
  • Только текстовые данные, кириллица в логах может вызвать ошибки.
  • Необходимость парсить — наличие функции request_logs в инструментах разработчика позволяет лишь получить логи в виде текста, для его обработки потребуется отдельный парсер.
• Как и где использовать:
  
  Для сбора информации о работе приложения, измерений времени выполнения запросов, оповещения о медленной работе функций или о нештатных ситуациях.
  
  
• Где лучше не использовать:
  
  В некоторых случаях статистику работы приложения целесообразнее хранить в datastore. В таких случаях данные лучше передавать в задачу taskqueue и записывать её в datastore в фоновом режиме.
  

Заключение

App Engine даёт гораздо больше способов хранения данных, чем кажется на первый взгляд. В каждом из них свои компромиссы, так что вероятно, что Вашему приложению подойдёт один (или больше) из них. Часто оптимально решение включает в себя комбинацию методов, например, datastore и memcache, или локальные файлы и память инстанса.