ในบล็อกโพสต์ล่าสุด ผมอภิปรายเมื่อไหร่ที่คุณต้อง scale MongoDB ในโพสต์นี้ โฟกัสที่วิธี scale MongoDB
MongoDB version 3.0 นำเสนอ WiredTiger เป็น default storage engine MongoDB ตั้งแต่นั้นมาสามารถให้สองแนวทางเมื่อพูดถึง scalability Mongo ตอนนี้สามารถขยาย vertically และ horizontally ทั้งสองแนวทางสมควรได้รับการตรวจสอบอย่างใกล้ชิด
Scaling Vertically
Scaling vertically เพิ่ม computing resources เช่น จำนวนและประเภทของ CPUs หรือปริมาณ RAM หรือ disk space ด้วยสิ่งนี้ในใจ เมื่อ scaling vertically กับ WiredTiger คุณต้องระบุว่าทรัพยากรไหนมีส่วนทำให้เกิด bottleneck (ไม่ว่าจะเป็น CPU/RAM/ disk space หรือ combination บางอย่าง)
Note on WiredTiger RAM
หาก RAM ที่จัดสรรน้อยกว่า 1GB WiredTiger โดยปกติจะ default ไปที่ 256MB หรือ 50 เปอร์เซ็นต์ของ RAM ที่มีอยู่ ผลคือ WiredTiger cache ต้อง resize หากจัดสรร RAM มากขึ้น
Scaling Horizontally
Scaling horizontally แจกจ่าย computing resources ข้าม network โดยปกติโดยการเพิ่ม servers เพื่อกระจายข้อมูลข้าม multiple nodes เมื่อพวกเขาถูกเพิ่ม MongoDB ใช้ database architecture ที่เรียกว่า sharding ซึ่งใช้ key ranges เพื่อ partition data ที่กระจายไปใน multiple database instances
Setting Up the Sharding Infrastructure
Physical components ที่เกี่ยวข้องในการตั้งค่า sharding configuration ต้องการรายการต่อไปนี้
- Mongos ทำหน้าที่เป็น query router
- Config servers เก็บ sharding metadata
- Data nodes เก็บ actual data
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ physical components เยี่ยมชม MongoDB Overview ของเรา
Defining Shard Keys
หลังจากตั้งค่า physical sharding infrastructure แล้ว ให้โฟกัสที่ logical aspect ของ sharding Shard keys แทน fields ต่างๆ ภายใน collection ที่ MongoDB ใช้ในการ partition data สะดวกที่ Mongo ให้คุณกำหนด keys เหล่านี้
เพื่อระบุ fields ที่เกี่ยวข้องกับการ implement shard keys:
- ระบุ collections ที่จะ shard Collections ที่ใหญ่กว่า 200MB และข้อมูลสามารถกระจายได้อย่างสม่ำเสมอ เป็น good candidates สำหรับ sharding
- สร้างหรือคิดค้น shard key ที่เหมาะสม เมื่อสร้าง shard key พิจารณาคำแนะนำและคำถามต่อไปนี้:
- ได้ insight เข้าไปในลักษณะที่ application โต้ตอบกับฐานข้อมูล
- พิจารณาว่า application เป็น read-heavy หรือ write-heavy หรือ balanced อย่างสม่ำเสมอ
- กิจกรรมสำคัญที่สุดต่อฐานข้อมูลคืออะไร? ตัวอย่างเช่น application อาจเขียนข้อมูลจำนวนมากไปที่ฐานข้อมูล แตกิจกรรมสำคัญที่สุดอาจเกี่ยวกับ queries ที่คืนค่าข้อมูลในเวลาน้อยกว่า 100 ms
- Expected weekly และ monthly patterns ของ data growth คืออะไร?
- มี pain หรือ problem areas ที่ต้องจัดการไหม เช่น slow queries?
- Application วุ่นวายในชั่วโมง บางวันของสัปดาห์ เดือน หรือปี? หรือวุ่นวายตลอดเวลา?
หลังจากสำรวจประเด็นเหล่านี้ คุณสามารถเริ่ม detailed analysis ได้ บล็อกโพสต์ถัดไปจะพูดถึงวิธีหา shard key ที่เหมาะสม
