แต่ไม่รู้ว่าเยอะขนาดนี้
- 1,000,000,000 page view ต่อวัน
- 212,000,000 registered user
- 1,000,000,000 photos
- 2,000,000 GB data
- 26,000,000,000 sql execute ต่อวัน
(อะไรวะ เฉลี่ยหนึ่งหน้า(page view) พ่อล่อไป 26 sql เลยเหรอ) - 3,000,000,000 api call ต่อเดือน
architecture เป็นไงบ้างหรือ
- scale horizontal -> parallel boxes
- presentation layer -> MSXML (พัฒนาเอง)
- ใช้แค่ servlet, connection pools
ภาษาอังกฤษ เขาใช้คำว่า "Throw out most of J2EE" - ไม่ใช้ session state
ถ้าจำเป็นต้องมี ก็จะใช้ cookie หรือ database ชั่วคราว - app server ใช้ WebSphere (jdk 1.3)
ทายสิว่าใช้กี่ตัว
คำตอบคือ 15,000 - Database -> oracle
แค่ 200 database
โดย split database ตาม functional - no stored procedures (บ้านเราคงไม่ชอบแนวนี้)
- หลีกเลี่ยงการใช้ cpu ใน database layer
ฉนั้น join กับ sorting กรุณาออกไปทำที่ application layer - minimize db transaction
แค่เห็นก็เหนื่อยแล้ว นี่ยังไม่พูดเรื่อง searhing กับ deployment
ใครอยากรู้ต่อ ลองอ่าน ebay presentation ดู
Note: นึกถึง project เมื่อ 2 ปีก่อน
ผมเคยมอง architecture ตรงข้ามกับ
พวกผู้ชำนาญการจากบริษัท IBM กับ คณะที่ปรึกษา (อาจารย์มหาวิทยาลัยมีชื่อแห่งหนึ่ง)
รวมทั้ง sales จาก IBM
ตอนนั้น production จะต้อง deploy บน box 4 cpu กับ box 2 cpu
ผมบอกให้ใช้ 2 cpu เป็น database server
สวน app server ให้ใช้ 4 cpu box
ทางฝั่งนู้น บอก "ไม่ไช่ๆ จากประสบการณ์ของผู้เชี่ยวชาญ
database box ต้องใช้ 4 cpu ต่างหาก"
แล้วก็ดื้อ config เครื่องไปตามนั้น
ถึงวันใช้จริง load ฝั่ง database เฉลี่ยไม่เกิน 10 %
ส่วนฝั่ง app อยู่แถว 60 % ถ้าเจอ spike ก็พุ่งปรึ๊ดเกือบติดเพดาน
ผ่านไป 2 เดือนพวกผู้เชี่ยวชาญก็เลยยอม โอน cpu จาก database
มาให้ application server
เวลาผ่านไปอีก 1 ปี ก็มีการย้ายเครื่องขึ้น linux mainframe
พวกผู้ชำนาญการก็ยังไม่เข็ด
จัดสรร computing resource ให้ database server เยอะกว่า app
แต่สุดท้ายก็ต้องโอน resource กลับมาให้ app อยู่ดี
เรื่องนี้สอนให้รู้ว่า
1. ผู้เชี่ยวชาญ ถ้าใช้ประสบการณ์เดิมๆ มาตัดสิน
บางครั้งก็เดาพลาดได้เหมือนกัน
2. คนเขียนโปรแกรมย่อมรู้ดีว่าตัวเองเขียน app ให้มี nature แบบไหน
