Разработка для легкой миграции на Google App Engine
Я собираюсь начать разрабатывать веб-приложение вскоре, и в то время как у меня есть большой опыт, делающий его в мире SQL, я понятия не имею, что я должен учесть для того, чтобы сделать так с целью миграции на GAE в самом ближайшем будущем.
С другой стороны, я мог разработать приложение для GAE от запуска, и так в этом случае, каковы различия, которые я должен учесть? Другими словами, каковы DOS и DONTs записи Вашего приложения для GAE, прибывающего из реляционные базы данных мимо.
1 ответ
Просто из головы:
- Это действительно ТОЛЬКО хранилище ключ->значение, не обманывайтесь такими вещами, как GQL (который является просто подмножеством SQL SELECT)
- Нет JOINов - часто приходится денормализовывать или забывать
- Более или менее частые таймауты
- (Очень) медленный доступ по сравнению с локальной базой SQL.
- COUNT очень дорогой
OFFSET (в SELECT) реализован на стороне клиента - так что фактически вы получаете все записи до смещения- как указал Ник Джонсон в одном из комментариев, это не на стороне клиента, так что теперь, когда LIMIT в 1000 исчез, это похоже на SQL базы данных.- (Недавно удалено) LIMIT of 1000 fetched rows
- Производительность SELECT резко снижается с увеличением числа возвращаемых строк
- Миграции трудно выполнять, потому что вы должны делать их с помощью обычных http-запросов, а каждый запрос убивается через 30 секунд. Приходится прибегать к очередям задач, которые обрабатывают строки партиями
- Существуют псевдо-иностранные ключи - называемые ReferenceProperties в Python API - но они никак не обеспечиваются - если кто-то/что-то удалит целевой объект, то у вас будет то, что в C++ известно как висячий указатель
- Поля, которые вы используете для запросов, должны быть проиндексированы, но все же использование key (своего рода первичный ключ для каждой строки/инстанции) делает ваши запросы быстрее
- Создание индексов на живом экземпляре может занять много времени (и вы не можете уменьшить его), и без них ваше приложение часто не может работать. Пиво и терпение настоятельно рекомендуются...
- Много искусственных ограничений (например, уже убранный max LIMIT в 1000). Например, оператор GQL 'IN' - это просто синтаксический сахар для множественного OR, и верхний предел используемых значений - 30.
Все это означает, что вам, вероятно, не удастся избежать демонстрации непоследовательного состояния пользователю, и почти наверняка вы не сможете избежать непоследовательного состояния ваших данных (например, половина строк перенесена, а половина нет, при ручном изменении данных JOIN и т.д.)
.