ไม่มีวิธีแก้ปัญหาที่ชัดเจนเพราะสิ่งนี้ขึ้นอยู่กับบริบทของคุณโดยเฉพาะอย่างยิ่งตามขนาดที่ระบบของคุณควรจะปรับขนาดและปัญหาที่แท้จริงของคุณคืออะไร ฐานข้อมูลเป็นปัญหาคอขวดของคุณหรือไม่
คำตอบนี้ (น่าเสียดายที่ค่อนข้างยาว) จะอ่านเล็กน้อยเช่น“ microservices นั้นไม่ดี monoliths ตลอดชีวิต!” แต่นั่นไม่ใช่ความตั้งใจของฉัน ประเด็นของฉันคือ microservices และฐานข้อมูลแบบกระจายสามารถแก้ปัญหาต่าง ๆ ได้ แต่ไม่ใช่โดยไม่มีปัญหาของตัวเอง เพื่อให้การโต้แย้งที่แข็งแกร่งสำหรับสถาปัตยกรรมของคุณคุณต้องแสดงให้เห็นว่าปัญหาเหล่านี้ไม่ได้ใช้สามารถบรรเทาและสถาปัตยกรรมนี้เป็นตัวเลือกที่ดีที่สุดสำหรับความต้องการทางธุรกิจของคุณ
ข้อมูลที่แจกจ่ายเป็นเรื่องยาก
ความยืดหยุ่นเช่นเดียวกับที่ช่วยให้การปรับขนาดที่ดีขึ้นเป็นด้านพลิกของการรับประกันที่อ่อนแอ โดยเฉพาะอย่างยิ่งระบบกระจายที่ให้เหตุผลได้ยากกว่ามาก
การอัปเดตการทำธุรกรรมของอะตอมความสอดคล้อง / ความสมบูรณ์ของการอ้างอิงและความทนทานเป็นสิ่งที่มีค่าอย่างยิ่งและไม่ควรได้รับการหลีกเลี่ยง มีจุดเล็ก ๆ น้อย ๆ ในการมีข้อมูลหากข้อมูลไม่สมบูรณ์ล้าสมัยหรือผิดพลาด เมื่อคุณมี ACID เป็นความต้องการทางธุรกิจ แต่กำลังใช้เทคโนโลยีฐานข้อมูลที่ไม่สามารถให้ได้นอกกรอบ (เช่นฐานข้อมูล NoSQL จำนวนมากหรือสถาปัตยกรรม DB-per-microservice) ดังนั้นแอปพลิเคชันของคุณจะต้องเติมช่องว่างและให้การรับรองเหล่านั้น
นี่เป็นไปไม่ได้ที่จะทำ แต่ยากที่จะทำให้ถูกต้อง ยุ่งยากมาก โดยเฉพาะอย่างยิ่งในการตั้งค่าแบบกระจายที่มีตัวเขียนหลายตัวในแต่ละฐานข้อมูล ปัญหานี้แปลว่ามีโอกาสสูงที่จะเกิดข้อบกพร่องซึ่งอาจรวมถึงข้อมูลที่ถูกทิ้งข้อมูลที่ไม่สอดคล้องและอื่น ๆ
ตัวอย่างเช่นพิจารณาอ่านJepsen วิเคราะห์ที่รู้จักกันดีระบบฐานข้อมูลแบบกระจายอาจจะเริ่มต้นด้วยการวิเคราะห์คาสซานดรา ฉันไม่เข้าใจว่าครึ่งหนึ่งของการวิเคราะห์นั้น แต่ TL; DR คือระบบการกระจายนั้นยากมากที่บางครั้งแม้แต่โครงการชั้นนำในอุตสาหกรรมก็ทำให้พวกเขาเข้าใจผิด
ระบบกระจายยังหมายถึงความพยายามในการพัฒนาที่ใหญ่ขึ้น ในระดับหนึ่งมีการแลกเปลี่ยนโดยตรงระหว่างค่าใช้จ่ายในการพัฒนาหรือลดเงินในฮาร์ดแวร์ที่มีเนื้อวัว
ตัวอย่าง: การอ้างอิงห้อย
ในทางปฏิบัติคุณไม่ควรมองศาสตร์วิทยาการคอมพิวเตอร์ แต่ในความต้องการทางธุรกิจของคุณเพื่อดูว่ากรดสามารถผ่อนคลายได้หรือไม่ เช่นความสัมพันธ์ระหว่างประเทศกับต่างประเทศอาจไม่สำคัญเท่าที่ควร พิจารณาความสัมพันธ์ของผลิตภัณฑ์ - หมวดหมู่ n: m ใน RDBMS เราอาจใช้ข้อ จำกัด foreign-key เพื่อให้เฉพาะผลิตภัณฑ์ที่มีอยู่และหมวดหมู่ที่มีอยู่สามารถเป็นส่วนหนึ่งของความสัมพันธ์นั้นได้ จะเกิดอะไรขึ้นถ้าเราแนะนำบริการผลิตภัณฑ์และหมวดหมู่แยกต่างหากและผลิตภัณฑ์หรือหมวดหมู่ถูกลบไปแล้ว
ในกรณีนี้อาจไม่ใช่ปัญหาใหญ่และเราสามารถเขียนแอปพลิเคชันของเราเพื่อกรองผลิตภัณฑ์หรือหมวดหมู่ที่ไม่มีอยู่อีกต่อไป แต่มีข้อเสียคือ!
โปรดทราบว่าสิ่งนี้อาจต้องการระดับแอปพลิเคชันJOINบนหลายฐานข้อมูล / ไมโครไซต์ซึ่งจะย้ายการประมวลผลจากเซิร์ฟเวอร์ฐานข้อมูลไปยังแอปพลิเคชันของคุณ ซึ่งจะเป็นการเพิ่มภาระทั้งหมดและต้องย้ายข้อมูลพิเศษผ่านเครือข่าย
ซึ่งสามารถยุ่งกับเลขหน้า เช่นคุณขอผลิตภัณฑ์ 25 รายการถัดไปจากหมวดหมู่และกรองผลิตภัณฑ์ที่ไม่พร้อมใช้งานออกจากคำตอบนั้น ตอนนี้แอปพลิเคชันของคุณแสดง 23 ผลิตภัณฑ์ ในทางทฤษฎีแล้วจะสามารถใช้หน้าเว็บที่มีผลิตภัณฑ์เป็นศูนย์ได้!
คุณจะต้องเรียกใช้สคริปต์ที่ล้างการอ้างอิงที่ห้อยอยู่เป็นครั้งคราวไม่ว่าหลังจากการเปลี่ยนแปลงที่เกี่ยวข้องหรือตามช่วงเวลาปกติ โปรดทราบว่าสคริปต์ดังกล่าวมีราคาแพงพอสมควรเพราะพวกเขาต้องขอทุกผลิตภัณฑ์ / หมวดหมู่จากฐานข้อมูลสำรอง / microservice เพื่อดูว่ายังมีอยู่หรือไม่
สิ่งนี้ควรชัดเจน แต่เพื่อความชัดเจน: ห้ามนำ ID ซ้ำมาใช้ รหัสประจำตัวสไตล์อัตโนมัติอาจเป็นหรือไม่ก็ได้ GUID หรือแฮชให้ความยืดหยุ่นแก่คุณมากขึ้นเช่นโดยสามารถกำหนด ID ก่อนที่รายการจะถูกแทรกลงในฐานข้อมูล
ตัวอย่าง: คำสั่งซื้อพร้อมกัน
ตอนนี้ให้พิจารณาความสัมพันธ์ระหว่างผลิตภัณฑ์และคำสั่งซื้อแทน จะเกิดอะไรขึ้นกับคำสั่งซื้อหากผลิตภัณฑ์ถูกลบหรือเปลี่ยนแปลง? ตกลงเราสามารถคัดลอกข้อมูลผลิตภัณฑ์ที่เกี่ยวข้องลงในรายการคำสั่งซื้อเพื่อให้ใช้ได้ - พื้นที่ดิสก์ซื้อขายเพื่อความง่าย แต่จะเกิดอะไรขึ้นถ้าราคาสินค้าเปลี่ยนแปลงหรือผลิตภัณฑ์ไม่พร้อมใช้งานก่อนสั่งทำผลิตภัณฑ์? ในระบบแบบกระจายเอฟเฟ็กต์ต้องใช้เวลาในการเผยแพร่และคำสั่งจะผ่านข้อมูลที่ล้าสมัย
อีกวิธีวิธีนี้ขึ้นอยู่กับความต้องการทางธุรกิจของคุณ อาจเป็นคำสั่งที่ล้าสมัยและคุณสามารถยกเลิกคำสั่งนั้นได้ในภายหลังหากไม่สามารถดำเนินการได้
แต่อาจไม่ใช่ตัวเลือกเช่นสำหรับการตั้งค่าพร้อมกันสูง พิจารณาคน 3,000 คนที่รีบซื้อตั๋วคอนเสิร์ตภายใน 10 วินาทีแรกและสมมติว่าการเปลี่ยนแปลงความพร้อมใช้งานนั้นจะต้องใช้เวลา 10ms ในการเผยแพร่ ความน่าจะเป็นในการขายตั๋วใบสุดท้ายให้กับคนหลายคนเป็นเท่าไหร่? ขึ้นอยู่กับวิธีการจัดการการชนเหล่านั้น แต่ใช้การแจกแจงแบบปัวซงด้วยλ = 3000 / (10s / 10ms) = 3เราจะได้รับP(k > 1) = 1 - P(k = 0) - P(k = 1) = 80%โอกาสในการชนกันต่อช่วงเวลา 10 มิลลิวินาที ไม่ว่าจะขายและยกเลิกคำสั่งซื้อส่วนใหญ่ของคุณในภายหลังเป็นไปได้โดยไม่กระทำการทุจริตอาจนำไปสู่การสนทนาที่น่าสนใจกับฝ่ายกฎหมายของคุณ
ลัทธินิยมนิยมหมายถึงการเลือกสรรเชอร์รี่ที่ดีที่สุด
ข่าวดีก็คือคุณไม่จำเป็นต้องย้ายไปใช้โมเดลฐานข้อมูลแบบกระจายหากไม่จำเป็นต้องใช้อย่างอื่น ไม่มีใครจะเพิกถอนการเป็นสมาชิก Microservice Club ของคุณหากคุณไม่ได้ทำไมโครซอฟท์ว่า "ถูกต้อง" เพราะไม่มีสโมสรดังกล่าว - และไม่มีใครที่จะสร้าง microservices ได้
ลัทธินิยมนิยมชนะทุกครั้งดังนั้นผสมผสานและจับคู่แนวทางที่หลากหลายขณะที่พวกเขาแก้ปัญหาของคุณ นี่อาจหมายถึง microservices ด้วยฐานข้อมูลส่วนกลาง จริงๆแล้วอย่าไปสู่ความเจ็บปวดของฐานข้อมูลแบบกระจายถ้าคุณไม่ต้องทำ
คุณสามารถปรับขนาดได้โดยไม่ต้องใช้ไมโครไซต์
Microservices มีประโยชน์สองประการที่สำคัญ:
- ผลประโยชน์ขององค์กรที่พวกเขาสามารถพัฒนาและปรับใช้อย่างอิสระโดยทีมงานแยกต่างหาก (ซึ่งจะต้องใช้บริการเพื่อให้อินเทอร์เฟซที่มีเสถียรภาพ)
- ประโยชน์ในการดำเนินงานว่าแต่ละ MICROSERVICE สามารถปรับขนาดได้อย่างอิสระ
หากไม่จำเป็นต้องปรับสเกลอิสระ microservices น่าสนใจน้อยกว่ามาก
เซิร์ฟเวอร์ฐานข้อมูลเป็นบริการประเภทหนึ่งที่คุณสามารถปรับขนาด (ค่อนข้าง) ได้อย่างอิสระเช่นโดยการเพิ่มแบบจำลองการอ่าน คุณพูดถึงขั้นตอนการจัดเก็บ การลดขนาดอาจมีผลกระทบขนาดใหญ่ที่การอภิปรายเรื่องความสามารถในการปรับขนาดอื่น ๆ นั้นเป็นสิ่งที่สงสัย
และเป็นไปได้ที่จะมีเสาหินที่ปรับขนาดได้ซึ่งรวมถึงบริการทั้งหมดเป็นห้องสมุด จากนั้นคุณสามารถปรับขนาดได้ด้วยการเปิดตัวอินสแตนซ์ของเสาหินจำนวนมากขึ้นซึ่งแน่นอนว่าแต่ละอินสแตนซ์จะต้องไร้สถานะ
สิ่งนี้มีแนวโน้มที่จะทำงานได้ดีจนกระทั่งเสาหินมีขนาดใหญ่เกินไปที่จะนำไปใช้อย่างสมเหตุสมผลหรือถ้าบริการบางอย่างมีข้อกำหนดทรัพยากรพิเศษเพื่อให้คุณอาจต้องการปรับขนาดพวกเขาอย่างอิสระ โดเมนปัญหาที่เกี่ยวข้องกับทรัพยากรเพิ่มเติมอาจไม่เกี่ยวข้องกับตัวแบบข้อมูลแยกต่างหาก
คุณมีกรณีธุรกิจที่แข็งแกร่งหรือไม่?
คุณตระหนักถึงความต้องการทางธุรกิจขององค์กรของคุณและสามารถสร้างอาร์กิวเมนต์สำหรับสถาปัตยกรรมฐานข้อมูลต่อการให้บริการโดยอ้างอิงจากการวิเคราะห์:
- ต้องใช้ขนาดที่แน่นอนและสถาปัตยกรรมนี้เป็นวิธีที่ประหยัดต้นทุนมากที่สุดในการปรับขนาดได้โดยคำนึงถึงความพยายามในการพัฒนาที่เพิ่มขึ้นสำหรับโซลูชันการตั้งค่าและทางเลือกดังกล่าว และ
- ความต้องการทางธุรกิจของคุณอนุญาตให้ ACID ที่เกี่ยวข้องรับประกันผ่อนคลายโดยไม่นำไปสู่ปัญหาต่าง ๆ เช่นที่กล่าวไว้ข้างต้น
ในทางกลับกันหากคุณไม่สามารถแสดงสิ่งนี้ได้โดยเฉพาะอย่างยิ่งหากการออกแบบฐานข้อมูลปัจจุบันสามารถรองรับสเกลที่เพียงพอในอนาคตได้
นอกจากนี้ยังมีองค์ประกอบ YAGNI ขนาดใหญ่เพื่อความยืดหยุ่น เมื่อเผชิญกับความไม่แน่นอนมันเป็นการตัดสินใจทางธุรกิจเชิงกลยุทธ์ในการสร้างความสามารถในการปรับขนาดได้ในขณะนี้ (ลดต้นทุนโดยรวม แต่เกี่ยวข้องกับค่าเสียโอกาสและอาจไม่จำเป็นต้องใช้) เมื่อเทียบกับการชะลองานบางส่วน แนวคิดของมาตราส่วนจริง) นี่ไม่ใช่การตัดสินใจทางเทคนิคเป็นหลัก