Chciałbym wiedzieć z ograniczeniami GAE wymienionymi poniżej, czy w ogóle można zbudować świetną aplikację społecznościową (jak Facebook), hostując tę aplikację na GAE?
Innymi słowy, czy GAE jest infrastrukturą umożliwiającą hosting aplikacji używanej przez 600 milionów aktywnych użytkowników?
Ograniczenia, które wykopałem z kilku forów / blogów (dodaj coś do listy, jeśli czegoś brakuje):
Żądanie / odpowiedź HTTP
- Maksymalny rozmiar żądania: 32 MB
- Maksymalny rozmiar odpowiedzi: 32 MB
- Wszystkie żądania muszą odpowiedzieć w ciągu 30 sekund, w przeciwnym razie GAE zgłosi wyjątek DeadlineExceededException
- Każde zadanie crona musi zostać wykonane w ciągu 10 minut
- Zadania Cron nie mogą korzystać ze zmniejszania mapy
- Każdy GET lub POST na innej stronie jest przerywany po 5 sekundach. Możesz go skonfigurować tak, aby czekał maksymalnie 10 sekund. (serwery pośrednie byłyby konieczne do współpracy z Twitterem i Facebookiem wiele razy)
- Klient nie może połączyć się z GAE przez FTP (tylko HTTP i HTTPS).
- Brak https dla domen niestandardowych. Tylko dla domen twoja.app-id.appspot.com.
- W przypadku napływu użytkowników pojawia się błąd „przekroczenie limitu”
Baza danych
- Zachowanie bazy danych nie jest takie samo w rozwoju lokalnym jak w rzeczywistych serwerach.
- GQL. Nic więcej.
- Żadne zapytanie nie może pobrać więcej niż 1000 rekordów (jest do bani, jeśli chcesz pozwolić swojemu klientowi na kliknięcie przycisku „przejdź do trybu offline-teraz”)
- Jeśli potrzebujesz liniowego dostępu do ogromnej liczby rekordów, aby wykonać operację, nie masz szczęścia (systemy Google są masowo skupione)
- Maksymalny rozmiar wartości Memcache to 1 MB.
- Nie można wykonać prostego wyszukiwania tekstu
- Nie możesz dołączyć do 2 stołów.
- Powolny (musisz przeczytać o tym, jak oddzielić tabele za pomocą dziedziczenia, aby móc wyszukiwać w tabeli, uzyskać klucz, a następnie uzyskać jego element nadrzędny, aby uniknąć wydajności deserializacji)
- Wyjątek czasu wykonywania „Zbyt wiele indeksów”
- Jednostka może mieć najwyżej 5000 wartości właściwości w indeksie
- Kluczowe nazwy formularza * (początek i koniec z dwoma podkreśleniami) są zastrzeżone i nie powinny być używane przez aplikację.
- Nazwy kluczy są ograniczone do 500 bajtów (chyba kodowane w UTF-8)
Język
- Python, Java lub Go (lub języki, które korzystają z JVM, takie jak Groovy, Scala i inne)
Problemy z serwerem
- Brak statycznego adresu IP (mogą występować problemy z ograniczaniem przepustowości i limitami przy wywoływaniu interfejsów API stron trzecich)
- Każda aplikacja jest ograniczona do 3000 plików
- Brak kontroli nad systemem operacyjnym lub sprzętem, na którym działa aplikacja internetowa
Odpowiedzi:
Myślę, że denerwuje mnie to pytanie, że sformułowałeś je i załadowałeś „faktami”, próbując uzyskać ostateczne „nie”.
Prawda jest taka, że możesz opracować aplikację App Engine, która replikuje funkcje Facebooka, Twittera lub Tumblr. Zakładając, że aplikacja jest dobrze napisana, będzie skalowana, aby obsługiwać setki milionów użytkowników. Głównym powodem, dla którego nie chcesz tego robić (co nie wydaje się być dla ciebie rozważaniem), jest koszt uruchomienia usługi tej wielkości w App Engine.
Nie widzę też, w jaki sposób wymienione przez Ciebie ograniczenia uniemożliwiłyby ci opracowanie takiej aplikacji.
Żądanie / odpowiedź HTTP
- jeśli tworzysz aplikację społecznościową, która często musi dostarczać strony większe niż 10 MB, prawdopodobnie robisz to źle. Ponadto, jeśli musisz dostarczyć zawartość większą niż 32 MB, możesz użyć magazynu obiektów blobstore dla plików do 2 GB.
- W żaden sposób Facebook, Twitter lub Tumblr nie pobierają plików użytkownika i kopiują je do folderu. To nie problem.
- Jeśli potrzebujesz więcej niż 30 sekund, aby dostarczyć wyniki do żądania użytkownika, prawdopodobnie robisz to źle.
- Jeśli nie możesz podzielić długiego zadania na 10-minutowe fragmenty, A: prawdopodobnie robisz to źle, a B: możesz teraz przenieść to zadanie do instancji Backend, która nie ma limitu czasu na żądania.
Zadania Crona nie mogą korzystać z funkcji zmniejszania mapy - nigdy nie używanej redukcji mapy, ale myślę, że wymaga to cytowania.
Każdy GET lub POST na innej stronie jest przerywany po 5 sekundach. Możesz go skonfigurować tak, aby czekał maksymalnie 10 sekund. (serwery pośrednie byłyby niezbędne do współpracy z Twitterem i Facebookiem wiele razy) - Prawda.
- Jeśli skierowane do użytkownika żądanie zewnętrznego interfejsu API trwa dłużej niż 10 sekund, prawdopodobnie dobrym pomysłem jest poinformowanie użytkownika o ponownej próbie. Jeśli nie jest to żądanie skierowane do użytkownika, możesz automatycznie ponowić zadanie, dopóki interfejs API nie odpowie.
- Dlaczego to jest problem? Czy uważasz, że jakaś duża firma wdraża zmiany za pośrednictwem FTP?
- Ale to jest w planie.
- Jeśli odpowiednio budżetujesz swoją aplikację, nigdy nie zobaczysz błędu przekroczenia limitu. Witryna Royal Wedding była hostowana w App Engine i otrzymywała 32 000 próśb na sekundę. Brak błędów przekroczenia limitu. Czy widziałeś kiedyś błąd wieloryba na Twitterze lub błąd nadmiernej pojemności na Tumblr? To zasadniczo ich błąd przekroczenia limitu.
Baza danych
- Jeśli masz na myśli, że uruchomienie magazynu danych na laptopie jest wolniejsze niż uruchomienie go w klastrze App Engine, to prawda, w przeciwnym razie wcale nie prawda.
- Większość programistów używa filtrów db do przeszukiwania magazynu danych. Ponadto można również powiedzieć, że MySQL zezwala na „SQL. Nic więcej”.
- Limit 1000 rekordów został zniesiony dawno temu. Poza tym pokaż mi stronę skierowaną do użytkownika na Facebooku, Twitterze lub Tumblr, która wymaga renderowania ponad 1000 rekordów.
- Nie jestem nawet pewien, o co tu chodzi. Większość osób uważa szybkość ogromnego klastra Google za ogromną zaletę systemu.
Maksymalny rozmiar wartości Memcache to 10 MB. - W rzeczywistości jest to 1 MB na pozycję memcache, tak samo jak każda inna implementacja memcache.
Nie można przeprowadzić prostego wyszukiwania tekstu - prawda.
- To funkcja na pokładzie. Większość dużych witryn nie wykonuje własnego indeksowania wyszukiwania tekstowego.
- Programiści App Engine muszą zmienić sposób myślenia z pojedynczego zapytania SQL z wieloma połączeniami na kilka mniejszych pojedynczych zapytań lub zdenormalizować dane, aby łączenia nie były potrzebne.
- wymagane tłumaczenie / cytowanie.
- Istnieje ograniczenie liczby indeksów w jednej aplikacji. Widziałem jednak tylko aplikacje badań akademickich.
- Więc jeśli ktoś ma więcej niż 5000 przyjaciół, potrzebuje dwóch podmiotów w grupie przyjaciół.
__*__(początek i koniec z dwoma podkreśleniami) są zastrzeżone i nie powinny być używane przez aplikację. - Prawdziwe-- No i co z tego?
- Znowu, więc co? Kluczowe nazwy nie służą do przechowywania powieści, lecz do jednoznacznej identyfikacji bytu.
Język
- W rzeczywistości można również uruchomić dowolny język działający na JVM, w tym PHP i JRuby. Nie jestem pewien, dlaczego jest to problem, Python i Java to dwa potężne języki z dużą ilością dostępnych narzędzi, samouczków i doświadczonych programistów.
Problemy z serwerem
- Większość interfejsów API stron trzecich jest świadoma App Engine i / lub ma związek z Google. Kilka razy Twitter przypadkowo zablokował App Engine i naprawiono go w ciągu kilku godzin.
- Jeśli naprawdę potrzebujesz więcej niż 3000 plików kodu dla swojej aplikacji internetowej, możesz skorzystać z importu zip (również być może robisz to źle).
- App Engine to platforma jako usługa . Ludzie nie muszą się martwić o obsługę systemu operacyjnego lub sprzętu. Jest to kluczowa zaleta App Engine, a nie ograniczenie.
źródło
Nie, App Engine nie jest odpowiedni dla aplikacji z 600 milionami aktywnych użytkowników.
Realistycznie, tak duże aplikacje działają na wysoce spersonalizowanej infrastrukturze z własnych centrów danych. Prawdopodobnie możliwe jest hostowanie takiej aplikacji w Google, ale możesz zaprojektować rozwiązanie bezpośrednio z ich zespołem sprzedaży; wymienione powyżej ograniczenia piaskownicy byłyby od dawna nieistotne.
Jeśli dopiero zaczynasz, głupotą jest zakładać, że staniesz się tak popularny jak Facebook. Każda aplikacja, która osiąga tak duże rozmiary, robi to stopniowo i przy ciągłym ponownym faktorowaniu. Po pierwsze, martw się o projektowanie funkcji, które przyciągną 600 milionów użytkowników. W porównaniu z tym przeprojektowanie implementacji w celu obsługi rosnącej bazy użytkowników jest banalnym problemem.
źródło
Myślę, że punkty w tym FAQ dzielą się na kilka głównych obszarów.
Przede wszystkim istnieją punkty, które są bardziej korzystne dla skalowalności niż dla szkody. W wysoce skalowalnej aplikacji jedną z rzeczy, do której dążysz, jest upewnienie się, że każde żądanie jest w dużej mierze niezależne od innych, a także, że wszystkie mają ten sam „rozmiar” (pod względem wykorzystania procesora, pamięci, sieci itp.).
W ten sposób żądania mogą być łatwo dystrybuowane między węzłami w klastrze bez obawy, że grupa „dużych” żądań głosi mniejsze żądania w tym samym węźle. Dzięki temu infrastruktura jest prosta pod względem konserwacji, wydajności i niezawodności.
To obejmuje takie rzeczy jak:
Druga kategoria to rzeczy, które są po prostu nieaktualne:
Byłoby miło, gdyby Google otworzył swoją infrastrukturę, aby umożliwić zadaniom cron wykorzystanie Map Reduce i umożliwić uruchamianie zapytań dotyczących całego zestawu danych. Ale do czasu, gdy staniesz się znaczącym ułamkiem 600 milionów użytkowników, będziesz już bardzo dużym klientem Google i miałbyś więcej opcji niż to, co jest dostępne w App Engine.
źródło
Jeśli wpadniesz na pomysł, który przyciągnie nawet 100, nie mówiąc już o 600 milionach użytkowników, będziesz dysponować dowolnym kapitałem wysokiego ryzyka i dowolnym zespołem technologicznym, który opracuje go i uruchomi na dowolnej infrastrukturze. W takim przypadku będziesz także chciał chronić swoją własność intelektualną, której GAE nie zapewni, ponieważ Google chce mieć dostęp do kodu źródłowego każdej aplikacji GAE (tak naprawdę nie możesz tak naprawdę chronić kodu Python i Java).
GAE jest odpowiedni dla przedsiębiorstw, które chcą pozbyć się kosztów infrastruktury IT i nie muszą chronić kodu IP, ale tylko swoje dane.
źródło