ระบบประเภทใดบ้างที่ต้อง "ขยาย" แทนที่จะเป็น "ขยายออก"

ฉันสงสัยมานานแล้วถ้ามีระบบที่ต้อง "ขยาย" (สู่เซิร์ฟเวอร์ที่ทรงพลังและมีราคาแพงกว่า) มากกว่า "ขยายตัว" โดยแบ่งออกเป็นเซิร์ฟเวอร์ขนาดเล็กจำนวนมาก

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

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

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

ส่วนใหญ่ผมทำงานร่วมกับแอพลิเคชันที่มีศูนย์ที่มีศักยภาพการปรับแนวนอน แม้ว่ามันจะทำงานบน Linux, แอปพลิเคชัน, โครงสร้างข้อมูลและข้อกำหนด I / O บังคับให้ฉัน "ขยาย" ระบบที่มีขนาดใหญ่ขึ้นเพื่อรองรับปริมาณงานที่เพิ่มขึ้นของผู้ใช้

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

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

จากมุมมองของนักพัฒนาผมสามารถพูดได้ว่าเกือบทุกโปรแกรมฐานข้อมูลหลักแบบดั้งเดิมนั้นสามารถขยายและปรับขนาดได้อย่างมาก

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

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

ในทางกลับกันมีเอ็นจิ้นฐานข้อมูลรุ่นใหม่บางส่วนที่ได้รับการพัฒนาพร้อมกับการออกแบบพร้อมกันและ multi-master ตั้งแต่ต้น NOSQLและNewSQLเป็นคลาสการออกแบบใหม่

ดังนั้นจึงเป็นวิธีที่ดีที่สุดในการรับประสิทธิภาพที่ดีขึ้นจากเซิร์ฟเวอร์ SQL แบบดั้งเดิมที่เพิ่มขึ้น! ในขณะที่ใช้ NOSQL และ NewSQL ทั้งขยายและขยายขนาด

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

ในความคิดของฉันมีการกำหนดขอบเขตขึ้น / ออกเพื่อกำหนดว่าเวิร์กโฟลว์สามารถขนานกันได้อย่างไรและเธรดแบบขนานจำเป็นต้องประสานงานกันอย่างไร

เธรดเดี่ยว
ด้วยเหตุผลใดก็ตามเวิร์กโฟลว์นี้สามารถทำงานได้ในเธรดเดียวเท่านั้น

หนึ่งวิธีด้ายระบบใดระบบหนึ่งหมายถึงการปรับขนาดขึ้นที่จะทำให้มันไปได้เร็วขึ้น

การขนานแบบคู่ขนานอย่างแน่นหนา
นี่เป็นระบบที่มีหลายเธรดซึ่งเธรดจำเป็นต้องต่อกันอย่างแน่นหนา บางทีการสื่อสารระหว่างกระบวนการต้องรวดเร็วมากหรือทุกอย่างต้องได้รับการจัดการผ่านตัวจัดการหน่วยความจำเดียว ระบบ RDBMS ส่วนใหญ่เป็นการคำนวณแบบขนาน

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

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

นี่คือสไตล์ที่ขนาดออกมาเป็นจำนวนมากได้ง่ายขึ้น