GAE เป็นโครงสร้างพื้นฐานที่สามารถโฮสต์แอปที่ผู้ใช้หลายล้านคนใช้อยู่หรือไม่

ฉันอยากรู้ด้วยข้อ จำกัด ของ GAE ที่ระบุไว้ด้านล่างเป็นไปได้ไหมที่จะสร้างแอปโซเชียลที่ยอดเยี่ยม (เช่น Facebook) ด้วยการโฮสต์แอพนั้นบน GAE

กล่าวอีกนัยหนึ่งคือ GAE โครงสร้างพื้นฐานที่สามารถโฮสต์แอปที่ใช้งานโดยผู้ใช้งาน 600 ล้านคน

ข้อ จำกัด ที่ฉันได้รับจากกระดานสนทนา / บล็อก (โปรดเพิ่มลงในรายการหากคุณพบสิ่งที่ขาดหายไป):

1. คำขอ HTTP / ตอบกลับ

   • ขนาดคำขอสูงสุด: 32 MB
   • ขนาดการตอบสนองสูงสุด: 32 MB
   • คำขอทั้งหมดจะต้องตอบกลับภายใน 30 วินาทีมิฉะนั้น GAE จะส่ง DeadlineExceededException
   • งาน cron แต่ละงานจะต้องดำเนินการภายใน 10 นาที
   • งาน Cron ไม่สามารถใช้การลดแผนที่ได้
   • GET หรือ POST ไปยังเว็บไซต์อื่นจะถูกยกเลิกหลังจาก 5 วินาที คุณสามารถกำหนดค่าให้รอจนถึงสูงสุด 10 วินาที (เซิร์ฟเวอร์ระดับกลางจำเป็นต้องทำงานกับ Twitter และ Facebook หลายครั้ง)
   • ลูกค้าไม่สามารถเชื่อมต่อกับ GAE ผ่าน FTP (HTTP และ HTTPS เท่านั้น)
   • ไม่มี https สำหรับโดเมนที่กำหนดเอง สำหรับโดเมนของคุณ -app-id.appspot.com เท่านั้น
   • หากคุณได้รับผู้ใช้จำนวนมากคุณจะได้รับข้อผิดพลาด "เกินโควต้า"

2. ฐานข้อมูล

   • พฤติกรรมฐานข้อมูลไม่เหมือนกันในการพัฒนาท้องถิ่นมากกว่าในเซิร์ฟเวอร์จริง
   • gql ไม่มีอะไรอีกแล้ว.
   • ไม่มีคิวรีใดที่สามารถดึงข้อมูลได้มากกว่า 1,000 รายการ (แย่มากหากคุณต้องการอนุญาตให้ไคลเอนต์ของคุณมีปุ่มคลิกเดียวไปเลยออฟไลน์)
   • หากคุณต้องการเข้าถึงเชิงเส้นเพื่อบันทึกจำนวนมากเพื่อดำเนินการคุณจะโชคไม่ดี (ระบบของ Google มีการจัดกลุ่มอย่างหนาแน่น)
   • ค่า Memcache ขนาดสูงสุดคือ 1 MB
   • ไม่สามารถค้นหาข้อความธรรมดา ๆ ได้
   • คุณไม่สามารถเข้าร่วม 2 ตาราง
   • ช้า (คุณต้องอ่านเกี่ยวกับวิธีการแยกตารางโดยใช้การสืบทอดเพื่อให้คุณสามารถค้นหาในตารางรับคีย์จากนั้นรับพาเรนต์เพื่อหลีกเลี่ยงประสิทธิภาพในการกำจัด deserialization)
   • ข้อยกเว้นรันไทม์ "ดัชนีมากเกินไป"
   • เอนทิตีสามารถมีได้สูงสุด 5,000 ค่าคุณสมบัติในดัชนี
   • ชื่อคีย์ของฟอร์ม* (เริ่มต้นและสิ้นสุดด้วยเครื่องหมายขีดล่างสองอัน) ถูกสงวนไว้และไม่ควรใช้โดยแอปพลิเคชัน
   • ชื่อคีย์ถูก จำกัด 500 ไบต์ (เข้ารหัส UTF-8 ฉันเดา)

3. ภาษา

   • python หรือ java หรือ Go (หรือภาษาที่ใช้ JVM เช่น Groovy, Scala และอื่น ๆ )

4. ปัญหาเซิร์ฟเวอร์

   • ไม่มี IP แบบคงที่ (อาจมีปัญหาการควบคุมปริมาณและโควต้าที่เรียก API บุคคลที่สาม)
   • แต่ละแอปพลิเคชั่นถูก จำกัด ไว้ที่ 3000 ไฟล์
   • ไม่มีการควบคุมระบบปฏิบัติการหรือฮาร์ดแวร์ที่ใช้งานเว็บแอป

ฉันคิดว่าสิ่งที่ทำให้ฉันรำคาญเกี่ยวกับคำถามนี้คือคุณได้ใช้ถ้อยคำและโหลดด้วย "ข้อเท็จจริง" เพื่อพยายามรวบรวมหมายเลขที่ชัดเจน

ความจริงก็คือคุณสามารถพัฒนาแอพ App Engine ที่จำลองคุณสมบัติของ Facebook, Twitter หรือ Tumblr และสมมติว่าแอพเขียนได้ดีก็จะขยายเพื่อรองรับผู้ใช้หลายร้อยล้านคน เหตุผลหลักที่คุณไม่ต้องการ (ซึ่งไม่น่าจะเป็นข้อพิจารณาสำหรับคุณ) คือค่าใช้จ่ายในการเรียกใช้บริการที่มีขนาดตาม App Engine

นอกจากนี้ฉันไม่เห็นว่าข้อ จำกัด ใด ๆ ที่คุณระบุไว้จะป้องกันไม่ให้คุณพัฒนาแอปดังกล่าว

1. คำขอ HTTP / ตอบกลับ

   • ขนาดคำขอสูงสุด: 10 MB - ผิดยกเป็น 32MB
   • ขนาดการตอบสนองสูงสุด: 10 MB - ผิดเพิ่มเป็น 32MB

   - หากคุณกำลังพัฒนาแอพโซเชียลที่ต้องส่งหน้าเว็บที่มีขนาดใหญ่กว่า 10MB บ่อยครั้งคุณอาจทำผิด นอกจากนี้หากคุณต้องการส่งเนื้อหาที่มีขนาดใหญ่กว่า 32MB คุณสามารถใช้ blobstore สำหรับไฟล์สูงสุด 2GB

   • คุณไม่สามารถเข้าถึงระบบไฟล์ได้ (ลืมเกี่ยวกับการบันทึกการอัปโหลดไปยังระบบไฟล์) - ผิด คุณสามารถอ่านจากระบบไฟล์โลคัลและสามารถอัพโหลดและอ่าน / เขียนไฟล์ไปที่ blobstore

   - ไม่มีทางที่ Facebook, Twitter หรือ Tumblr กำลังจะอัพโหลดผู้ใช้และคัดลอกไปยังโฟลเดอร์ ไม่ใช่ปัญหา

   • คำขอทั้งหมดจะต้องตอบกลับภายใน 10 นาทีมิฉะนั้น GAE จะส่ง DeadlineExceededException - ผิด จริง ๆ แล้ว 30 วินาที

   - หากคุณต้องการเวลานานกว่า 30 วินาทีเพื่อส่งผลลัพธ์ไปยังคำขอของผู้ใช้คุณอาจทำผิดพลาด

   • งาน cron แต่ละงานต้องดำเนินการภายใน 30 วินาที - ผิด 10 นาที

   - หากคุณไม่สามารถแบ่งงานที่มีความยาวออกเป็นชิ้น ๆ นานถึง 10 นาที A: คุณอาจทำผิดและ B: ตอนนี้คุณสามารถย้ายงานนั้นไปยังอินสแตนซ์แบ็กเอนด์ซึ่งไม่มีการ จำกัด เวลาสำหรับคำขอ

   • งาน 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 ไม่มีอะไรอีกแล้ว"

   • ไม่มีคิวรีใดที่สามารถดึงข้อมูลได้มากกว่า 1,000 รายการ (แย่มากหากคุณต้องการอนุญาตให้ไคลเอนต์ของคุณมีปุ่มแบบคลิกเดียวคลิกเลยออฟไลน์) - เท็จ

   - มีการ จำกัด การบันทึก 1,000 ครั้งเป็นเวลานานแล้ว นอกจากนี้ให้แสดงหน้าผู้ใช้งานใด ๆ บน Facebook, Twitter หรือ Tumblr ที่ต้องการเรกคอร์ดมากกว่า 1,000 รายการ

   • หากคุณต้องการเข้าถึงเชิงเส้นเพื่อบันทึกจำนวนมากเพื่อดำเนินการคุณจะโชคไม่ดี (ระบบของ Google มีการจัดกลุ่มอย่างหนาแน่น)

   - ฉันไม่แน่ใจด้วยซ้ำว่าคุณกำลังมาที่นี่ คนส่วนใหญ่มองว่าความเร็วของคลัสเตอร์ขนาดใหญ่ของ Google นั้นเป็นข้อได้เปรียบอย่างมากของระบบ

   • ค่า Memcache ขนาดสูงสุดคือ 10 MB - ที่จริงแล้วคือ 1MB ต่อรายการ memcache เช่นเดียวกับการใช้งาน memcache อื่น ๆ

   • ไม่สามารถค้นหาข้อความธรรมดา - จริง

   - เป็นคุณลักษณะที่อยู่บนดาดฟ้า ไซต์ขนาดใหญ่ส่วนใหญ่ไม่ทำการจัดทำดัชนีการค้นหาข้อความของตนเอง

   • คุณไม่สามารถเข้าร่วม 2 ตาราง - จริง

   - นักพัฒนา App Engine จำเป็นต้องปรับความคิดของตนเองจากการสืบค้น SQL แบบรวมกลุ่มหลายครั้งใหญ่เป็นแบบค้นหารายย่อยที่มีขนาดเล็กกว่าหลายรายการหรือลดความซ้ำซ้อนของข้อมูลเพื่อไม่ให้เข้าร่วม

   • ช้า (คุณต้องอ่านเกี่ยวกับวิธีการแยกตารางโดยใช้การสืบทอดเพื่อให้คุณสามารถค้นหาในตารางรับคีย์จากนั้นรับพาเรนต์เพื่อหลีกเลี่ยงประสิทธิภาพการกำจัด deserialization) - ???

   - ต้องการการแปล / การอ้างอิง

   • ข้อยกเว้นรันไทม์ "ดัชนีมากเกินไป" - จริง

   - มีการ จำกัด จำนวนดัชนีในแอปเดียว ฉันเพิ่งเห็นงานวิจัยทางวิชาการตีมัน

   • เอนทิตีสามารถมีค่าคุณสมบัติได้ 5,000 ค่าในดัชนี - จริง

   - ดังนั้นหากใครบางคนมีเพื่อนมากกว่า 5,000 คนพวกเขาจะต้องใช้สองหน่วยงานในกลุ่มเพื่อน

   • ชื่อคีย์ของแบบฟอร์ม __*__ (เริ่มต้นและสิ้นสุดด้วยเครื่องหมายขีดล่างสองอัน) ถูกสงวนไว้และไม่ควรใช้โดยแอปพลิเคชัน - จริง

   - แต่อะไรนะ?

   • ชื่อคีย์ถูก จำกัด 500 ไบต์ (เข้ารหัส UTF-8 ฉันเดา) - จริง

   - อีกครั้งเพื่ออะไร ชื่อคีย์ไม่ได้มีไว้สำหรับจัดเก็บโนเวลลาสสำหรับการระบุเอนทิตีเฉพาะ

3. ภาษา

   • python หรือ java หรือ Go (สิ่งอื่นจะต้องแปลเป็นภาษาเหล่านี้) - ครึ่งจริง

   - จริงๆแล้วคุณสามารถใช้ภาษาใดก็ได้ที่ทำงานบน JVM รวมถึง PHP และ JRuby ไม่แน่ใจว่าทำไมถึงเป็นปัญหา แต่ Python และ Java เป็นภาษาที่ทรงพลังสองภาษาพร้อมด้วยเครื่องมือการสอนและโปรแกรมเมอร์ที่มีประสบการณ์มากมาย

4. ปัญหาเซิร์ฟเวอร์

   • ไม่มี IP แบบคงที่ (ปัญหาการควบคุมปริมาณและโควต้าเรียก API บุคคลที่สาม) - ครึ่งจริง

   - API บุคคลที่สามส่วนใหญ่รู้จัก App Engine และ / หรือมีความสัมพันธ์กับ Google ไม่กี่ครั้ง Twitter ได้บล็อก App Engine โดยไม่ตั้งใจและได้รับการแก้ไขภายในไม่กี่ชั่วโมง

   • แต่ละแอปพลิเคชั่นถูก จำกัด ไว้ที่ 3000 ไฟล์ - ครึ่งจริง

   - หากคุณต้องการไฟล์โค้ดมากกว่า 3,000 ไฟล์สำหรับเว็บแอปพลิเคชันของคุณคุณสามารถใช้การนำเข้ารหัสไปรษณีย์ได้ (อาจเป็นเพราะคุณทำผิด)

   • ไม่มีการควบคุม OS หรือฮาร์ดแวร์ที่ใช้งานเว็บแอพ - จริง

   - App Engine เป็นแพลตฟอร์มในรูปแบบบริการ ไม่ต้องกังวลกับการให้บริการระบบปฏิบัติการหรือฮาร์ดแวร์เป็นสิ่งที่ผู้คนจ่ายเงิน นี่เป็นข้อได้เปรียบที่สำคัญของ App Engine ไม่ใช่ข้อ จำกัด

ไม่ App Engine ไม่เหมาะสำหรับแอปที่มีผู้ใช้งาน 600 ล้านคน

แอพพลิเคชั่นขนาดใหญ่นี้ทำงานบนโครงสร้างพื้นฐานที่ปรับแต่งได้ตามความต้องการจากดาต้าเซ็นเตอร์ของตัวเอง อาจเป็นไปได้ที่จะโฮสต์แอปดังกล่าวกับ Google แต่คุณจะทำงานร่วมกับทีมขายโดยตรงเพื่อออกแบบโซลูชัน ข้อ จำกัด ของแซนด์บ็อกซ์ที่คุณระบุไว้ข้างต้นอาจจะไม่เกี่ยวข้องกันนานนัก

หากคุณเพิ่งเริ่มต้นมันเป็นเรื่องโง่ที่จะออกแบบตามสมมติฐานที่ว่าคุณกำลังจะได้รับความนิยมเหมือน Facebook แอพใดก็ตามที่มีขนาดใหญ่นี้จะเพิ่มขึ้นเรื่อย ๆ ก่อนอื่นต้องกังวลเกี่ยวกับการออกแบบคุณสมบัติที่จะดึงดูดผู้ใช้ 600 ล้านคน การออกแบบการนำไปใช้งานใหม่เพื่อสนับสนุนฐานผู้ใช้ที่เพิ่มขึ้นเป็นปัญหาเล็กน้อยโดยการเปรียบเทียบ

ฉันคิดว่าคะแนนในคำถามที่พบบ่อยนั้นแบ่งออกเป็นสองประเด็นหลัก

ก่อนอื่นมีจุดที่จริง ๆ แล้วเพื่อประโยชน์ในการปรับขยายได้มากกว่าความเสียหาย ในแอปพลิเคชันที่ปรับขนาดได้สูงสิ่งหนึ่งที่คุณมุ่งมั่นคือการทำให้แน่ใจว่าทุกคำร้องขอนั้นเป็นอิสระจากคำขออื่นและส่วนใหญ่นั้นมีขนาด "เท่ากัน" (ในแง่ของการใช้งาน CPU หน่วยความจำเครือข่าย ฯลฯ )

ด้วยวิธีนี้การร้องขอสามารถกระจายได้อย่างง่ายดายระหว่างโหนดในคลัสเตอร์ของคุณโดยไม่ต้องกังวลเกี่ยวกับกลุ่มของการร้องขอ "ใหญ่" ที่กำลังหิวโหยคำขอที่มีขนาดเล็กลงบนโหนดเดียวกัน สิ่งนี้ทำให้โครงสร้างพื้นฐานของคุณง่ายในแง่ของการบำรุงรักษาประสิทธิภาพและความน่าเชื่อถือ

เพื่อให้ครอบคลุมสิ่งต่าง ๆ เช่น:

• ขนาดคำขอ / การตอบกลับสูงสุด
• ร้องขอเวลาตอบกลับ
• การ จำกัด เวลาตอบสนองคำขอภายนอก
• ขนาดสูงสุด Memcache (ในความเป็นจริงในการสร้างเริ่มต้นของ memcache ขนาดค่าสูงสุดคือ 1 MB ดังนั้นเห็นได้ชัดว่า Google กำลังทำงานไบนารีที่กำหนดเองที่เพิ่มขีด จำกัด ที่ 10 เท่า)
• ขนาดการตอบสนองฐานข้อมูลสูงสุด (เช่นขีด จำกัด 1,000 แถว)
• ฯลฯ

ประเภทที่สองคือสิ่งที่ล้าสมัย:

• Google Go มีให้บริการเป็นภาษาใน App Engine แล้วแล้ว ในแง่ของภาษาที่มีประสิทธิภาพสูงคุณจะไม่ได้ดีไปกว่า Go ฉันชอบอันนี้จริงๆ
• ดาต้าสโตร์สามารถล้มเหลว - ไม่เป็นความจริงกับดาต้าเรเตอร์การจำลองแบบสูง (เห็นได้ชัดว่า memcache อาจล้มเหลว แต่เป็นเพียงแคช)
• ขีด จำกัด ของจำนวนไฟล์คือ 3,000 ไม่ใช่ 1,000

ตอนนี้มันจะดีถ้า Google เปิดโครงสร้างพื้นฐานเพื่อให้งาน cron ใช้การลดแผนที่และให้คุณเรียกใช้แบบสอบถามมากกว่าชุดข้อมูลทั้งหมดของคุณ แต่เมื่อถึงเวลาที่คุณมีผู้ใช้เพียง 600 ล้านคนคุณก็จะเป็นลูกค้ารายใหญ่ของ Google อยู่แล้วและจะมีตัวเลือกมากกว่าสิ่งที่มีอยู่ใน App Engine

หากคุณมีความคิดที่จะดึงดูดผู้ใช้ 100 คนผู้ใช้ 600 ล้านคนคุณจะมีเงินลงทุนและทีมเทคโนโลยีเพื่อพัฒนาและใช้งานบนโครงสร้างพื้นฐานใด ๆ และคุณจะต้องการปกป้องทรัพย์สินทางปัญญาของคุณในกรณีเช่นนั้นซึ่ง GAE จะไม่จัดให้เนื่องจาก Google ต้องการเข้าถึงซอร์สโค้ดของแอป GAE ทุกแอป (คุณไม่สามารถป้องกัน Python และรหัส Java ได้)
GAE เหมาะสำหรับองค์กรที่ต้องการกำจัดค่าใช้จ่ายด้านโครงสร้างพื้นฐานไอทีและไม่จำเป็นต้องปกป้องรหัส IP แต่เป็นข้อมูลเท่านั้น