การเฝ้าดูการพัฒนาซอฟต์แวร์ขององค์กรจากแถวแรกเป็นเวลาสองทศวรรษ แนวโน้มที่ปฏิเสธไม่ได้ในช่วงไม่กี่ปีที่ผ่านมานั้นชัดเจน นั่นคือการย้ายฐานข้อมูลไปสู่ระบบคลาวด์
ฉันได้มีส่วนร่วมในโครงการการย้ายข้อมูลสองสามโครงการแล้ว ซึ่งเป้าหมายคือการนำฐานข้อมูลภายในองค์กรที่มีอยู่มาไว้ในฐานข้อมูล Amazon Web Services (AWS) Cloud จากเอกสารประกอบของ AWS คุณจะได้เรียนรู้ว่าสิ่งนี้สามารถทำได้ง่ายเพียงใด แต่ฉันมาที่นี่เพื่อบอกคุณว่าการดำเนินการตามแผนนั้นไม่ใช่เรื่องง่ายเสมอไป และมีบางกรณีที่อาจล้มเหลวได้
ในโพสต์นี้ ฉันจะครอบคลุมประสบการณ์จริงในกรณีต่อไปนี้:
- แหล่งที่มา: ในทางทฤษฎีแล้ว มันไม่สำคัญว่าแหล่งที่มาของคุณคืออะไร (คุณสามารถใช้แนวทางที่คล้ายกันมากกับฐานข้อมูลยอดนิยมส่วนใหญ่) Oracle เป็นระบบฐานข้อมูลที่ได้รับเลือกในบริษัทองค์กรขนาดใหญ่เป็นเวลาหลายปี และ นั่นคือจุดสนใจของฉัน
- เป้าหมาย: ไม่มีเหตุผลว่าทำไมต้องเจาะจงด้านนี้ คุณสามารถเลือกฐานข้อมูลเป้าหมายใดก็ได้ใน AWS และแนวทางจะยังคงเหมาะสม
- โหมด: คุณสามารถรีเฟรชทั้งหมดหรือรีเฟรชส่วนเพิ่มได้ การโหลดข้อมูลเป็นชุด (สถานะต้นทางและเป้าหมายล่าช้า) หรือ (ใกล้) การโหลดข้อมูลตามเวลาจริง ทั้งสองจะถูกสัมผัสที่นี่
- ความถี่: คุณอาจต้องการการย้ายข้อมูลเพียงครั้งเดียวแล้วตามด้วยการสลับไปยังระบบคลาวด์เต็มรูปแบบ หรือต้องการระยะเวลาการเปลี่ยนแปลงและให้ข้อมูลเป็นปัจจุบันทั้งสองด้านพร้อมกัน ซึ่งหมายถึงการพัฒนาการซิงโครไนซ์รายวันระหว่างภายในองค์กรและ AWS แบบแรกนั้นง่ายกว่าและสมเหตุสมผลกว่ามาก แต่แบบหลังมักถูกร้องขอมากกว่าและมีจุดพักมากกว่า ฉันจะครอบคลุมทั้งสองที่นี่
คำอธิบายปัญหา
ข้อกำหนดมักจะง่าย:
เราต้องการเริ่มต้นพัฒนาบริการภายใน AWS ดังนั้นโปรดคัดลอกข้อมูลทั้งหมดของเราไปยังฐานข้อมูล “ABC” อย่างรวดเร็วและง่ายดาย ตอนนี้เราจำเป็นต้องใช้ข้อมูลใน AWS ในภายหลัง เราจะพิจารณาว่าส่วนใดของการออกแบบ DB ที่จะเปลี่ยนแปลงเพื่อให้ตรงกับกิจกรรมของเรา
ก่อนที่จะดำเนินการต่อไป มีสิ่งที่ต้องพิจารณา:
- อย่ากระโดดเข้าสู่ความคิดที่ว่า “แค่คัดลอกสิ่งที่เรามีแล้วจัดการในภายหลัง” เร็วเกินไป ฉันหมายความว่า ใช่ นี่เป็นวิธีที่ง่ายที่สุดที่คุณสามารถทำได้ และจะเสร็จอย่างรวดเร็ว แต่สิ่งนี้มีศักยภาพที่จะสร้างปัญหาทางสถาปัตยกรรมพื้นฐานดังกล่าว ซึ่งจะไม่สามารถแก้ไขได้ในภายหลัง หากไม่มีการปรับโครงสร้างใหม่อย่างจริงจังของแพลตฟอร์มคลาวด์ใหม่ส่วนใหญ่ . ลองนึกภาพว่าระบบนิเวศของคลาวด์นั้นแตกต่างอย่างสิ้นเชิงจากระบบในองค์กร บริการใหม่ ๆ หลายอย่างจะถูกนำมาใช้เมื่อเวลาผ่านไป โดยธรรมชาติแล้วผู้คนจะเริ่มใช้สิ่งเดียวกันแตกต่างกันมาก แทบจะเป็นไปไม่ได้เลยที่จะจำลองสถานะภายในองค์กรในระบบคลาวด์แบบ 1:1 อาจเป็นในกรณีเฉพาะของคุณ แต่อย่าลืมตรวจสอบอีกครั้ง
- ถามข้อกำหนดด้วยข้อสงสัยที่มีความหมายเช่น:
- ใครจะเป็นผู้ใช้ทั่วไปที่ใช้แพลตฟอร์มใหม่ ในขณะที่อยู่ในองค์กร มันสามารถเป็นผู้ใช้ทางธุรกิจที่ทำธุรกรรมได้ ในระบบคลาวด์ อาจเป็นนักวิทยาศาสตร์ข้อมูลหรือนักวิเคราะห์คลังข้อมูล หรือผู้ใช้หลักของข้อมูลอาจเป็นบริการ (เช่น Databricks, Glue, โมเดลการเรียนรู้ของเครื่อง เป็นต้น)
- งานประจำวันปกติคาดว่าจะยังคงอยู่แม้ว่าจะเปลี่ยนไปใช้ระบบคลาวด์แล้วหรือไม่ ถ้าไม่ คาดว่าจะมีการเปลี่ยนแปลงอย่างไร
- คุณวางแผนการเติบโตของข้อมูลในช่วงเวลาหนึ่งหรือไม่? ส่วนใหญ่แล้ว คำตอบคือใช่ เนื่องจากนั่นมักเป็นเหตุผลเดียวที่สำคัญที่สุดในการโยกย้ายไปยังระบบคลาวด์ แบบจำลองข้อมูลใหม่จะต้องพร้อมสำหรับมัน
- คาดหวังให้ผู้ใช้คิดถึงคำถามทั่วไปที่คาดว่าจะได้รับจากผู้ใช้ฐานข้อมูลใหม่ สิ่งนี้จะกำหนดว่าโมเดลข้อมูลที่มีอยู่จะเปลี่ยนแปลงมากน้อยเพียงใดเพื่อให้สอดคล้องกับประสิทธิภาพ
การตั้งค่าการย้ายข้อมูล
เมื่อเลือกฐานข้อมูลเป้าหมายและพูดถึงโมเดลข้อมูลจนพอใจแล้ว ขั้นตอนต่อไปคือทำความคุ้นเคยกับ AWS Schema Conversion Tool มีหลายพื้นที่ที่เครื่องมือนี้สามารถให้บริการได้:
อ้างอิง: เอกสาร AWS
ตอนนี้มีเคล็ดลับเล็กน้อยสำหรับการใช้เครื่องมือแปลงสคีมา
ประการแรก แทบจะเป็นไปไม่ได้เลยที่จะใช้เอาต์พุตโดยตรง ฉันจะพิจารณาว่ามันเป็นเหมือนผลอ้างอิง ซึ่งคุณจะต้องปรับเปลี่ยนตามความเข้าใจและวัตถุประสงค์ของข้อมูลของคุณ และวิธีที่ข้อมูลจะถูกใช้ในระบบคลาวด์
ประการที่สอง ก่อนหน้านี้ ผู้ใช้อาจเลือกตารางโดยคาดหวังผลลัพธ์สั้นๆ อย่างรวดเร็วเกี่ยวกับเอนทิตีโดเมนข้อมูลที่เป็นรูปธรรมบางอย่าง แต่ตอนนี้ ข้อมูลอาจถูกเลือกสำหรับวัตถุประสงค์ในการวิเคราะห์ ตัวอย่างเช่น ดัชนีฐานข้อมูลที่เคยทำงานในฐานข้อมูลภายในองค์กรจะไร้ประโยชน์และไม่ได้ปรับปรุงประสิทธิภาพของระบบ DB ที่เกี่ยวข้องกับการใช้งานใหม่นี้อย่างแน่นอน ในทำนองเดียวกัน คุณอาจต้องการแบ่งพาร์ติชันข้อมูลบนระบบเป้าหมายให้แตกต่างไปจากที่เคยเป็นมาก่อนบนระบบต้นทาง
นอกจากนี้ อาจเป็นการดีที่จะพิจารณาทำการแปลงข้อมูลบางอย่างในระหว่างกระบวนการย้าย ซึ่งโดยพื้นฐานแล้วหมายถึงการเปลี่ยนโมเดลข้อมูลเป้าหมายสำหรับบางตาราง (เพื่อให้ไม่ใช่สำเนา 1:1 อีกต่อไป) ในภายหลัง กฎการเปลี่ยนแปลงจะต้องนำไปใช้กับเครื่องมือการย้ายข้อมูล
หากฐานข้อมูลต้นทางและเป้าหมายเป็นประเภทเดียวกัน (เช่น Oracle on-premise เทียบกับ Oracle ใน AWS, PostgreSQL เทียบกับ Aurora Postgresql เป็นต้น) วิธีที่ดีที่สุดคือใช้เครื่องมือย้ายข้อมูลเฉพาะที่ฐานข้อมูลคอนกรีตรองรับแบบเนทีฟ ( เช่น การส่งออกและนำเข้า Data Pump, Oracle Goldengate เป็นต้น)
อย่างไรก็ตาม ในกรณีส่วนใหญ่ ฐานข้อมูลต้นทางและเป้าหมายจะใช้งานร่วมกันไม่ได้ จากนั้นเครื่องมือที่เลือกอย่างชัดเจนคือ AWS Database Migration Service
อ้างอิง: เอกสาร AWS
AWS DMS โดยทั่วไปอนุญาตให้กำหนดค่ารายการงานในระดับตาราง ซึ่งจะกำหนด:
- DB ต้นทางและตารางที่จะเชื่อมต่อคืออะไร
- ข้อกำหนดคำสั่งที่จะใช้เพื่อรับข้อมูลสำหรับตารางเป้าหมาย
- เครื่องมือการแปลง (ถ้ามี) กำหนดวิธีการแมปข้อมูลต้นทางเข้ากับข้อมูลตารางเป้าหมาย (หากไม่ใช่ 1:1)
- ฐานข้อมูลและตารางเป้าหมายที่แน่นอนในการโหลดข้อมูลคืออะไร
การกำหนดค่างาน DMS ทำในรูปแบบที่ใช้งานง่าย เช่น JSON
ตอนนี้ในสถานการณ์ที่ง่ายที่สุด สิ่งที่คุณต้องทำคือเรียกใช้สคริปต์การปรับใช้บนฐานข้อมูลเป้าหมายและเริ่มงาน DMS แต่มีอะไรมากกว่านั้น
การย้ายข้อมูลแบบเต็มเพียงครั้งเดียว
กรณีที่ง่ายที่สุดในการดำเนินการคือเมื่อคำขอย้ายฐานข้อมูลทั้งหมดไปยังฐานข้อมูลคลาวด์เป้าหมาย โดยพื้นฐานแล้ว สิ่งที่จำเป็นต้องทำจะมีลักษณะดังนี้:
หากการกำหนดค่าของ DMS ทำได้ดี จะไม่มีอะไรเลวร้ายเกิดขึ้นในสถานการณ์นี้ ทุกตารางต้นฉบับจะถูกหยิบขึ้นมาและคัดลอกไปยังฐานข้อมูลเป้าหมายของ AWS ข้อกังวลเพียงอย่างเดียวคือประสิทธิภาพของกิจกรรมและตรวจสอบให้แน่ใจว่าขนาดถูกต้องในทุกขั้นตอน เพื่อไม่ให้เกิดข้อผิดพลาดเนื่องจากพื้นที่จัดเก็บไม่เพียงพอ
การซิงโครไนซ์รายวันที่เพิ่มขึ้น
นี่คือสิ่งที่เริ่มซับซ้อน ฉันหมายความว่า ถ้าโลกนี้อยู่ในอุดมคติ มันก็น่าจะใช้ได้ดีตลอดเวลา แต่โลกไม่เคยสมบูรณ์แบบ
สามารถกำหนดค่า DMS ให้ทำงานในสองโหมด:
- โหลดเต็ม – โหมดเริ่มต้นที่อธิบายและใช้ข้างต้น งาน DMS จะเริ่มต้นเมื่อคุณเริ่มต้นหรือเมื่อมีการกำหนดเวลาให้เริ่มต้น เมื่อเสร็จแล้ว งาน DMS ก็เสร็จสิ้น
- เปลี่ยนการเก็บข้อมูล (CDC) – ในโหมดนี้ งาน DMS จะทำงานอย่างต่อเนื่อง DMS จะสแกนฐานข้อมูลต้นทางเพื่อหาการเปลี่ยนแปลงในระดับตาราง หากการเปลี่ยนแปลงเกิดขึ้น ระบบจะพยายามจำลองการเปลี่ยนแปลงในฐานข้อมูลเป้าหมายโดยทันทีตามการกำหนดค่าภายในงาน DMS ที่เกี่ยวข้องกับตารางที่เปลี่ยนแปลง
เมื่อไปที่ CDC คุณต้องเลือกอีกทางหนึ่ง นั่นคือวิธีที่ CDC จะแยกการเปลี่ยนแปลงเดลต้าจากฐานข้อมูลต้นทาง
#1. โปรแกรมอ่านบันทึก Oracle Redo
ทางเลือกหนึ่งคือการเลือกตัวอ่านบันทึกการทำซ้ำของฐานข้อมูลดั้งเดิมจาก Oracle ซึ่ง CDC สามารถใช้เพื่อรับข้อมูลที่เปลี่ยนแปลง และทำซ้ำการเปลี่ยนแปลงเดียวกันบนฐานข้อมูลเป้าหมายตามการเปลี่ยนแปลงล่าสุด
แม้ว่าสิ่งนี้อาจดูเหมือนเป็นตัวเลือกที่ชัดเจนหากต้องจัดการกับ Oracle เป็นซอร์ส แต่ก็มีสิ่งที่จับได้: โปรแกรมอ่านบันทึกการทำซ้ำของ Oracle ใช้คลัสเตอร์ Oracle ต้นทางและส่งผลโดยตรงต่อกิจกรรมอื่นๆ ทั้งหมดที่ทำงานในฐานข้อมูล (อันที่จริงแล้วจะสร้างเซสชันที่ใช้งานอยู่ใน ฐานข้อมูล)
ยิ่งคุณกำหนดค่างาน DMS มากเท่าไร (หรือคลัสเตอร์ DMS ขนานกันมากขึ้น) คุณก็อาจต้องเพิ่มขนาดคลัสเตอร์ Oracle มากขึ้น โดยพื้นฐานแล้ว ให้ปรับขนาดแนวตั้งของคลัสเตอร์ฐานข้อมูล Oracle หลักของคุณ สิ่งนี้จะส่งผลต่อต้นทุนรวมของโซลูชันอย่างแน่นอน ยิ่งถ้าการซิงโครไนซ์รายวันกำลังจะอยู่กับโครงการเป็นระยะเวลานาน
#2. เครื่องมือขุดบันทึก AWS DMS
นี่เป็นโซลูชัน AWS แบบเนทีฟสำหรับปัญหาเดียวกัน ซึ่งแตกต่างจากตัวเลือกด้านบน ในกรณีนี้ DMS จะไม่ส่งผลกระทบต่อ Oracle DB ต้นทาง แต่จะคัดลอกบันทึกการทำซ้ำของ Oracle ลงในคลัสเตอร์ DMS และทำการประมวลผลทั้งหมดที่นั่นแทน แม้ว่าจะช่วยประหยัดทรัพยากรของ Oracle แต่ก็เป็นโซลูชันที่ช้ากว่า เนื่องจากเกี่ยวข้องกับการดำเนินการมากขึ้น และอย่างที่เราเดาได้ง่ายๆ ว่าตัวอ่านแบบกำหนดเองสำหรับบันทึกการทำซ้ำของ Oracle อาจทำงานได้ช้ากว่าตัวอ่านแบบเนทีฟจาก Oracle
ขึ้นอยู่กับขนาดของฐานข้อมูลต้นทางและจำนวนการเปลี่ยนแปลงรายวัน ในกรณีที่ดีที่สุด คุณอาจลงเอยด้วยการซิงโครไนซ์ที่เพิ่มขึ้นเกือบตามเวลาจริงของข้อมูลจากฐานข้อมูล Oracle ภายในองค์กรไปยังฐานข้อมูล AWS Cloud
ในสถานการณ์อื่นๆ จะยังไม่ใกล้เคียงกับการซิงโครไนซ์แบบเรียลไทม์ แต่คุณสามารถพยายามเข้าใกล้ความล่าช้าที่ยอมรับได้มากที่สุด (ระหว่างต้นทางและเป้าหมาย) โดยการปรับแต่งการกำหนดค่าประสิทธิภาพของคลัสเตอร์ต้นทางและเป้าหมายและการขนานกัน หรือการทดลองกับ จำนวนงาน DMS และการกระจายระหว่างอินสแตนซ์ CDC
และคุณอาจต้องการเรียนรู้ว่า CDC รองรับการเปลี่ยนแปลงตารางต้นฉบับใดบ้าง (เช่น การเพิ่มคอลัมน์ เป็นต้น) เนื่องจากไม่รองรับการเปลี่ยนแปลงที่เป็นไปได้ทั้งหมด ในบางกรณี วิธีเดียวคือทำให้ตารางเป้าหมายเปลี่ยนแปลงด้วยตนเองและเริ่มงาน CDC ใหม่ตั้งแต่ต้น (สูญเสียข้อมูลที่มีอยู่ทั้งหมดในฐานข้อมูลเป้าหมายไปพร้อมกัน)
เมื่อสิ่งต่าง ๆ ผิดพลาด ไม่ว่าอะไรจะเกิดขึ้น
ฉันเรียนรู้สิ่งนี้ด้วยวิธีที่ยาก แต่มีสถานการณ์เฉพาะหนึ่งที่เชื่อมต่อกับ DMS ซึ่งสัญญาของการจำลองแบบรายวันนั้นยากที่จะบรรลุ
DMS สามารถประมวลผลบันทึกการทำซ้ำด้วยความเร็วที่กำหนดเท่านั้น ไม่สำคัญว่าจะมี DMS จำนวนมากที่เรียกใช้งานของคุณหรือไม่ ถึงกระนั้น อินสแตนซ์ DMS แต่ละรายการจะอ่านบันทึกการทำซ้ำด้วยความเร็วที่กำหนดเดียวเท่านั้น และแต่ละอินสแตนซ์ต้องอ่านทั้งหมด ไม่สำคัญว่าคุณจะใช้ Oracle redo logs หรือ AWS log miner ทั้งคู่มีขีดจำกัดนี้
หากฐานข้อมูลต้นทางมีการเปลี่ยนแปลงจำนวนมากภายในหนึ่งวันที่บันทึกการทำซ้ำของ Oracle มีขนาดใหญ่มาก (เช่น 500GB+ ขนาดใหญ่) ทุกวัน CDC จะไม่ทำงาน การจำลองแบบจะไม่เสร็จสิ้นก่อนสิ้นวัน จะนำงานที่ยังไม่ได้ดำเนินการไปในวันถัดไป ซึ่งชุดการเปลี่ยนแปลงใหม่ที่จะทำซ้ำกำลังรออยู่แล้ว จำนวนข้อมูลที่ยังไม่ได้ประมวลผลจะเพิ่มขึ้นในแต่ละวันเท่านั้น
ในกรณีนี้ CDC ไม่ใช่ตัวเลือก (หลังจากการทดสอบประสิทธิภาพหลายครั้งและเราพยายามดำเนินการ) วิธีเดียวที่จะทำให้แน่ใจว่าการเปลี่ยนแปลงเดลต้าอย่างน้อยที่สุดจากวันปัจจุบันจะถูกจำลองแบบในวันเดียวกันคือทำดังนี้:
- แยกโต๊ะขนาดใหญ่ที่ไม่ได้ใช้งานบ่อยนัก และจัดโต๊ะซ้ำเพียงสัปดาห์ละครั้ง (เช่น ในช่วงวันหยุดสุดสัปดาห์)
- กำหนดค่าการจำลองแบบของตารางที่ไม่ใหญ่แต่ยังคงใหญ่เพื่อแยกระหว่างงาน DMS หลายงาน ในที่สุดตารางหนึ่งก็ถูกย้ายโดยงาน DMS ที่แยกจากกัน 10 งานขึ้นไปพร้อมกัน เพื่อให้แน่ใจว่าการแยกข้อมูลระหว่างงาน DMS นั้นแตกต่างกัน (เกี่ยวข้องกับการเข้ารหัสแบบกำหนดเองที่นี่) และดำเนินการทุกวัน
- เพิ่มอินสแตนซ์ของ DMS เพิ่ม (สูงสุด 4 อินสแตนซ์ในกรณีนี้) และแบ่งงาน DMS ระหว่างกันเท่าๆ กัน ซึ่งหมายความว่าไม่เพียงแค่จำนวนตารางเท่านั้น แต่ยังรวมถึงขนาดด้วย
โดยพื้นฐานแล้ว เราใช้โหมดโหลดเต็มของ DMS เพื่อจำลองข้อมูลรายวัน เพราะนั่นเป็นวิธีเดียวที่จะทำให้การจำลองข้อมูลเสร็จสิ้นภายในวันเดียวกันเป็นอย่างน้อย
ไม่ใช่วิธีแก้ปัญหาที่สมบูรณ์แบบ แต่ก็ยังมีอยู่ และแม้ผ่านไปหลายปี ก็ยังใช้งานได้เหมือนเดิม ดังนั้นอาจไม่ใช่วิธีแก้ปัญหาที่แย่นัก 😃
