GAE có phải là cơ sở hạ tầng có khả năng lưu trữ một ứng dụng được sử dụng bởi hàng triệu người dùng đang hoạt động không?

Tôi muốn biết với những hạn chế của GAE được liệt kê dưới đây, thậm chí có thể xây dựng một ứng dụng xã hội tuyệt vời (như Facebook) bằng cách lưu trữ ứng dụng đó trên GAE không?

Nói cách khác, GAE có phải là cơ sở hạ tầng có khả năng lưu trữ một ứng dụng được sử dụng bởi 600 triệu người dùng đang hoạt động không?

Những hạn chế tôi đã rút ra từ một vài diễn đàn / blog (xin vui lòng thêm vào danh sách nếu bạn tìm thấy bất cứ điều gì còn thiếu):

1. Yêu cầu / Phản hồi HTTP

   • Kích thước yêu cầu tối đa: 32 MB
   • Kích thước phản hồi tối đa: 32 MB
   • Tất cả các yêu cầu phải trả lời trong vòng 30 giây nếu không GAE sẽ ném DeadlineExceededException
   • Mỗi công việc định kỳ phải được thực hiện trong vòng 10 phút
   • Việc làm cron không thể sử dụng giảm bản đồ
   • Mỗi GET hoặc POST đến một trang web khác sẽ bị hủy bỏ sau 5 giây. Bạn có thể định cấu hình nó để chờ tối đa 10 giây. (máy chủ trung gian sẽ cần thiết để làm việc với Twitter và Facebook nhiều lần)
   • Máy khách không thể kết nối với GAE thông qua FTP (chỉ HTTP và HTTPS).
   • Không có https cho tên miền tùy chỉnh. Chỉ dành cho tên miền của bạn-app-id.appspot.com.
   • Nếu bạn nhận được một luồng người dùng, bạn sẽ gặp lỗi "vượt quá hạn ngạch"

2. Cơ sở dữ liệu

   • Hành vi cơ sở dữ liệu không giống nhau trong phát triển cục bộ so với các máy chủ thực tế.
   • GQL. Không có gì khác.
   • Không có truy vấn nào có thể truy xuất hơn 1000 bản ghi (thực sự nghiêm túc nếu bạn muốn cho phép khách hàng của mình có nút một lần nhấp-ngoại tuyến-ngay bây giờ)
   • Nếu bạn cần truy cập tuyến tính vào một lượng lớn hồ sơ để thực hiện một thao tác, bạn sẽ không gặp may (các hệ thống của Google được phân cụm ồ ạt)
   • Giá trị Memcache kích thước tối đa là 1 MB.
   • Không thể thực hiện tìm kiếm văn bản đơn giản
   • Bạn không thể tham gia 2 bảng.
   • Chậm (Bạn phải đọc về cách tách các bảng bằng cách sử dụng tính kế thừa để bạn có thể tìm kiếm trong một bảng, lấy khóa và sau đó lấy cha mẹ của nó để tránh hiệu suất khử lưu huỳnh)
   • Ngoại lệ thời gian chạy "Quá nhiều chỉ mục"
   • Một thực thể nhiều nhất có thể có 5000 giá trị thuộc tính trong một chỉ mục
   • Tên khóa của biểu mẫu * (bắt đầu và kết thúc bằng hai dấu gạch dưới) được bảo lưu và ứng dụng không nên được sử dụng.
   • Tên khóa được giới hạn ở 500 byte (mã hóa UTF-8, tôi đoán vậy)

3. Ngôn ngữ

   • python hoặc java hoặc Go (hoặc các ngôn ngữ sử dụng JVM như Groovy, Scala và các ngôn ngữ khác)

4. Sự cố máy chủ

   • Không có IP tĩnh (có thể có vấn đề về điều tiết và hạn ngạch khi gọi API của bên thứ ba)
   • Mỗi ứng dụng được giới hạn ở 3000 tệp
   • Không kiểm soát hệ điều hành hoặc phần cứng chạy ứng dụng web

Tôi nghĩ điều khiến tôi bực mình về câu hỏi này là bạn đã đặt câu hỏi và tải nó với "sự thật" trong nỗ lực thu thập số không.

Sự thật là bạn có thể phát triển ứng dụng App Engine sao chép các tính năng của Facebook, Twitter hoặc Tumblr. Và giả sử ứng dụng được viết tốt, nó sẽ mở rộng để hỗ trợ hàng trăm triệu người dùng. Lý do chính mà bạn không muốn (dường như không phải là một sự cân nhắc cho bạn) là chi phí để chạy một dịch vụ có kích thước trên Máy ứng dụng.

Ngoài ra, tôi không thấy bất kỳ hạn chế nào bạn liệt kê sẽ ngăn bạn phát triển một ứng dụng như vậy.

1. Yêu cầu / Phản hồi HTTP

   • Kích thước yêu cầu tối đa: 10 MB - sai, tăng lên 32 MB.
   • Kích thước phản hồi tối đa: 10 MB - sai, tăng lên 32 MB.

   - nếu bạn đang phát triển một ứng dụng xã hội thường xuyên cần phân phối các trang lớn hơn 10MB thì có lẽ bạn đã làm sai. Ngoài ra, nếu bạn cần phân phối nội dung lớn hơn 32 MB, bạn có thể sử dụng blobstore cho các tệp có dung lượng lên tới 2GB.

   • Bạn không thể truy cập hệ thống tập tin. (quên về việc lưu các tệp tải lên hệ thống tập tin) - sai. Bạn có thể đọc từ hệ thống tệp cục bộ và có thể tải lên và đọc / ghi tệp lên blobstore.

   - Không có cách nào mà Facebook, Twitter hoặc Tumblr chỉ lấy người dùng tải lên và sao chép chúng vào một thư mục. Không phải là một vấn đề.

   • Tất cả các yêu cầu phải trả lời trong vòng 10 phút nếu không GAE sẽ ném DeadlineExceededException - sai. Thực sự là 30 giây.

   - Nếu bạn cần lâu hơn 30 giây để cung cấp kết quả cho yêu cầu của người dùng, có lẽ bạn đang làm sai.

   • Mỗi công việc định kỳ phải được thực hiện trong vòng 30 giây - sai, đó là 10 phút.

   - Nếu bạn không thể chia một nhiệm vụ dài thành 10 phút, A: bạn có thể đã làm sai và B: bây giờ bạn có thể chuyển nhiệm vụ đó sang phiên bản Backend, không có giới hạn thời gian cho các yêu cầu.

   • Công việc cron không thể sử dụng giảm bản đồ - không bao giờ sử dụng giảm bản đồ, nhưng tôi nghĩ điều này đòi hỏi phải trích dẫn.

   • Mỗi GET hoặc POST đến một trang web khác sẽ bị hủy bỏ sau 5 giây. Bạn có thể định cấu hình nó để chờ tối đa 10 giây. (máy chủ trung gian sẽ cần thiết để làm việc với Twitter và Facebook nhiều lần) - Đúng.

   - Nếu yêu cầu đối mặt với người dùng đối với API bên ngoài mất hơn 10 giây, có lẽ bạn nên nói với người dùng thử lại bằng mọi cách. Nếu đó không phải là yêu cầu đối với người dùng, bạn có thể tự động thử lại tác vụ cho đến khi API phản hồi.

   • Máy khách không thể kết nối với GAE thông qua FTP (chỉ HTTP và HTTPS). - Thật

   -- Tại sao điều này là một vấn đề? Bạn có nghĩ rằng bất kỳ công ty quy mô lớn nào triển khai các thay đổi thông qua FTP không?

   • Không có https cho tên miền tùy chỉnh. Chỉ dành cho tên miền của bạn-app-id.appspot.com. - Thật.

   - Đó là trên lộ trình mặc dù.

   • Nếu bạn nhận được một luồng người dùng, bạn sẽ gặp lỗi "vượt quá hạn ngạch" - Một nửa đúng.

   - Nếu bạn đặt ngân sách đúng cho ứng dụng của mình, bạn sẽ không bao giờ thấy lỗi vượt quá hạn ngạch. Trang web Royal Wedding được lưu trữ trên App Engine và nhận được 32.000 yêu cầu mỗi giây. Không có lỗi vượt quá hạn ngạch. Ngoài ra, đã bao giờ nhìn thấy cá voi thất bại trên Twitter, hoặc lỗi quá dung lượng trên Tumblr? Đó thực chất là lỗi vượt quá hạn ngạch của họ.

2. Cơ sở dữ liệu

   • Hành vi cơ sở dữ liệu không giống nhau trong phát triển cục bộ so với các máy chủ thực tế. - Sai

   - Nếu bạn có nghĩa là chạy kho dữ liệu trên máy tính xách tay của bạn chậm hơn so với chạy trên cụm của Máy ứng dụng, thì đúng, nếu không thì không đúng.

   • GQL. Không có gì khác. - Sai

   - Hầu hết các nhà phát triển sử dụng bộ lọc db để truy vấn kho dữ liệu. Thêm vào đó, bạn cũng có thể nói rằng MySQL cho phép "SQL. Không có gì khác."

   • Không có truy vấn nào có thể truy xuất hơn 1000 bản ghi (nghiêm túc nếu bạn muốn cho phép khách hàng của mình có nút một lần nhấp-ngoại tuyến-ngay bây giờ) - Sai.

   - Giới hạn kỷ lục 1000 đã được dỡ bỏ từ lâu. Ngoài ra, hãy cho tôi xem bất kỳ trang nào hướng tới người dùng trên Facebook, Twitter hoặc Tumblr yêu cầu hơn 1000 bản ghi để hiển thị.

   • Nếu bạn cần truy cập tuyến tính vào một lượng lớn hồ sơ để thực hiện một thao tác, bạn sẽ không gặp may (các hệ thống của Google được phân cụm ồ ạt)

   - Tôi thậm chí không chắc chắn những gì bạn nhận được ở đây. Hầu hết mọi người coi tốc độ của cụm khổng lồ của Google là một lợi thế rất lớn của hệ thống.

   • Giá trị Memcache kích thước tối đa là 10 MB. - Trên thực tế, đó là 1 MB cho mỗi mục nhập memcache, giống như mọi cách thực hiện memcache khác.

   • Không thể thực hiện tìm kiếm văn bản đơn giản - Đúng.

   - Đó là một tính năng đó trên boong. Hầu hết các trang web lớn không thực hiện lập chỉ mục tìm kiếm văn bản của riêng họ.

   • Bạn không thể tham gia 2 bảng. - Thật.

   - Các nhà phát triển Máy ứng dụng cần điều chỉnh suy nghĩ của họ từ một truy vấn SQL đa tham gia đơn lẻ sang một số truy vấn riêng lẻ nhỏ hơn hoặc không chuẩn hóa dữ liệu để không cần tham gia.

   • Chậm (Bạn phải đọc về cách tách các bảng bằng cách sử dụng tính kế thừa để bạn có thể tìm kiếm trong một bảng, lấy khóa và sau đó lấy cha mẹ của nó để tránh hiệu suất khử lưu huỳnh) - ???

   - yêu cầu dịch thuật / trích dẫn.

   • Ngoại lệ thời gian chạy "Quá nhiều chỉ mục" - Đúng

   - Có giới hạn số lượng chỉ mục trong một ứng dụng. Tôi chỉ thấy các ứng dụng nghiên cứu học thuật đạt được nó mặc dù.

   • Một thực thể nhiều nhất có thể có 5000 giá trị thuộc tính trong một chỉ mục - Đúng

   - Vì vậy, nếu ai đó có hơn 5000 bạn bè, họ sẽ cần hai thực thể trong nhóm bạn bè.

   • Tên chính của biểu mẫu __*__(bắt đầu và kết thúc bằng hai dấu gạch dưới) được bảo lưu và ứng dụng không nên được sử dụng. - Thật

   -- Nhưng cái gì cơ?

   • Tên khóa được giới hạn ở 500 byte (tôi đoán là được mã hóa UTF-8) - Đúng

   - Một lần nữa, vậy thì sao? Tên khóa không phải để lưu trữ tiểu thuyết, chúng là để xác định duy nhất một thực thể.

3. Ngôn ngữ

   • python hoặc java hoặc Go (bất cứ điều gì khác sẽ phải được dịch sang các ngôn ngữ này) - Một nửa đúng

   - Trên thực tế, bạn cũng có thể chạy bất kỳ ngôn ngữ nào chạy trên JVM, bao gồm PHP và JRuby. Không chắc tại sao đó là một vấn đề, Python và Java là hai ngôn ngữ mạnh mẽ với nhiều công cụ, hướng dẫn và lập trình viên có kinh nghiệm.

4. Sự cố máy chủ

   • Không có IP tĩnh (Vấn đề điều chỉnh và hạn ngạch khi gọi API của bên thứ ba) - Một nửa đúng

   - Hầu hết các API của bên thứ ba đều biết về Máy ứng dụng và / hoặc có mối quan hệ với Google. Một vài lần Twitter đã vô tình chặn App Engine và nó sẽ được sửa trong vòng vài giờ.

   • Mỗi ứng dụng được giới hạn ở 3000 tệp - Một nửa đúng

   - Nếu bạn thực sự cần nhiều hơn 3000 tệp mã cho ứng dụng web của mình, bạn có thể sử dụng nhập khẩu zip (Ngoài ra, bạn có thể đang làm sai).

   • Không kiểm soát HĐH hoặc phần cứng chạy ứng dụng web - Đúng

   - Máy ứng dụng là một Nền tảng như một Dịch vụ . Không phải lo lắng về việc phục vụ HĐH hay phần cứng là những gì mọi người đang trả tiền. Đây là lợi thế chính của App Engine, không phải là giới hạn.

Không, App Engine không phù hợp với ứng dụng có 600 triệu người dùng hoạt động.

Trên thực tế, các ứng dụng lớn này chạy trên cơ sở hạ tầng tùy biến cao từ các trung tâm dữ liệu của riêng họ. Có thể lưu trữ một ứng dụng như vậy với Google, nhưng bạn sẽ làm việc trực tiếp với nhóm bán hàng của họ để thiết kế một giải pháp; các hạn chế hộp cát bạn đã liệt kê ở trên từ lâu sẽ không liên quan.

Nếu bạn chỉ mới bắt đầu, thật ngớ ngẩn khi thiết kế xung quanh giả định rằng bạn sẽ trở nên nổi tiếng như Facebook. Bất kỳ ứng dụng nào có được số lượng lớn như vậy sẽ tăng dần và liên tục bao thanh toán lại. Đầu tiên, lo lắng về việc thiết kế các tính năng sẽ thu hút 600 triệu người dùng. Thiết kế lại việc thực hiện để hỗ trợ cơ sở người dùng đang phát triển là một vấn đề không đáng kể bằng cách so sánh.

Tôi nghĩ rằng những điểm trong Câu hỏi thường gặp đó rơi vào một vài lĩnh vực chính.

Trước hết, có những điểm thực sự có lợi cho khả năng mở rộng, hơn là gây bất lợi. Trong một ứng dụng có khả năng mở rộng cao, một trong những điều bạn phấn đấu là đảm bảo mọi yêu cầu chủ yếu độc lập với các yêu cầu khác và tất cả chúng đều có cùng "kích cỡ" (về cách sử dụng CPU, bộ nhớ, mạng, v.v.).

Bằng cách đó, các yêu cầu có thể được phân phối dễ dàng giữa các nút trong cụm của bạn mà không phải lo lắng về một nhóm các yêu cầu "lớn" bỏ đói các yêu cầu nhỏ hơn trên cùng một nút. Điều này giữ cho cơ sở hạ tầng của bạn đơn giản về bảo trì, hiệu suất và độ tin cậy.

Vì vậy, bao gồm những thứ như:

• Yêu cầu tối đa / kích thước phản hồi
• Yêu cầu thời gian trả lời
• Giới hạn thời gian đáp ứng yêu cầu bên ngoài
• Kích thước tối đa của Memcache (trên thực tế, trong bản dựng mặc định của memcache, kích thước giá trị tối đa là 1 MB, vì vậy rõ ràng Google đang chạy nhị phân tùy chỉnh tăng giới hạn gấp 10 lần)
• Kích thước phản hồi cơ sở dữ liệu tối đa (nghĩa là giới hạn 1.000 hàng)
• Vân vân

Danh mục thứ hai là những thứ đơn giản là lỗi thời:

• Google Go hiện có sẵn dưới dạng ngôn ngữ trên Máy ứng dụng . Về ngôn ngữ hiệu suất cao, bạn không thể giỏi hơn Go. Tôi thực sự rất thích cái này
• Kho dữ liệu có thể thất bại - không đúng với Kho dữ liệu sao chép cao (rõ ràng memcache có thể thất bại, nhưng đó chỉ là bộ đệm)
• Giới hạn số lượng tệp là 3.000 chứ không phải 1.000

Bây giờ, thật tuyệt nếu Google mở cơ sở hạ tầng của họ để cho phép các công việc định kỳ sử dụng Map Giảm và cho phép bạn chạy truy vấn trên toàn bộ tập dữ liệu của mình. Nhưng vào thời điểm bạn thậm chí là một phần đáng kể của 600 triệu người dùng, bạn sẽ trở thành một khách hàng rất lớn của Google và sẽ có nhiều tùy chọn hơn những gì có sẵn trong Máy ứng dụng.

Nếu bạn đưa ra một ý tưởng sẽ thu hút thậm chí 100, hãy để 600, hàng triệu người dùng bạn sẽ có bất kỳ vốn đầu tư mạo hiểm và bất kỳ nhóm công nghệ nào để phát triển và chạy nó trên bất kỳ cơ sở hạ tầng nào. Và bạn cũng sẽ muốn bảo vệ tài sản trí tuệ của mình trong trường hợp đó, GAE sẽ không cung cấp vì Google muốn có quyền truy cập vào mã nguồn của mọi ứng dụng GAE (dù sao bạn cũng không thể thực sự bảo vệ mã Python và Java).
GAE phù hợp cho các doanh nghiệp muốn loại bỏ chi phí cơ sở hạ tầng CNTT của họ và không có nhu cầu bảo vệ mã IP mà chỉ là dữ liệu của họ.