apakah GAE merupakan infrastruktur yang mampu menampung aplikasi yang digunakan oleh jutaan pengguna aktif?

Saya ingin tahu dengan batasan GAE yang tercantum di bawah ini, mungkinkah membangun aplikasi sosial yang hebat (seperti Facebook) dengan hosting aplikasi itu di GAE?

Dengan kata lain apakah GAE merupakan infrastruktur yang mampu menampung aplikasi yang digunakan oleh 600 juta pengguna aktif?

Batasan yang saya gali dari beberapa forum / blog (silakan tambahkan ke daftar jika Anda menemukan sesuatu yang hilang):

1. Permintaan / Tanggapan HTTP

   • Ukuran permintaan maks: 32 MB
   • Ukuran respons maks: 32 MB
   • Semua permintaan harus merespons dalam waktu 30 detik jika tidak, GAE akan melempar DeadlineExceededException
   • Setiap tugas cron harus dijalankan dalam 10 menit
   • Pekerjaan Cron tidak dapat memanfaatkan pengurangan peta
   • Setiap GET atau POST ke situs lain dibatalkan setelah 5 detik. Anda dapat mengonfigurasinya untuk menunggu hingga maksimal 10 detik. (server perantara akan diperlukan untuk bekerja dengan Twitter dan Facebook berkali-kali)
   • Klien tidak dapat terhubung ke GAE melalui FTP (hanya HTTP dan HTTPS).
   • Tidak ada https untuk domain khusus. Hanya untuk domain-app-id.appspot.com Anda.
   • Jika Anda mendapatkan masuknya pengguna, Anda mendapatkan kesalahan "melebihi kuota"

2. Basis data

   • Perilaku database tidak sama dalam pengembangan lokal daripada di server yang sebenarnya.
   • GQL. Tidak ada lagi.
   • Tidak ada kueri yang dapat mengambil lebih dari 1000 catatan (sangat menyebalkan jika Anda ingin klien Anda memiliki tombol satu klik-go-offline-sekarang)
   • Jika Anda memerlukan akses linier ke sejumlah besar catatan untuk melakukan operasi, Anda kurang beruntung (sistem Google dikelompokkan secara besar-besaran)
   • Nilai maksimum ukuran maksimum adalah 1 MB.
   • Tidak dapat melakukan pencarian teks sederhana
   • Anda tidak dapat bergabung dengan 2 tabel.
   • Lambat (Anda harus membaca tentang cara memisahkan tabel menggunakan pewarisan sehingga Anda dapat mencari di dalam tabel, mendapatkan kunci lalu memperoleh induknya untuk menghindari kinerja deserialisasi)
   • Pengecualian runtime "Terlalu banyak indeks"
   • Entitas paling banyak dapat memiliki 5000 nilai properti dalam indeks
   • Nama-nama kunci dari formulir * (mulai dan akhiri dengan dua garis bawah) dicadangkan, dan tidak boleh digunakan oleh aplikasi.
   • Nama-nama kunci dibatasi hingga 500 byte (saya kira dikodekan dengan UTF-8)

3. Bahasa

   • python atau java atau Go (atau bahasa yang menggunakan JVM seperti Groovy, Scala, dan lainnya)

4. Masalah Server

   • Tidak ada IP statis (mungkin memiliki masalah pelambatan dan kuota memanggil API pihak ketiga)
   • Setiap aplikasi dibatasi hingga 3000 file
   • Tidak ada kontrol OS atau perangkat keras yang menjalankan aplikasi web

Saya pikir apa yang mengganggu saya tentang pertanyaan ini adalah bahwa Anda telah mengutarakannya dan memuatnya dengan "fakta" dalam upaya untuk mengumpulkan no definitif.

Yang benar adalah bahwa Anda dapat mengembangkan aplikasi App Engine yang mereplikasi fitur Facebook, Twitter, atau Tumblr. Dan dengan asumsi aplikasi itu ditulis dengan baik, itu akan skala untuk mendukung ratusan juta pengguna. Alasan utama Anda tidak ingin (yang tampaknya tidak menjadi pertimbangan bagi Anda) adalah biaya menjalankan layanan yang sebesar di App Engine.

Juga, saya gagal melihat bagaimana pembatasan yang Anda daftarkan akan mencegah Anda mengembangkan aplikasi semacam itu.

1. Permintaan / Tanggapan HTTP

   • Ukuran permintaan maks: 10 MB - salah, dinaikkan menjadi 32MB.
   • Ukuran respons maks: 10 MB - salah, dinaikkan menjadi 32MB.

   - jika Anda mengembangkan aplikasi sosial yang sering perlu mengirimkan halaman yang lebih besar dari 10MB, Anda mungkin salah melakukannya. Juga, jika Anda perlu mengirimkan konten yang lebih besar dari 32MB Anda dapat menggunakan blobstore untuk file hingga 2GB.

   • Anda tidak dapat mengakses sistem file. (lupakan tentang menyimpan unggahan ke sistem file) - salah. Anda dapat membaca dari sistem file lokal dan dapat mengunggah dan membaca / menulis file ke blobstore.

   - Tidak mungkin Facebook, Twitter, atau Tumblr hanya mengambil unggahan pengguna dan menyalinnya ke folder. Bukan masalah.

   • Semua permintaan harus merespons dalam 10 menit jika GAE akan melempar DeadlineExceededException - salah. Sebenarnya 30 detik.

   - Jika Anda membutuhkan lebih dari 30 detik untuk mengirimkan hasil ke permintaan pengguna, Anda mungkin salah melakukannya.

   • Setiap tugas cron harus dijalankan dalam 30 detik - salah, ini 10 menit.

   - Jika Anda tidak dapat membagi tugas panjang menjadi potongan 10 menit, A: Anda mungkin salah melakukannya dan B: Anda sekarang dapat memindahkan tugas itu ke instance Backend, yang tidak memiliki batas waktu pada permintaan.

   • Pekerjaan Cron tidak dapat menggunakan pengurangan peta - pernah digunakan pengurangan peta, tapi saya pikir ini membutuhkan kutipan.

   • Setiap GET atau POST ke situs lain dibatalkan setelah 5 detik. Anda dapat mengonfigurasinya untuk menunggu hingga maksimal 10 detik. (server perantara akan diperlukan untuk bekerja dengan Twitter dan Facebook berkali-kali) - Benar.

   - Jika permintaan yang dihadapi pengguna ke API eksternal membutuhkan waktu lebih dari 10 detik, mungkin ide yang baik untuk memberitahu pengguna untuk mencoba lagi. Jika itu bukan permintaan yang menghadap pengguna, Anda dapat secara otomatis mencoba kembali tugas sampai API merespons.

   • Klien tidak dapat terhubung ke GAE melalui FTP (hanya HTTP dan HTTPS). - Benar

   - Mengapa ini menjadi masalah? Apakah Anda pikir ada perusahaan skala besar yang menyebarkan perubahan melalui FTP?

   • Tidak ada https untuk domain khusus. Hanya untuk domain-app-id.appspot.com Anda. - Benar.

   - Ini ada di peta jalan.

   • Jika Anda mendapatkan masuknya pengguna, Anda mendapatkan kesalahan "melebihi kuota" - Setengah benar.

   - Jika Anda menganggarkan aplikasi dengan benar, Anda tidak akan pernah melihat kesalahan kuota berlebihan. Situs Royal Wedding dihosting di App Engine dan menerima 32.000 permintaan per detik. Tidak ada kesalahan kuota. Juga, pernah melihat paus gagal di Twitter, atau kesalahan kelebihan kapasitas di Tumblr? Itu pada dasarnya kesalahan kelebihan kuota mereka.

2. Basis data

   • Perilaku database tidak sama dalam pengembangan lokal daripada di server yang sebenarnya. - Salah

   - Jika Anda maksud menjalankan datastore di laptop Anda lebih lambat daripada menjalankannya di cluster App Engine, maka benar, jika tidak, tidak benar sama sekali.

   • GQL. Tidak ada lagi. - Salah

   - Sebagian besar pengembang menggunakan filter db untuk menanyakan datastore. Plus, Anda bisa mengatakan bahwa MySQL memungkinkan "SQL. Tidak ada yang lain."

   • Tidak ada kueri yang dapat mengambil lebih dari 1000 catatan (sangat menyebalkan jika Anda ingin klien Anda memiliki tombol satu klik-go-offline-sekarang) - Salah.

   - Batas rekor 1000 telah diangkat sejak lama. Selain itu, perlihatkan kepada saya halaman yang menghadap pengguna di Facebook, Twitter, atau Tumblr yang membutuhkan lebih dari 1000 catatan untuk diurai.

   • Jika Anda memerlukan akses linier ke sejumlah besar catatan untuk melakukan operasi, Anda kurang beruntung (sistem Google dikelompokkan secara besar-besaran)

   - Saya bahkan tidak yakin apa yang Anda dapatkan di sini. Kebanyakan orang menganggap kecepatan cluster besar Google sebagai keuntungan besar dari sistem.

   • Nilai maksimum ukuran memo adalah 10 MB. - Sebenarnya ini 1MB per entri memcache, sama seperti setiap implementasi memcache lainnya.

   • Tidak dapat melakukan pencarian teks sederhana - Benar.

   - Ini adalah fitur yang ada di dek. Sebagian besar situs besar tidak melakukan pengindeksan pencarian teks sendiri.

   • Anda tidak dapat bergabung dengan 2 tabel. - Benar.

   - Pengembang App Engine perlu menyesuaikan pemikiran mereka dari satu kueri SQL multi-gabung tunggal yang besar ke beberapa kueri individual yang lebih kecil, atau denormalkan data sehingga penggabungan tidak diperlukan.

   • Lambat (Anda harus membaca tentang cara memisahkan tabel menggunakan pewarisan sehingga Anda dapat mencari di dalam tabel, mendapatkan kunci lalu mendapatkan induknya untuk menghindari kinerja deserialisasi) - ???

   - terjemahan / kutipan diperlukan.

   • Pengecualian runtime "Terlalu banyak indeks" - Benar

   - Ada batasan jumlah indeks dalam satu aplikasi. Saya hanya melihat aplikasi penelitian akademik memukulnya.

   • Entitas paling banyak dapat memiliki 5000 nilai properti dalam indeks - Benar

   - Jadi, jika seseorang memiliki lebih dari 5000 teman, mereka akan membutuhkan dua entitas dalam grup teman.

   • Nama-nama utama formulir __*__(mulai dan akhiri dengan dua garis bawah) dicadangkan, dan tidak boleh digunakan oleh aplikasi. - Benar

   - Tapi jadi apa?

   • Nama-nama kunci dibatasi hingga 500 byte (disandi UTF-8, kurasa) - Benar

   - Sekali lagi, lalu apa? Nama kunci bukan untuk menyimpan novellas, tetapi untuk mengidentifikasi entitas secara unik.

3. Bahasa

   • python atau java atau Go (apa pun harus diterjemahkan ke bahasa ini) - Setengah benar

   - Sebenarnya Anda juga dapat menjalankan bahasa apa pun yang berjalan di JVM, termasuk PHP dan JRuby. Tidak yakin mengapa ini menjadi masalah, Python dan Java adalah dua bahasa yang kuat dengan banyak alat yang tersedia, tutorial, dan programmer yang berpengalaman.

4. Masalah Server

   • Tidak ada IP statis (Masalah pelambatan dan kuota memanggil API pihak ketiga) - Setengah benar

   - Sebagian besar API pihak ketiga mengetahui Mesin Aplikasi dan / atau memiliki hubungan dengan Google. Beberapa kali Twitter secara tidak sengaja memblokir App Engine dan diperbaiki dalam beberapa jam.

   • Setiap aplikasi dibatasi hingga 3000 file - Setengah benar

   - Jika Anda benar-benar membutuhkan lebih dari 3000 file kode untuk aplikasi web Anda, Anda dapat menggunakan impor zip (Juga, Anda mungkin salah melakukannya).

   • Tidak ada kontrol OS atau perangkat keras yang menjalankan aplikasi web - Benar

   - App Engine adalah Platform sebagai Layanan . Tidak perlu khawatir tentang perbaikan OS atau perangkat keras adalah apa yang orang bayar. Ini adalah keunggulan utama App Engine, bukan batasan.

Tidak, App Engine tidak sesuai untuk aplikasi dengan 600 juta pengguna aktif.

Secara realistis, aplikasi ini berjalan besar pada infrastruktur yang sangat disesuaikan dari pusat data mereka sendiri. Mungkin memungkinkan untuk meng-host aplikasi semacam itu dengan Google, tetapi Anda akan bekerja secara langsung dengan tim penjualan mereka untuk merancang solusi; pembatasan kotak pasir yang Anda sebutkan di atas akan lama tidak relevan.

Jika Anda baru memulai, konyol untuk mendesain dengan asumsi bahwa Anda akan menjadi sepopuler Facebook. Aplikasi apa pun yang mendapatkan sebesar ini melakukannya secara bertahap dan dengan anjak piutang ulang yang konstan. Pertama, khawatir tentang mendesain fitur yang akan menarik 600 juta pengguna. Mendesain ulang implementasi untuk mendukung basis pengguna yang berkembang adalah masalah sepele dengan perbandingan.

Saya pikir poin dalam FAQ itu terbagi dalam beberapa area utama.

Pertama-tama, ada poin yang sebenarnya menguntungkan skalabilitas, daripada merugikan. Dalam aplikasi yang sangat skalabel, salah satu hal yang Anda perjuangkan adalah memastikan setiap permintaan sebagian besar independen dari yang lain dan juga bahwa mereka semua di sekitar "ukuran" yang sama (dalam hal penggunaan CPU, memori, jaringan, dll).

Dengan begitu, permintaan dapat dengan mudah didistribusikan antar node di cluster Anda tanpa khawatir tentang sekelompok "besar" permintaan yang kelaparan permintaan yang lebih kecil pada node yang sama. Ini membuat infrastruktur Anda tetap sederhana dalam hal pemeliharaan, kinerja, dan keandalan.

Jadi itu mencakup hal-hal seperti:

• Ukuran permintaan / respons maks
• Minta waktu tanggapan
• Batas waktu respons permintaan eksternal
• Ukuran maksimum memcache (pada kenyataannya, dalam build default memcache, ukuran nilai maksimum adalah 1 MB, jadi jelas Google menjalankan biner kustom yang meningkatkan batas 10 kali lipat)
• Ukuran respons basis data maksimum (yaitu batas 1.000 baris)
• dll

Kategori kedua adalah hal-hal yang sudah ketinggalan zaman:

• Google Go sekarang tersedia sebagai bahasa di App Engine . Dalam hal bahasa kinerja tinggi, Anda tidak mendapatkan yang lebih baik daripada Go. Sebenarnya saya sangat suka yang ini
• Datastore bisa gagal - tidak benar dengan Datastore Replikasi Tinggi (jelas memcache bisa gagal, tapi itu hanya cache)
• Batas jumlah file adalah 3.000 bukan 1.000

Sekarang, alangkah baiknya jika Google membuka infrastruktur mereka untuk memungkinkan pekerjaan cron menggunakan Peta Reduce, dan membiarkan Anda menjalankan kueri atas seluruh kumpulan data Anda. Tetapi pada saat Anda bahkan sebagian kecil dari 600 juta pengguna, Anda akan menjadi pelanggan Google yang sangat besar dan akan memiliki lebih banyak opsi daripada yang tersedia di App Engine.

Jika Anda datang dengan ide yang akan menarik bahkan 100, apalagi 600, juta pengguna Anda akan memiliki modal usaha dan tim teknologi apa pun untuk mengembangkan dan menjalankannya di infrastruktur apa pun. Dan Anda juga ingin melindungi kekayaan intelektual Anda dalam hal itu, yang tidak akan disediakan oleh GAE karena Google ingin memiliki akses ke kode sumber setiap aplikasi GAE (Anda toh tidak dapat benar-benar melindungi kode Python dan Java).
GAE cocok untuk perusahaan yang ingin menyingkirkan biaya infrastruktur TI mereka dan tidak perlu melindungi IP kode tetapi hanya data mereka.