чи GAE інфраструктура здатна розміщувати додаток, який використовують мільйони активних користувачів?

Мені хотілося б дізнатися з переліченими нижче обмеженнями GAE, чи можливо навіть створити чудовий соціальний додаток (наприклад, Facebook), розмістивши цей додаток у GAE?

Іншими словами, чи може GAE інфраструктура здатна розміщувати додаток, який використовує 600 мільйонів активних користувачів?

Обмеження, які я розкопав з декількох форумів / блогів (будь ласка, не соромтесь додати до списку, якщо ви виявите, що щось не вистачає):

1. HTTP-запит / відповідь

   • Максимальний розмір запиту: 32 Мб
   • Максимальний розмір відповіді: 32 Мб
   • Усі запити повинні відповісти протягом 30 секунд, інакше GAE викине DeadlineExceededException
   • Кожне завдання з крон має бути виконане протягом 10 хвилин
   • Завдання Cron не можуть використовувати зменшення карт
   • Кожен GET або POST на інший сайт припиняється через 5 секунд. Ви можете налаштувати його на очікування до 10 секунд макс. (проміжні сервери були б необхідні для роботи з Twitter і Facebook багато разів)
   • Клієнт не може підключитися до GAE через FTP (лише HTTP та HTTPS).
   • Немає https для користувацьких доменів. Лише для ваших доменів-app-id.appspot.com.
   • Якщо ви отримуєте приплив користувачів, ви отримуєте помилку "над квотою"

2. База даних

   • Поведінка бази даних не є такою ж, як у локальній розробці, як у фактичних серверах.
   • GQL. Більш нічого.
   • Жоден запит не може отримати більше 1000 записів (витягує серйозно, якщо ви хочете дозволити вашому клієнту кнопку "один клік" перейти "офлайн-зараз".
   • Якщо вам потрібен лінійний доступ до величезної кількості записів для виконання операції, вам не пощастило (системи Google масово кластеризовані)
   • Максимальний розмір пам'яті - 1 МБ.
   • Неможливо простий пошук тексту
   • Ви не можете приєднатись до двох таблиць.
   • Повільний (Ви повинні прочитати про те, як розділити таблиці за допомогою успадкування, щоб ви могли шукати в таблиці, отримати ключ, а потім отримати його батьків, щоб уникнути ефективності десеріалізації)
   • Виключення для виконання "занадто багато індексів"
   • Суб'єкт може мати не більше 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 Гб.

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

   - Неможливо, що Facebook, Twitter або Tumblr просто беруть завантаження користувачів і копіюють їх у папку. Не проблема.

   • На всі запити потрібно відповісти протягом 10 хвилин, інакше GAE викине DeadlineExceededException - неправильно. Насправді це 30 секунд.

   - Якщо вам потрібні більше 30 секунд, щоб доставити результати на запит користувача, ви, ймовірно, робите це неправильно.

   • Кожну роботу з кроном потрібно виконати протягом 30 секунд - неправильно, це 10 хвилин.

   - Якщо ви не можете розділити тривалу задачу на 10 хвилин, A: ви, мабуть, робите це неправильно, і B: тепер ви можете перенести це завдання на екземпляр Backend, у якого немає обмеження на час запитів.

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

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

   - Якщо запит, спрямований на користувача до зовнішнього API, займає більше 10 секунд, це, мабуть, хороша ідея сказати користувачеві все-таки повторити спробу. Якщо це не запит, спрямований на користувача, ви можете автоматично повторити завдання, поки API не відповість.

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

   - Чому це питання? Як ви думаєте, якась масштабна компанія розгортає зміни через FTP?

   • Немає https для користувацьких доменів. Лише для ваших доменів-app-id.appspot.com. - Правда.

   - Хоча це на дорожній карті.

   • Якщо ви отримуєте приплив користувачів, ви отримуєте помилку "над квотою" - наполовину правда.

   - Якщо ви належним чином сплачуєте бюджет свого додатка, ви ніколи не побачите помилку надмірної квоти. Сайт Royal Wedding розміщувався на App Engine і отримував 32 000 запитів в секунду. Відсутня помилка над квотою. Крім того, коли-небудь бачили несправний кит у Twitter або помилку надмірно потужності на Tumblr? Це, по суті, їх помилка перевищення квоти.

2. База даних

   • Поведінка бази даних не є такою ж, як у локальній розробці, як у фактичних серверах. - Помилковий

   - Якщо ви маєте на увазі запуск сховища даних на своєму ноутбуку повільніше, ніж запуск його на кластері App Engine, то це правда, інакше зовсім не відповідає дійсності.

   • GQL. Більш нічого. - Помилковий

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

   • Жоден запит не може отримати більше 1000 записів (витягується серйозно, якщо ви хочете дозволити вашому клієнту мати кнопку в один клік - перейти офлайн-зараз) - Невірно.

   - Ліміт запису на 1000 був знятий давно. Окрім того, покажіть мені будь-яку сторінку на Facebook у Facebook, Twitter чи Tumblr, для отримання якої потрібно більше 1000 записів.

   • Якщо вам потрібен лінійний доступ до величезної кількості записів для виконання операції, вам не пощастило (системи Google масово кластеризовані)

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

   • Значення максимальних значень Memcache - 10 Мб. - Насправді це 1 МБ на запис запису, як і будь-яка інша реалізація пам’яті.

   • Неможливо простий пошук тексту - правда.

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

   • Ви не можете приєднатись до двох таблиць. - Правда.

   - Розробникам App Engine потрібно налаштувати своє мислення від єдиного масивного багатокористувацького запиту SQL до декількох менших індивідуальних запитів або денормалізувати дані, щоб об'єднання не потрібні.

   • Повільно (Ви повинні прочитати про те, як розділити таблиці за допомогою успадкування, щоб ви могли шукати в таблиці, отримати ключ, а потім отримати його батьків, щоб уникнути ефективності десеріалізації) - ???

   - необхідний переклад / цитування.

   • Виключення із виконання "занадто багато індексів" - True

   - Існує обмеження кількості індексів в одному додатку. Я бачив, що це потрапило лише до академічних досліджень.

   • Суб'єкт може мати не більше 5000 значень властивостей в індексі - True

   - Тож якщо у когось більше 5000 друзів, вони потребують двох організацій у групі друзів.

   • Ключові назви форми __*__(початок та кінець двома підкресленнями) зарезервовані, і програма не повинна використовувати їх. - Правда

   - Але так що?

   • Назви ключових лімітів обмежені 500 байтами (мабуть, закодовано UTF-8) - Вірно

   - Знову, так що? Ключові назви не для зберігання новел, вони для унікальної ідентифікації сутності.

3. Мова

   • python або java або Go (все, що потрібно було б перекласти на ці мови) - Напівправда

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

4. Проблеми з сервером

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

   - Більшість API сторонніх розробників знають про App Engine і / або мають стосунки з Google. Кілька разів Twitter випадково заблокував App Engine, і він виправляється протягом декількох годин.

   • Кожна програма обмежена 3000 файлами - наполовину правдивою

   - Якщо вам дійсно потрібно більше 3000 файлів коду для вашого веб-додатка, ви можете використовувати імпорт поштового зв’язку (Також, можливо, ви робите це неправильно).

   • Немає керування ОС або апаратним забезпеченням, що працює під веб-додатком - Правда

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

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

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

Якщо ви тільки починаєте, нерозумно розробляти припущення, що ви станете настільки ж популярними, як Facebook. Будь-яка програма, яка отримує таку велику кількість, робить це поступово і з постійним пере-факторингом. По-перше, турбуйтеся про розробку функцій, які збираються залучити 600 мільйонів користувачів. Перепроектування реалізації для підтримки зростаючої бази користувачів - це тривіальна проблема порівняння.

Я думаю, що пункти в цьому FAQ поширюються на кілька основних напрямків.

Перш за все, тут є точки, які є на користь масштабованості, а не на шкоду. У дуже масштабованому додатку одна з речей, до якої ви прагнете, - це переконатись, що кожен запит значною мірою не залежить від інших, а також те, що вони всі мають однаковий розмір (з точки зору використання процесора, пам'яті, мережі тощо).

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

Отже, це охоплює такі речі, як:

• Максимальний розмір запиту / відповіді
• Запит часу на відповідь
• Терміни відповіді на зовнішній запит
• Максимальні розміри Memcache (насправді, у збірці memcache за замовчуванням максимальний розмір значення становить 1 Мб, тому очевидно, що Google використовує спеціальний бінарний файл, що збільшує обмеження в 10 разів)
• Максимальний розмір відповідей бази даних (тобто обмеження 1000 рядків)
• тощо

Друга категорія - речі, які просто застаріли:

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

Тепер було б непогано, якби Google відкрив їх інфраструктуру, щоб дозволити роботі Cron використовувати Зменшення карт, і дозволити вам виконувати запити протягом усього набору даних. Але до того моменту, коли ви навіть значна частка 600 мільйонів користувачів, ви вже будете дуже великим клієнтом Google і матимете більше варіантів, ніж у будь-якому випадку в App Engine.

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