whatz up dude? สวัสดีครับนักพัฒนาทั้งหลาย อากาศเริ่มร้อนอย่างช่วงปลายกุมภาต่อต้นมีนาแบบนี้ทำให้รู้สึกว่าถึงเวลาต้องเตรียมหาทะแลและชายหาดสวยๆสำหรับพักผ่อนกันบ้างแล้วสิ ผมคิดว่าคุณทุกคนน่าจะคิดเหมือนกัน ใครมีชายหาดที่ไหนที่เยี่ยมๆคูลๆก็ลองแนะนำหน่อยละกัน
ขอสรุปใจความตอนที่แล้วก่อนนะครับ โดยในบทนั้นผมได้กล่าวถึงความหมาย, องค์ประกอบหลัก, และได้ทิ้งท้ายไว้ถึง 3 ชนิดของ replication ซึ่งก็จะมาบรรยายกันต่อในตอนนี้
และก่อนจะไปต่อกันตรงนั้น อานุภาพของ SQL Server สำหรับงานแบบกระจายยังเหลือประเด็นให้รู้สึกอยากพูดถึงอีกนิด โดยนอกเหนือไปจากการใช้ฟีเจอร์ replication อีกทางเลือกหนึ่งที่ไมโครซอฟท์สร้างไว้ใน SQL Server คือการประมวลผล distributed transactions ร่วมกับเซอร์วิส DTC (Distributed Transaction Coordinator)
การประมวลผล distributed transactions ร่วมกับ DTC นั้นทุกเซิร์ฟเวอร์ที่ทำงานแบบกระจายจะต้องออนไลน์ (พร้อมทำงาน) ด้วยกันทั้งหมด เมื่อทรานแซกชันย่อยที่แต่ละเซิร์ฟเวอร์ทำเสร็จก็จะถูกคอมมิทและจัดการด้วยขั้นตอนตามโปรโตคอล 2-phase commit ซึ่งหากข้อผิดพลาดเกิดขึ้นแม้แต่จุดเดียวทรานแซกชันโดยรวมจะถูกยกเลิก แต่หากไม่มีข้อผิดพลาดเกิดขึ้นเลย สภาพข้อมูลในทุกเซิร์ฟเวอร์ก็จะถูกอัพเดตไปพร้อมกัน เสมือนไม่มีดีเลย์ในทุกเซิร์ฟเวอร์ ถ้ามองในแง่ความสัมพันธ์แล้วกล่าวได้ว่าสภาพข้อมูลไม่เป็นอิสระจากกัน (ต้องถูกจัดการให้ถูกต้องเหมือนกันพร้อมกันไปตลอดเวลาในทุกเซิร์ฟเวอร์)
ทีนี้หากต้องเลือกสักทางเลือกก็คงต้องดูว่าระบบฐานข้อมูลนั้น ยอมรับได้แค่ไหนในระดับความเป็นอิสระจากกันของสภาพข้อมูลแต่ละเซิร์ฟเวอร์ (ต้องถูกต้องเหมือนกันตลอดเวลา หรือยอมให้ข้อมูลแต่ละเซิรฟเวอร์มีสภาพต่างกันได้บ้าง) << ความเป็นอิสระจากกันของสภาพข้อมูลของแต่ละเซิร์ฟเวอร์ = site autonomy >>
มาถึงตรงนี้ก็สามารถโยงไปถึง 3 ชนิดของ SQL Server replication ได้แล้วอันได้แก่
- Snapshot replication เป็นชนิดที่เรียบง่ายที่สุด ไม่มีการจัดการที่ซับซ้อนเหมือนอีก 2 ชนิด โดย publication ทั้งก้อนเต็มๆจาก publisher จะเป็นสิ่งเดียวที่จะนำมาใช้งาน ข้อมูลpublication แบบนี้ไมโครซอฟท์เรียกมันว่า snapshot (อันที่จริงข้อมูล snapshot นี้ replication อีก 2 ชนิดก็มีการใช้งานด้วยเช่นกัน) ข้อมูลการเปลี่ยนแปลงย่อยๆอื่นๆจะไม่มีการนำใช้ใน replication ชนิดนี้
- Transactional replication เริ่มต้นการทำงานนั้น publication แรกจะถือเป็นข้อมูล snapshot (ข้อมูลก้อนใหญ่ที่ใช้เป็นพื้นฐานแบบเดียวกับที่ snapshot replication ใช้) แต่มีความพิเศษตรงที่เมื่อมีการเปลี่ยนแปลงเกิดขึ้นกับ article (ลองย้อนกลับไปดูความหมายในตอนที่แล้วนะครับ) รายละเอียดการเปลี่ยนแปลงนั้นก็จะถูกรวบรวมจาก transaction log และนำส่งออกไปที่ subscriber อย่างต่อเนื่อง
- Merge replication คล้ายกับ transactional replication ในด้านการรวบรวมความเปลี่ยนแปลงของข้อมูลอย่างต่อเนื่อง แต่แทนที่จะส่งออกไปอย่างต่อเนื่องเช่นกัน จะมีการรวบรวมเป็นก้อนใหญ่กว่าแล้วค่อยส่งในลักษณะ batch ด้วยช่วงเวลาที่นานขึ้น นอกจากนี้ merge replication ยังมีการจัดการความขัดแย้งของข้อมูล (conflict resolver) ที่ดีเยี่ยมอีกด้วยเมื่อนำข้อมูลมาผสานหรือ merge กัน
หลังจากได้รู้จักกับทั้ง 3 ชนิดแล้ว ผู้อ่านอาจสงสัยว่ามันโยงกันหรือเปรียบเทียบกันได้อย่างไรกับ 'การประมวลผล distributed transactions ร่วมกับ DTC' ที่กล่าวถึงไปก่อนหน้านี้ บางคนอาจเดาได้แล้ว ใช่แล้วครับ...ประเด็น'ระดับความเป็นอิสระของสภาพข้อมูล' นั่นเอง
จากรูปจะเห็นว่ากับการประมวลผล distributed transactions ร่วมกับ DTC นั้น 'ระดับความเป็นอิสระจากกันของสภาพข้อมูล' จะต่ำที่สุด จากนั้นก็จะไล่ไปที่ transactional replication และที่สูงที่สุดคือ merge replication
หรือกล่าวได้ว่า merge replication เป็นรูปแบบการทำงานที่แต่ละเซิร์ฟเวอร์ทำงานเป็นอิสระต่อกันสูงมาก เมื่อถึงเวลาอันเหมาะสมเวลาหนึ่งข้อมูลจากแต่ละเซิร์ฟเวอร์ก็จะถูกนำมาผสานกัน แน่นอนล่ะความขัดแย้งมีโอกาสเกิดขึ้นได้สูงเพราะต่างฝ่ายต่างทำงานเป็นอิสระจากกัน แต่ที่เซิร์ฟเวอร์ศูนย์กลางก็สามารถระบุเงื่อนไขและขั้นตอนสำหรับการจัดการกับความขัดแย้งดังกล่าวได้
และตอนนี้ก็สามารถโยงต่อมาได้ที่ Pocket PC applications ถึงเหตุผลที่ควรเลือกใช้ merge replication หลายคนคงเดาได้อีกว่าเพราะ Pocket PC นั้นจะให้ทำงานโดยเชื่อมต่อกับฐานข้อมูลศูนย์กลางตลอดเวลาคงลำบากหรือเป็นไปไม่ได้ ต้องใช้รูปแบบการทำงานแบบกระจายและต้องมีความเป็นอิสระสูงด้วย เมื่อถึงเวลาที่ต้องส่งข้อมูล (ที่บันทึกในไฟล์ sdf) ไปผสานที่ศูนย์กลางต้องคำนึงถึงวิธีการจัดการกับความขัดแย้งของข้อมูลที่อาจเกิดขึ้นด้วย (ตัวอย่างเช่น การบันทึกข้อมูลข่าวจากนักข่าวหลายๆคนใน Pocket PC ซึ่งเนื้อหาของข่าวเดียวกันอาจต่างกันได้ นั่นจึงต้องมีวิธีจัดการเมื่อนำมาผสานกันที่ศูนย์กลาง)
ที่จริงแล้วอยากบรรยายต่อในเรื่องของบรรดา agents ซึ่งพวกมันเป็นเซอร์วิสคอมโพเนนท์ที่ช่วยกันทำงาน replication ให้ลุล่วงไปได้ แต่จะทำให้บทความนี้ห่างไกลจากความเป็นบทความของ developer แต่จะกลายเป็นเข้าใกล้การเป็นบทความของ DBA ซะมากกว่า
ไว้เจอกันโอกาสหน้านะครับ ซึ่งจะเป็นตอนจบของซีรีส์ไตรภาคนี้ โชคดีทุกคนครับ
**********************
**บทความในซีรีส์นี้**
SQL Server Replication เบื้องต้นสำหรับผู้พัฒนาโปรแกรมบน Pocket PC (ตอนที่1)
SQL Server Replication เบื้องต้นสำหรับผู้พัฒนาโปรแกรมบน Pocket PC ตอนที่ 2 (RELOADED)