เว็บไซต์ตอบสนองช้ามากโดยใช้ฐานข้อมูลระยะไกล

ฉันต้องการสองเว็บไซต์เดียวกันเพื่อแชร์ฐานข้อมูลเดียวกัน เซิร์ฟเวอร์หนึ่งอยู่ในเอเชีย โฮสต์เว็บไซต์และฐานข้อมูล เซิร์ฟเวอร์อื่นอยู่ในสหรัฐอเมริกา โฮสต์เว็บเดียวกันผ่านฐานข้อมูลระยะไกล อย่างไรก็ตามเว็บในสหรัฐอเมริกาตอบสนองช้ามาก แต่เมื่อย้ายฐานข้อมูลไปยังเซิร์ฟเวอร์ภายใน (เซิร์ฟเวอร์ของสหรัฐอเมริกา) เว็บตอบสนองเร็ว จะเพิ่มความเร็วการเชื่อมต่อระหว่างเซิร์ฟเวอร์ในสหรัฐอเมริกาและฐานข้อมูลในเอเชียได้อย่างไร?

ฉันใช้ Centos7+Nginx+MySQL

จะเพิ่มความเร็วการเชื่อมต่อระหว่างเซิร์ฟเวอร์ในสหรัฐอเมริกาและฐานข้อมูลในเอเชียได้อย่างไร?

คุณคงไม่สามารถ สหรัฐฯ-เอเชียอยู่ห่างไกลกัน และมีความหน่วงแฝงเข้ามาเกี่ยวข้อง พูดง่ายๆ ก็คือ แสงมีความเร็วจำกัด

คุณควรมองหาทางเลือกอื่นๆ ในการสืบค้นฐานข้อมูลระยะไกล เช่น การแคชเนื้อหาในหลายตำแหน่ง การใช้ CDN หรือการใช้รูปแบบการจำลองฐานข้อมูล เพื่อให้คุณสามารถมีสำเนาข้อมูลในเครื่องได้

เว็บแอปพลิเคชันของคุณสร้างการสืบค้นฐานข้อมูลแยกกันหลายรายการหรือไม่ ข้อความค้นหาหนึ่งรายการขึ้นอยู่กับข้อความค้นหาก่อนหน้า หรือมีข้อความค้นหาอิสระที่ทั้งสองอาจทำงานพร้อมกันเพื่อซ้อนทับเวลาแฝง

หากเป็นอย่างหลัง ตรวจสอบให้แน่ใจว่าสิ่งนั้นเกิดขึ้นจริงในภาษาโปรแกรมใดก็ตามที่คุณใช้ ไม่ใช่การทำให้ข้อความค้นหาของคุณเป็นอนุกรมโดยไม่จำเป็น

หากยังไม่เพียงพอหรือเป็นไปไม่ได้ คุณจะต้องลดเวลาแฝงไปกลับระหว่างเว็บเซิร์ฟเวอร์และฐานข้อมูลด้วยวิธีใดวิธีหนึ่ง โดยการจำลองฐานข้อมูลเพื่อให้คุณสามารถมีสำเนาในเครื่อง แคชส่วนที่ "ร้อน" บางส่วนที่ไม่ เปลี่ยนแปลงบ่อยครั้ง หรือสิ่งอื่นๆ เช่น การแคชผลลัพธ์สุดท้ายของเว็บเซิร์ฟเวอร์หรือสิ่งอื่นๆ ที่ CDN สามารถทำได้ (ดูคำตอบของ vidarlo)

คุณไม่สามารถพัฒนาความเร็วแสงได้ _{{ต้องการการอ้างอิง}}

แทนที่จะสอบถามข้ามทวีป คุณอาจต้องพิจารณาว่า MySQL เสนอการจำลองแบบใด คุณต้องมีเว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์ฐานข้อมูลในเอเชียและทำซ้ำในแต่ละตำแหน่ง (สหรัฐอเมริกา สหภาพยุโรป แอฟริกา ME ฯลฯ) เมื่อเว็บเซิร์ฟเวอร์เขียน ฐานข้อมูลในเครื่องจะได้รับการอัปเดตทันที จากนั้นการอัปเดตนั้นจะถูกส่งไปยังเซิร์ฟเวอร์ฐานข้อมูลระยะไกลโดย MySQL เป็นการภายใน

แง่บวก:

• เซสชันของผู้ใช้อาจพลิกจากไซต์หนึ่งไปอีกไซต์หนึ่ง และบันทึกฐานข้อมูลจะสอดคล้องกัน
• คุณต้องสำรองข้อมูลเซิร์ฟเวอร์ฐานข้อมูลเพียงเครื่องเดียวเพื่อรับข้อมูลจำนวนมาก
• สามารถเพิ่มความซ้ำซ้อนและความทนทานต่อความผิดพลาดได้โดยการมีไซต์หลัก และถ้าไซต์นั้นหยุดทำงาน ก็จะล้มเหลวในไซต์ระยะไกล
• สามารถปรับขนาดเว็บเซิร์ฟเวอร์ตามแนวนอนในแต่ละไซต์เพื่อให้มีการบำรุงรักษาในช่วงหยุดทำงาน เช่น การอัปเดต/รีบูต
• คุณยังสามารถมีเซิร์ฟเวอร์ DB สำรองภายในเครื่องสำหรับแต่ละไซต์ ซึ่งช่วยให้สามารถสำรองข้อมูลอีกครั้งได้โดยไม่ต้องล้มเหลว

เชิงลบ:

• เพิ่มความซับซ้อน
• ค่าใช้จ่ายที่เพิ่มขึ้นของทรัพยากรมากขึ้น

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

การออกแบบตามปกติของเว็บไซต์ที่มีฐานข้อมูลสำรองจะใช้การสืบค้นฐานข้อมูลเพียงเล็กน้อย (หรือมากกว่านั้น เช่น 50 หรือ 100 รายการ) เพื่อสร้างหน้าเว็บเพจเดียวเพื่อตอบสนองคำขอของเบราว์เซอร์

ทุกๆ แบบสอบถามเหล่านี้ต้องใช้เวลาไป-กลับระหว่างเว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์ฐานข้อมูล สิ่งนี้สามารถเพิ่มได้อย่างรวดเร็ว

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

ดูความแตกต่าง? 2 เซิร์ฟเวอร์ไปกลับระหว่างผู้ใช้กับเซิร์ฟเวอร์และเซิร์ฟเวอร์ไป-กลับหลายครั้ง (น่าจะหลายสิบ) การเชื่อมต่อระหว่างเซิร์ฟเวอร์อาจเร็วขึ้น แต่ไม่มาก

นี่คือสาเหตุที่การตั้งค่าของคุณไม่มีจุดหมาย

ทำแล้วได้อะไร?

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

ประสบการณ์ของผู้ใช้ในปัจจุบันถูกควบคุมโดยคุณสมบัติการเชื่อมต่อของผู้ใช้เป็นอันดับแรก และแทบจะไม่ขึ้นอยู่กับตำแหน่งเว็บเซิร์ฟเวอร์

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

มีเคล็ดลับ CDN ที่อาจปรับปรุงเวลาตอบสนองของคุณแม้กับเซิร์ฟเวอร์เดียว โดยดูเหมือนว่าคุณมีเซิร์ฟเวอร์หลายเครื่องในสถานที่ต่างกัน ผู้ให้บริการ CDN รายใหญ่อย่าง Cloudflare หรือ Akamai มีเครื่องมือที่ทรงพลังจริงๆ

2. ใช้การจำลองฐานข้อมูลและดูแลฐานข้อมูลใกล้กับเว็บเซิร์ฟเวอร์ทั้งสอง สิ่งนี้อาจต้องมีการคิดใหม่อย่างลึกซึ้งเกี่ยวกับการออกแบบแอปพลิเคชัน รวมถึงชุดทักษะที่กว้างขึ้นและ/หรือสิทธิ์ใช้งาน DB ที่มีราคาแพงกว่ามาก

3. ตรวจสอบคุณสมบัติการเชื่อมต่อฐานข้อมูลของคุณที่ปลายทั้งสองด้าน (เซิร์ฟเวอร์ db และเว็บเซิร์ฟเวอร์)

• การบันทึกที่กว้างขวาง การพิสูจน์ตัวตนที่ซับซ้อน และการย้อนกลับ DNS ในฝั่งเซิร์ฟเวอร์ db อาจทำให้ผลลัพธ์ของการสืบค้น db แต่ละรายการล่าช้าได้ค่อนข้างมาก
• การใช้การเชื่อมต่อ db แบบต่อเนื่องบนฝั่งเว็บเซิร์ฟเวอร์สามารถลดการสืบค้น db แบบไปกลับได้ 2-5 เท่า

4. ออกแบบแอปพลิเคชันของคุณใหม่เพื่อใช้แบบสอบถาม db น้อยลงต่อหน้า ในทางกลับกัน อาจส่งผลให้ข้อความค้นหาซับซ้อนขึ้น ช้าลง และยากต่อการรักษา ระยะทางของคุณอาจแตกต่างกันไป

ระยะทางไม่ได้ทำให้ฐานข้อมูลช้าลง แต่เพิ่มเวลาแฝง

การลดเวลาในการตอบสนองรวมถึง

• เรียกใช้หลายแบบสอบถามพร้อมกัน
• ลดจำนวนคำถามที่ต้องการ
• แคชผลลัพธ์ในเครื่อง
• การเก็บสำเนาของฐานข้อมูลแบบอ่านอย่างเดียวไว้ในเครื่อง

บางเลเยอร์ของ SQL wrapper เช่น สร้างคิวรีพิเศษจำนวนมากเพื่อกำหนดโครงสร้างฐานข้อมูล คุณอาจต้องออกแบบใหม่เพื่อใช้ SQL ดั้งเดิมแทน

หากเป็นไปได้ให้ใช้การรวมแทนการวนซ้ำของคิวรี หากจำเป็น คุณสามารถอัปเดตและแทรกหลายแถวได้ แต่ฉันไม่รู้ไวยากรณ์ที่ดีที่สุดที่จะใช้ใน mysql

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

อีกทางเลือกหนึ่งคือการมอบฉันทะให้กับแบบสอบถาม ด้วยพร็อกซี คุณสามารถตั้งค่าเว็บเซิร์ฟเวอร์ของสหรัฐอเมริกาเพื่อส่งต่อไปยังเว็บเซิร์ฟเวอร์ในเอเชียที่อยู่ในฐานข้อมูล อาปาเช่ ทำได้แน่นอน และผมเชื่อเช่นนั้น งินซ์ ได้เช่นกัน (แต่ฉันคุ้นเคยกับการกำหนดค่า Nginx น้อยกว่ามาก) วิธีนี้จะแก้ไขปัญหาเกี่ยวกับการวนซ้ำไปมาระหว่างเว็บเซิร์ฟเวอร์และฐานข้อมูลที่ช้าโดยต้องเพิ่มการสื่อสารผ่านพร็อกซีที่ด้านบน แต่การสื่อสารด้วยพร็อกซีอาจเป็นคู่คำขอ/การตอบกลับเดียว ซึ่งโดยทั่วไปจะเร็วกว่า

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

การมอบฉันทะยังช่วยหลีกเลี่ยงการทำซ้ำทั้งสองทิศทาง หากทั้งเว็บเซิร์ฟเวอร์ท้องถิ่น (สหรัฐอเมริกา) และเว็บเซิร์ฟเวอร์ระยะไกล (เอเชีย) ดำเนินการเขียน การดำเนินการเขียนทั้งหมดจะทำได้โดยตรงไปยังเซิร์ฟเวอร์ฐานข้อมูลที่มีสิทธิ์ได้ง่ายขึ้น วิธีนี้จะหลีกเลี่ยงปัญหาการแก้ไขที่ขัดแย้งกันซึ่งแต่ละรายการพยายามเขียนทับกันในระยะไกล แต่ตอนนี้ เราอาจกลับมาสร้างคำขอฐานข้อมูลระยะไกลแบบไป-กลับหลายครั้ง (แม้ว่าจะน้อยกว่านั้นก็ตาม) ด้วยพร็อกซี คุณจะรับประกันได้ว่าจะมีเพียงหนึ่งคำขอ/การตอบกลับต่อการโหลดหน้าเว็บเท่านั้น

นอกจากนี้ยังให้ประโยชน์บางประการเมื่อเทียบกับการใช้เว็บเซิร์ฟเวอร์ระยะไกล (เอเชีย) โดยตรงเสมอ หากเนื้อหาบางส่วนเป็นไดนามิกและคุณเพียงพร็อกซีเนื้อหานั้น เซิร์ฟเวอร์ภายใน (US) ของคุณยังคงสามารถจัดเตรียมเนื้อหาสแตติกทั้งหมดได้ แน่นอน คุณอาจจะดีกว่าถ้าใช้ CDN สำหรับเนื้อหาคงที่และการเข้าถึงไคลเอ็นต์โดยตรงไปยังเว็บเซิร์ฟเวอร์ในเอเชีย