GAE - это инфраструктура, способная разместить приложение, используемое миллионами активных пользователей?

Я хотел бы знать, учитывая ограничения GAE, перечисленные ниже, возможно ли вообще создать отличное социальное приложение (например, Facebook), разместив это приложение на GAE?

Другими словами, является ли GAE инфраструктурой, способной разместить приложение, которым пользуются 600 миллионов активных пользователей?

Ограничения, которые я нашел на нескольких форумах / блогах (пожалуйста, не стесняйтесь добавлять в список, если вы обнаружите, что чего-то не хватает):

1. HTTP-запрос / ответ

   • Максимальный размер запроса: 32 МБ
   • Максимальный размер ответа: 32 МБ
   • Все запросы должны ответить в течение 30 секунд, в противном случае GAE сгенерирует исключение DeadlineExceededException
   • Каждое задание cron должно быть выполнено в течение 10 минут
   • Задания Cron не могут использовать уменьшение карты
   • Каждый GET или POST на другой сайт прерывается через 5 секунд. Вы можете настроить его на ожидание до 10 секунд макс. (промежуточные серверы были бы необходимы для работы с Twitter и Facebook много раз)
   • Клиент не может подключиться к GAE через FTP (только HTTP и HTTPS).
   • Нет https для пользовательских доменов. Только для доменов your-app-id.appspot.com.
   • Если вы получаете приток пользователей, вы получаете ошибку «over quota»

2. База данных

   • Поведение базы данных не является таким же в локальной разработке, как на реальных серверах.
   • GQL. Ничего больше.
   • Ни один запрос не может получить более 1000 записей (отстой, если вы хотите, чтобы у вашего клиента была кнопка «один щелчок - перейти в автономный режим»)
   • Если вам нужен линейный доступ к огромному количеству записей для выполнения операции, вам не повезло (системы Google сильно сгруппированы)
   • Максимальный размер значения Memcache составляет 1 МБ.
   • Не могу сделать простой поиск текста
   • Вы не можете присоединиться к 2 столам.
   • Медленно (Вы должны прочитать о том, как разделить таблицы, используя наследование, чтобы вы могли искать в таблице, получить ключ и затем получить его родителя, чтобы избежать производительности десериализации)
   • Исключение во время выполнения «слишком много индексов»
   • У объекта может быть не более 5000 значений свойств в индексе
   • Имена ключей в форме * (начало и конец с двумя подчеркиваниями) зарезервированы и не должны использоваться приложением.
   • Имена ключей ограничены 500 байтами (я думаю, в кодировке UTF-8)

3. язык

   • Python или Java или Go (или языки, которые используют JVM, такие как Groovy, Scala и другие)

4. Проблемы с сервером

   • Отсутствие статического IP-адреса (могут возникнуть проблемы с регулированием и квотой при вызове сторонних API)
   • Каждое приложение ограничено 3000 файлами
   • Нет контроля над ОС или оборудованием, на котором работает веб-приложение

Я думаю, что меня раздражает в этом вопросе то, что вы сформулировали его и загрузили его «фактами», пытаясь собрать окончательное «нет».

Правда заключается в том, что вы можете разработать приложение App Engine, которое будет воспроизводить функции Facebook, Twitter или Tumblr. И, если приложение хорошо написано, оно будет масштабироваться для поддержки сотен миллионов пользователей. Основная причина, по которой вы не захотите (что для вас не имеет значения) - это стоимость запуска службы такого размера в App Engine.

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

1. HTTP-запрос / ответ

   • Максимальный размер запроса: 10 МБ - неправильно, увеличено до 32 МБ.
   • Максимальный размер ответа: 10 МБ - неправильно, увеличено до 32 МБ.

   - если вы разрабатываете социальное приложение, которое часто требует доставки страниц размером более 10 МБ, вы, вероятно, делаете это неправильно. Кроме того, если вам нужно доставить контент размером более 32 МБ, вы можете использовать хранилище больших двоичных файлов для файлов объемом до 2 ГБ.

   • Вы не можете получить доступ к файловой системе. (забыть о сохранении закачек в файловую систему) - неправильно. Вы можете читать из локальной файловой системы и загружать и читать / записывать файлы в blobstore.

   - Фейсбук, твиттер или Tumblr не могут просто загружать пользователей и копировать их в папку. Не ошибка.

   • Все запросы должны ответить в течение 10 минут, иначе GAE выдаст исключение DeadlineExceededException - неправильно. Это на самом деле 30 секунд.

   - Если вам требуется более 30 секунд для доставки результатов по запросу пользователя, вы, вероятно, делаете это неправильно.

   • Каждое задание cron должно быть выполнено в течение 30 секунд - неправильно, это 10 минут.

   - Если вы не можете разделить длинную задачу на 10-минутные порции, A: вы, вероятно, делаете это неправильно, и B: теперь вы можете переместить эту задачу в экземпляр Backend, у которого нет ограничений по времени для запросов.

   • Задания Cron не могут использовать уменьшение карты - никогда не использовалось уменьшение карты, но я думаю, что это требует цитирования.

   • Каждый GET или POST на другой сайт прерывается через 5 секунд. Вы можете настроить его на ожидание до 10 секунд макс. (промежуточные серверы были бы необходимы для работы с Twitter и Facebook много раз) - правда.

   - Если запрос внешнего интерфейса API на пользовательский интерфейс занимает больше 10 секунд, возможно, в любом случае рекомендуется попросить пользователя повторить попытку. Если это не пользовательский запрос, вы можете автоматически повторить задачу, пока API не ответит.

   • Клиент не может подключиться к GAE через FTP (только HTTP и HTTPS). - Правда

   - Почему это проблема? Как вы думаете, какая-нибудь крупная компания внедряет изменения через FTP?

   • Нет https для пользовательских доменов. Только для доменов your-app-id.appspot.com. - Правда.

   - Это на дорожной карте, хотя.

   • Если вы получаете приток пользователей, вы получаете сообщение об ошибке «over quota» - Half true.

   - Если вы правильно составите бюджет своего приложения, вы никогда не увидите ошибку превышения квоты. Сайт Royal Wedding размещался на App Engine и получал 32 000 запросов в секунду. Нет ошибок по квоте. Кроме того, когда-либо видели сбойный кит в Твиттере или ошибку переполнения на Tumblr? Это по сути их ошибка по квоте.

2. База данных

   • Поведение базы данных не является таким же в локальной разработке, как на реальных серверах. - Ложь

   - Если вы имеете в виду, что запуск хранилища данных на вашем ноутбуке выполняется медленнее, чем запуск его в кластере App Engine, тогда значение true, в противном случае - совсем не так.

   • GQL. Ничего больше. - Ложь

   - Большинство разработчиков используют фильтры БД для запроса хранилища данных. Кроме того, вы могли бы также сказать, что MySQL позволяет «SQL. Ничего другого».

   • Ни один запрос не может получить более 1000 записей (отстой, если вы хотите, чтобы у вашего клиента была кнопка «один щелчок - перейти в автономный режим») - False.

   - Лимит в 1000 записей был снят очень давно. Кроме того, покажите мне любую пользовательскую страницу в Facebook, Twitter или Tumblr, для отображения которой требуется более 1000 записей.

   • Если вам нужен линейный доступ к огромному количеству записей для выполнения операции, вам не повезло (системы Google сильно сгруппированы)

   - Я даже не уверен, что ты здесь делаешь. Большинство людей считают скорость огромного кластера Google огромным преимуществом системы.

   • Максимальный размер значения Memcache составляет 10 МБ. - На самом деле это 1 МБ на запись в memcache, как и в любой другой реализации memcache.

   • Не могу сделать простой текстовый поиск - правда.

   - Это особенность, которая на палубе. Большинство крупных сайтов не имеют собственной индексации текстового поиска.

   • Вы не можете присоединиться к 2 столам. - Правда.

   - Разработчики App Engine должны адаптировать свое мышление от одного массивного SQL-запроса с несколькими объединениями к нескольким более мелким индивидуальным запросам или денормализовать данные так, чтобы объединения не были нужны.

   • Медленно (Вы должны прочитать о том, как разделить таблицы, используя наследование, чтобы вы могли искать в таблице, получить ключ и затем получить его родителя, чтобы избежать производительности десериализации) - ???

   - требуется перевод / цитирование.

   • Исключение во время выполнения «слишком много индексов» - True

   - Существует ограничение на количество индексов в одном приложении. Я только видел академические исследовательские приложения, поражающие это все же.

   • У объекта может быть не более 5000 значений свойств в индексе - True

   - Таким образом, если у кого-то более 5000 друзей, им понадобятся два объекта в группе друзей.

   • Имена ключей формы __*__(начало и конец с двумя подчеркиваниями) зарезервированы и не должны использоваться приложением. - Правда

   - Ну и что?

   • Имена ключей ограничены 500 байтами (я думаю, в кодировке UTF-8) - True

   - Опять так и что? Имена ключей предназначены не для хранения новелл, а для уникальной идентификации сущности.

3. язык

   • Python или Java или Go (что-нибудь еще должно быть переведено на эти языки) - наполовину верно

   - На самом деле вы также можете запустить любой язык, который работает на JVM, включая PHP и JRuby. Не знаю, почему это проблема, хотя Python и Java - два мощных языка с множеством доступных инструментов, учебных пособий и опытных программистов.

4. Проблемы с сервером

   • Отсутствие статического IP-адреса (проблемы регулирования и квотирования при вызове сторонних API) - половина истинного

   - Большинство сторонних API знают о App Engine и / или имеют отношения с Google. Несколько раз Twitter случайно блокировал App Engine, и он исправлялся в течение нескольких часов.

   • Каждое приложение ограничено 3000 файлов - половина правда

   - Если вам действительно нужно более 3000 кодовых файлов для вашего веб-приложения, вы можете использовать zip-импорт (также вы можете ошибаться).

   • Нет контроля над ОС или оборудованием, на котором работает веб-приложение - правда

   - App Engine - это платформа как услуга . Люди не платят за то, чтобы не беспокоиться об обслуживании ОС или оборудования. Это ключевое преимущество App Engine, а не ограничение.

Нет, App Engine не подходит для приложения с 600 миллионами активных пользователей.

Реально, такие большие приложения работают на высоко настраиваемой инфраструктуре вне своих центров обработки данных. Возможно, можно разместить такое приложение в Google, но вы бы напрямую поработали с их отделом продаж, чтобы разработать решение; ограничения песочницы, которые вы перечислили выше, давно бы не имели значения.

Если вы только начинаете, глупо строить предположения, что вы станете такими же популярными, как Facebook. Любое приложение, которое получает такой большой размер, делает это постепенно и с постоянным рефакторингом. Во-первых, беспокойтесь о разработке функций, которые собираются привлечь 600 миллионов пользователей. Перестройка реализации для поддержки растущей пользовательской базы является сравнительно простой задачей.

Я думаю, что пункты в этом FAQ относятся к нескольким основным областям.

Прежде всего, есть моменты, которые на самом деле выгодны масштабируемости, а не ущербу. В приложении с высокой степенью масштабируемости одна из целей, к которой вы стремитесь, - убедиться, что каждый запрос в значительной степени независим от других, а также что они имеют одинаковый «размер» (с точки зрения использования процессора, памяти, сети и т. Д.).

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

Так что охватывает такие вещи, как:

• Максимальный размер запроса / ответа
• Запрос времени ответа
• Ограничения по времени ответа на внешний запрос
• Максимальные размеры Memcache (на самом деле, при стандартной сборке memcache максимальный размер значения составляет 1 МБ, поэтому, очевидно, Google запускает пользовательский двоичный файл, который увеличивает этот предел в 10 раз)
• Максимальные размеры ответов базы данных (т.е. ограничение в 1000 строк)
• так далее

Вторая категория - это вещи, которые просто устарели:

• Google Go теперь доступен в качестве языка в App Engine . С точки зрения высокопроизводительных языков вы не намного лучше, чем Go. Мне действительно очень нравится этот
• Хранилище данных может потерпеть неудачу - это не так с хранилищем данных с высокой репликацией (очевидно, что memcache может выйти из строя, но это только кеш)
• Ограничение на количество файлов составляет 3000, а не 1000

Теперь было бы неплохо, если бы Google открыл свою инфраструктуру, чтобы позволить заданиям cron использовать Map Reduce и позволять вам выполнять запросы по всему набору данных. Но к тому времени, когда вы станете значительной частью из 600 миллионов пользователей, вы уже станете очень большим клиентом Google, и у вас будет больше возможностей, чем в любом случае в App Engine.

Если у вас возникнет идея, которая привлечет даже 100, не говоря уже о 600 миллионах пользователей, у вас будет любой венчурный капитал и любая техническая команда для его разработки и использования в любой инфраструктуре. И в этом случае вы также захотите защитить свою интеллектуальную собственность, которую GAE не предоставит, потому что Google хочет иметь доступ к исходному коду каждого приложения GAE (в любом случае вы не можете реально защитить код Python и Java).
GAE подходит для предприятий, которые хотят избавиться от затрат на ИТ-инфраструктуру и не нуждаются в защите кода IP, а только свои данные.