Мышление в AppEngine

Я ищу ресурсы, которые помогут перенести мои дизайнерские навыки из традиционного хранилища данных RDBMS в AppEngine DataStore (например, стиль «Смягчающая схема»). Я видел несколько презентаций и все касаются общих тем и некоторых конкретных техник.

Мне интересно, есть ли место, где мы могли бы объединить знания из опыта («из окопов») на реальных подходах к переосмыслению структуры данных, особенно переносить существующие приложения. Мы сильно зависим от Hibernate и, вероятно, уже немного поехали по неверному пути с нашей моделью данных, создавая некоторые грубые запросы, с которыми наша БД борется.

Пожалуйста, ответьте, если:

  1. Вы перенесли нетривиальное приложение в AppEngine
  2. Вы создали общий тип приложения с нуля в AppEngine
  3. Вы не делали ни 1, ни 2, но рассматриваете это и хотите поделиться своими собственными результатами.

    Мне интересно, есть ли место, где мы могли бы объединить знания из опыта

    Различные группы Google хороши для этого, хотя я не знаю, применимы ли какие-либо приложения к Java-GAE еще – мой опыт GAE до сих пор является полностью Python (я с гордостью могу сказать, что Guido van Rossum, изобретатель из Python и теперь работает в Google на App Engine, сказал мне, что я научил его нескольким вещам о том, как работает его детище, – его рекомендация, в которой упоминается, что это тот самый, который я горжусь, среди всех тех, кто находится в моем связанном профиле; ). [Я работаю в Google, но мое влияние на App Engine было очень периферийным – я работал над созданием облака, кластером и сетевым управлением SW, а App Engine – о том, чтобы сделать эту инфраструктуру полезной для сторонних разработчиков].

    Есть действительно много эссе и презентаций о том, как лучше денормализовать и очертить ваши данные для оптимального масштабирования и производительности GAE – они отличаются качества. Книги, которые до сих пор существуют, так себе; в ближайшие несколько месяцев придет еще много, надеюсь, лучших (у меня был проект написать один из них, с двумя очень опытными друзьями, но мы все так заняты, что мы закончили тем, что сбросили его). В общем, я бы порекомендовал видеоролики ввода-вывода Google и эссе, которые Google благословил на своем сайте и блогах с помощью движка, PLUS каждый бит контента из блога appenginefan – то, что Гвидо похвалил меня за то, что он научил его GAE, я, в свою очередь, в основном узнал от appenginefan (отчасти благодаря замечательной команде разработчиков приложений в Пало-Альто, но его блог тоже замечателен ;-).

    Я играл с Google App Engine для Java и обнаружил, что у него было много недостатков:

    Это не хостинг Java-приложений общего назначения. В частности, у вас нет доступа к полной JRE (например, невозможно создавать потоки и т. Д.). Учитывая этот факт, вы в значительной степени должны создавать свое приложение с нуля с помощью JRE Google App Engine. Портирование любого не-тривиального приложения было бы невозможным.

    Более уместны ваши вопросы к хранилищу данных …

    Производительность хранилища данных ужасающая. Я пытался написать 5000 метеорологических наблюдений в час – ничего слишком массивного, но я не мог этого сделать, потому что я продолжал исключать из себя исключение как с хранилищем данных, так и с запросом HTTP. Использование «низкоуровневого» API хранилища данных помогло несколько, но недостаточно.

    Я хотел удалить эти наблюдения по погоде через 24 часа, чтобы не заполнить свою квоту. Опять же, не удалось сделать это, потому что операция удаления заняла слишком много времени. Эта проблема в свою очередь привела к заполнению моей квоты хранилища данных. Безумно, вы не можете легко удалить большие полосы данных в хранилище данных GAE.

    Есть некоторые функции, которые мне понравились. Интеграция Eclipse поразительна. Интерфейс сервера приложений appspot в миллион раз лучше, чем работа с Tomcat (например, красивые просмотры журналов). Но минусы намного перевешивали эти льготы для меня.

    В общем, мне постоянно приходилось побрить яка , чтобы сделать что-то, что было бы довольно тривиально в любой обычной среде хостинга Java / приложений.

    Тайм-ауты жесткие и производительность была нормально, но не очень, поэтому я нашел себе дополнительное пространство, чтобы сэкономить время; например, у меня было соотношение «многие ко многим» между торговыми картами и игроками, поэтому я дублировал информацию о том, кому принадлежит: у объектов Карты есть список объектов «Игроки» и «Игрок», список карт.

    Обычно сохранение всей вашей информации в два раза было бы глупым (и склонным к сбою синхронизации), но он работал очень хорошо.

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

    Конструкция без реляционной базы данных, по возможности, предполагает денормализацию.

    Пример. Поскольку BigTable не обеспечивает достаточных функций агрегации, опция суммы (наличности), которая будет в мире РСУБД, недоступна. Вместо этого он должен быть сохранен на модели, и метод сохранения модели должен быть переопределен для вычисления суммы денормализованного поля.

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