Мышление в AppEngine

Question

Я ищу ресурсы, которые помогут перенести мои навыки проектирования из традиционного хранилища данных СУБД в хранилище данных AppEngine (т. Е. В стиле «мягкой схемы»). Я видел несколько презентаций, и все они касаются всеобъемлющих тем и некоторых конкретных приемов.

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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