Проектирование для легкого перехода на Google App Engine - PullRequest
Новая
       14

Проектирование для легкого перехода на Google App Engine

6 голосов
/ 02 марта 2010

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

В качестве альтернативы, я мог бы спроектировать приложение для GAE с самого начала, и поэтому в этом случае, какие различия я должен принять во внимание? Другими словами, каковы ДЕЙСТВИЯ и НЕДОСТУПНОСТИ написания вашего приложения для GAE, исходя из прошлых реляционных баз данных.

1 Ответ

7 голосов
/ 02 марта 2010

Просто из головы:

  • Это действительно ТОЛЬКО хранилище ключей -> значений, не дайте себя одурачить такими вещами, как GQL (который является просто подмножеством SQL SELECT)
  • Нет СОЕДИНЕНИЙ - часто приходится денормализовать или забыть
  • Более или менее частые тайм-ауты
  • (Очень) медленный доступ по сравнению с локальной базой SQL.
  • COUNT очень дорого
  • OFFSET (в SELECT) реализован на стороне клиента - так что фактически вы извлекаете все записи вплоть до смещения - как указал Ник Джонсон в одном из комментариев, это не сторона клиента, так что теперь, как Ограничение 1000 пропало, похоже на базы данных SQL.
  • (Недавно удалено) LIMIT из 1000 выбранных строк
  • Производительность SELECT резко уменьшается с увеличением количества возвращаемых строк
  • Миграции сложно выполнить, потому что вы должны выполнять их с использованием обычных HTTP-запросов, и каждый запрос прерывается через 30 секунд. Вы должны прибегнуть к очередям задач, которые обрабатывают строки в пакетах
  • Существуют псевдо-внешние ключи - называемые ReferenceProperties в Python API - но они не применяются каким-либо образом - если кто-то / что-то удаляет целевой объект, у вас есть то, что в C ++ известно как висячий указатель
  • Поля, которые вы используете для запросов, должны быть проиндексированы, но все равно с помощью ключа (сортировка первичного ключа для каждой строки / экземпляра) ваши запросы выполняются быстрее
  • Создание индексов на живом экземпляре может занять много времени (и вы не можете уменьшить его), и без них ваше приложение часто не сможет работать. Настоятельно рекомендуется пиво и терпение.
  • МНОЖЕСТВО искусственных пределов (например, уже удаленный максимальный предел 1000). Например. Оператор GQL 'IN' является просто синтаксическим сахаром для нескольких OR, и существует верхний предел 30 используемых значений.

Все это означает, что вы, вероятно, не можете избежать раскрытия несогласованного состояния пользователю, и почти наверняка вы не сможете избежать несогласованного состояния ваших данных (например, половина строк перенесена, а половина нет, при ручном изменении данных JOIN и т. Д.) *

...