Computer >> คอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

ทำความเข้าใจปลายทาง Amazon Aurora

หากคุณเคยใช้ Aurora Read Replicas คุณอาจสังเกตเห็นว่ามีจุดสิ้นสุดที่แตกต่างกันหลายจุด ปลายทางคลัสเตอร์ , Reader Endpoint และ Instance Endpoints … ด้วยตัวเลือกทั้งหมดนี้ คุณจะทราบได้อย่างไรว่าควรใช้ตัวเลือกใดและเมื่อใด เช่นเดียวกับระบบที่ไม่สำคัญ คำตอบคือ… ขึ้นอยู่กับ ในบล็อกโพสต์นี้ เราจะพิจารณาจุดสิ้นสุดที่แตกต่างกัน กรณีการใช้งานสำหรับพวกเขา และข้อดีข้อเสียที่มาพร้อมกับการตัดสินใจออกแบบเหล่านั้น

ก่อนอื่น มาทำความรู้จักกับปลายทางต่างๆ ที่มีใน Amazon Aurora กัน

  • ปลายทางคลัสเตอร์Cluster Endpoint เชื่อมต่อแอปพลิเคชันของคุณกับอินสแตนซ์ DB หลักปัจจุบันสำหรับคลัสเตอร์ DB นั้น แอปพลิเคชันของคุณสามารถอ่านและเขียนไปยังอินสแตนซ์นี้ได้

  • จุดสิ้นสุดของผู้อ่านReader Endpoint การเชื่อมต่อโหลดบาลานซ์ข้ามพูลของ Read Replicas ที่พร้อมใช้งาน ลดภาระการสืบค้นเพื่ออ่านที่นี่ ลดภาระงานอินสแตนซ์ DB หลักของคุณ

  • ปลายทางอินสแตนซ์Instance Endpoint เชื่อมต่อกับอินสแตนซ์เฉพาะในคลัสเตอร์ ลูกค้าสามารถควบคุมการจัดสรรการสืบค้นอย่างละเอียด แทนที่จะให้ Amazon Aurora จัดการการกระจายการเชื่อมต่อ

ฉันรู้ว่าคุณกำลังคิดอะไรอยู่... ฉันจะเชื่อมต่อกับ Cluster Endpoint forwrites Reader Endpoint สำหรับการอ่านทั้งหมด และเหตุใดฉันจึงต้องเชื่อมต่อกับอินสแตนซ์เฉพาะ – ที่ข้ามความทนทานต่อข้อผิดพลาดในตัวและกำลังประสบปัญหาใช่ไหม ดังที่อธิบายไปก่อนหน้านี้ แอปพลิเคชันของคุณและการโต้ตอบกับออโรร่าสร้างระบบที่ซับซ้อน (หรืออย่างน้อยก็ไม่ใช่เรื่องเล็กน้อย) ด้วยระบบที่ซับซ้อน ขนาดเดียวจึงไม่ใช่กฎที่ต้องพึ่งพา… เว้นแต่คุณจะเพลิดเพลินกับการโทรในตอนกลางคืน

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

ความสม่ำเสมอในทันที

แอปพลิเคชันบางตัวคาดว่าข้อมูลจะสอดคล้องกันในทันที เมื่อแอปพลิเคชันเหล่านี้เขียนข้อมูล พวกเขาจะอ่านข้อมูลทันทีโดยปฏิบัติตามรูปแบบการออกแบบใดๆ ที่ระบุว่า "พึ่งพาแบบจำลอง ไม่ใช่ข้อมูลในเครื่องของคุณ" Amazon Aurora เป็นไปตามข้อกำหนดของ ACID; การอ่านจาก Cluster Endpoint ทันทีหลังจากที่เขียนสำเร็จจะดึงข้อมูลที่คาดหวัง (สมมติว่าธุรกรรมอื่นไม่ได้แก้ไขข้อมูลก่อนการอ่านครั้งต่อไป)

จุดที่เกิดปัญหาคือเมื่อมีการส่งการเขียนไปยัง Cluster Endpoint andreads ถูกสร้างไปยัง Reader Endpoint . นี่เป็นเพราะเวลาแฝงระหว่างการเขียนข้อมูลและเมื่อผู้อ่านมองเห็นได้ แม้ว่าเวลาในการตอบสนองการจำลองแบบจะต่ำกว่า 100 มิลลิวินาที แต่ก็ไม่ได้เกิดขึ้นทันที ซึ่งนำไปสู่สภาวะการแข่งขัน หากคุณมีสถานการณ์ที่ต้องอ่านข้อมูลหลังเขียนทันที ให้ใช้ Cluster Endpoint สำหรับทั้งอ่านและเขียน โปรดทราบว่าหากต้องการประสิทธิภาพเพิ่มเติม คุณต้องเพิ่มขนาดของอินสแตนซ์หลักของคุณ

อย่างไรก็ตาม หากยอมรับความสอดคล้องในที่สุดและแอปพลิเคชันของคุณรองรับ ให้ใช้ Reader Endpoint เป็นวิธีที่ดีในการลดภาระในอินสแตนซ์หลักของคุณ

กำลังโหลดการอ่าน

ถ้าอ่านทันทีหลังจากเขียนแล้วไม่โอเค การมี Reader Endpoint แยกกันจะมีประโยชน์อะไร ? มีหลายกรณีการใช้งานที่ข้อมูลไม่สอดคล้องกันเล็กน้อยไม่ใช่ปัญหา ตัวอย่างเช่น:การรายงานรายวัน เมื่อรันงานแบทช์เพื่อสร้างรายงานจากข้อมูลเมื่อวาน ความล่าช้าในการจำลองแบบ 100 มิลลิวินาทีไม่สำคัญ ง่ายต่อการจินตนาการถึงสถานการณ์อื่นๆ เช่น คำอธิบายผลิตภัณฑ์ในไซต์อีคอมเมิร์ซ... คุณมีแนวโน้มที่จะมีข้อมูลเก่าในเบราว์เซอร์ของผู้ใช้มากกว่าได้รับผลกระทบจากความล่าช้าในการจำลอง

โดยทั่วไป ปริมาณงานที่อ่านมากซึ่งไม่ได้อาศัยความสอดคล้องในทันทีควรพิจารณาการใช้ Reader Endpoint .

ปริมาณงานที่ไม่สม่ำเสมอ

มีบางสถานการณ์ที่เหมาะสมที่จะใช้ Instance Endpoints . สมมติว่าคุณมีแอปพลิเคชันที่มีไมโครเซอร์วิสไร้สัญชาติจำนวนมากอยู่เบื้องหลัง Elastic Load Balancer ในสถานการณ์นี้ มีเหตุผลที่จะสมมติว่าการสืบค้นข้อมูลมีการกระจายอย่างเท่าเทียมกันในไคลเอนต์ ดังนั้นทั่วทั้ง Read Replica – เมื่อใช้ Reader Endpoint .

แต่แล้วสถานการณ์ที่ปริมาณงานของลูกค้าแต่ละรายไม่กระจายอย่างเท่าเทียมกันล่ะ? หากมีการเพิ่มบริการการรายงานในการผสม Read Replica หนึ่งรายการจะมีโหลดสูงอย่างไม่สมส่วนเมื่อเทียบกับบริการอื่นๆ หากไมโครเซอร์วิสที่กล่าวถึงก่อนหน้านี้ใช้ Read Replica นี้ด้วย มีความเป็นไปได้สูงที่ประสิทธิภาพในการค้นหาที่ไม่ดีเมื่อทำการสอบถามอินสแตนซ์ที่ใช้โดยบริการการรายงาน แนวทางหนึ่งที่จะหลีกเลี่ยงสิ่งนี้คือการจัดการการกระจายการเชื่อมต่อทางฝั่งไคลเอ็นต์ แทนที่จะปล่อยให้ Amazon Aurora ทำสิ่งนี้ให้คุณ โชคดีที่ทำได้ง่ายๆ โดยใช้ Instance Endpoints แทนที่จะเป็น Reader Endpoint .ด้วยตัวเชื่อมต่อ MariaDB/J สำหรับ Aurora สำหรับ MySQL หรือ Fast Failover กับ AmazonAurora PostgreSQL ไดรเวอร์จะรับรู้ถึงอินสแตนซ์แต่ละรายการที่คุณต้องการใช้เป็น Read Replica ซึ่งช่วยให้ไดรเวอร์จัดการวิธีการกระจายการสืบค้นไปยังอินสแตนซ์แต่ละรายการได้โดยตรง

จัดการการแคช DNS

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

การจัดการ Cluster Endpoint อัตโนมัติ เฟลโอเวอร์และ Reader Endpoint การจัดสรรภาระงานได้รับการจัดการผ่าน DNS (Amazon Route 53) ไม่ใช่ที่ IP, TCP, หรือชั้นโปรโตคอลไคลเอ็นต์ฐานข้อมูล การจัดการการกระจายการเชื่อมต่อผ่าน DNS หมายความว่าแอปพลิเคชันของคุณต้องทำการสืบค้น DNS สำหรับคำขอเชื่อมต่อใหม่แต่ละรายการ แอปพลิเคชันที่ใช้การแคช DNS ควรปรับระยะหมดเวลาของแคชให้ตรงกับระเบียน DNS TTL สำหรับ Amazon Aurora การแคชการตอบสนอง DNS นานกว่าบันทึก Aurora DNS TTL จะส่งผลให้เกิดข้อผิดพลาดสองสามข้อ หากมีเหตุการณ์เฟลโอเวอร์ High-Availability (HA) นั่นคือ Read Replica ได้รับการเลื่อนระดับเป็น Primary การตอบสนอง DNS ที่แคชไว้จะหมายความว่าแอปพลิเคชันของคุณจะพยายามเชื่อมต่อกับอินสแตนซ์เก่าที่ล้มเหลวอีกครั้ง ในกรณีของ Reader Endpoint การแคชการตอบสนอง DNS ส่งผลให้เกิดการเชื่อมต่อหลายรายการไปยัง Read Replica เฉพาะ แทนที่จะกระจายไปทั่ว Read Replica ที่มีอยู่

สรุปผล

อย่างที่เราทราบกันดีอยู่แล้วว่าไม่มีโซลูชันใดที่เหมาะกับทุกขนาดเมื่อพูดถึงปริมาณงานการผลิตที่ไม่สำคัญ หากแอปพลิเคชันของคุณต้องการความสอดคล้องในทันที ตรวจสอบให้แน่ใจว่าทั้งการอ่านและเขียนถูกส่งไปยัง Cluster Endpoint . เมื่ออ่านข้อความค้นหาสามารถจัดการกับการจำลองแบบล่าช้าเล็กน้อย ให้โหลดการสืบค้นเพื่ออ่านไปยัง Reader Endpoint หากคุณสามารถใช้ Read Replicas ได้ แต่การสืบค้นของคุณไม่ได้ถูกกระจายอย่างทั่วถึงในไคลเอนต์ทั้งหมด ให้ใช้ Instance Endpoints และจัดการการกระจายการเชื่อมต่อทางฝั่งไคลเอ็นต์ อย่าลืมว่าหากแอปพลิเคชันของคุณใช้การแคช DNS โดยมีแคชหมดเวลานานกว่า TTL ของระเบียน DNS ปลายทางดูเหมือนจะไม่ทำงานตามที่คาดไว้ระหว่าง Cluster Endpoint ความล้มเหลวของ HA หรือเมื่อใช้ Reader Endpoint .

การทำความเข้าใจธรรมชาติของแอปพลิเคชันของคุณ วิธีการทำงานของ Aurora Endpoint และการใช้ความรู้นั้นอย่างถูกต้องจะนำไปสู่สภาพแวดล้อมของแอปพลิเคชันที่แข็งแกร่งยิ่งขึ้น ซึ่งเป็นสิ่งสำคัญมากสำหรับคุณและลูกค้าของคุณ ไม่มีใครอยากให้ไฟดับกลางดึก

ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม