ความแตกต่างระหว่างการปรับสเกลแนวนอนและแนวตั้งสำหรับฐานข้อมูล [ปิด]

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

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

เป็นวิธีที่ง่ายต่อการจำนี้คือการคิดของเครื่องบนชั้นวางเซิร์ฟเวอร์เราเพิ่มเครื่องมากขึ้นในแนวนอนทิศทางและเพิ่มทรัพยากรมากขึ้นกับเครื่องในแนวตั้งทิศทาง

ในฐานข้อมูลโลกแนวนอน - สเกลมักจะขึ้นอยู่กับการแบ่งข้อมูลคือแต่ละส่วนของข้อมูลที่มีเพียงส่วนหนึ่งของข้อมูลในแนวตั้ง - ข้อมูลที่อยู่ในแนวดิ่งเดียวและการไต่สวนจะทำแบบมัลติคอร์คือกระจายโหลดระหว่าง ทรัพยากร CPU และ RAM ของเครื่องนั้น

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

ตัวอย่างที่ดีของการปรับขนาดแนวนอนคือ Cassandra, MongoDB, Google Cloud Spanner .. และตัวอย่างที่ดีของการปรับขนาดแนวตั้งคือ MySQL - Amazon RDS (รุ่นคลาวด์ของ MySQL) มันเป็นวิธีที่ง่ายในการปรับขนาดในแนวตั้งโดยเปลี่ยนจากเครื่องขนาดเล็กเป็นเครื่องที่ใหญ่กว่า กระบวนการนี้มักจะเกี่ยวข้องกับการหยุดทำงาน

กริดข้อมูลในหน่วยความจำเช่นGigaSpaces XAP , Coherence และอื่น ๆ มักจะได้รับการปรับให้เหมาะสมสำหรับการปรับสเกลแนวนอนและแนวตั้งเนื่องจากไม่ได้ถูกผูกไว้กับดิสก์ ปรับขนาดแนวนอนด้วยการแบ่งพาร์ติชันและปรับขนาดแนวตั้งผ่านการสนับสนุนมัลติคอร์

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ในโพสต์ก่อนหน้าของฉัน: ปรับ ขนาดเทียบกับเพิ่มขนาดและหลักการทั่วไปที่อยู่เบื้องหลังทางเลือก NOSQL

การปรับตามแนวนอน ===> มิเนียนพันจะทำงานร่วมกันเพื่อคุณ

การปรับในแนวตั้ง ===> ซากใหญ่หนึ่งก้อนจะช่วยคุณได้ทั้งหมด

เริ่มจากความจำเป็นในการปรับขนาดที่เพิ่มทรัพยากรเพื่อให้ระบบของคุณสามารถจัดการคำร้องขอได้มากกว่าที่เคยทำได้

เมื่อคุณทราบว่าระบบของคุณเริ่มช้าและไม่สามารถจัดการกับจำนวนคำขอปัจจุบันคุณจำเป็นต้องปรับขนาดระบบ

มีสองตัวเลือกให้คุณเลือก ไม่ว่าคุณจะเพิ่มทรัพยากรในเซิร์ฟเวอร์ที่คุณใช้อยู่ในปัจจุบันนั่นคือเพิ่มปริมาณ RAM, CPU, GPU และทรัพยากรอื่น ๆ สิ่งนี้เรียกว่าการขยายในแนวตั้ง

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

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

หวังว่าคุณจะได้รับแนวคิดทั้งหมดของการแนะนำการปรับสเกลกับระบบ

มีสถาปัตยกรรมเพิ่มเติมที่ไม่ได้กล่าวถึง - บริการฐานข้อมูลบน SQL ที่เปิดใช้งานการปรับสเกลแนวนอนโดยไม่ต้องใช้ความซับซ้อนของการแบ่งส่วนด้วยตนเอง บริการเหล่านี้มีส่วนแบ่งในพื้นหลังดังนั้นจึงช่วยให้คุณสามารถรันฐานข้อมูล SQL แบบดั้งเดิมและขยายขนาดได้ตามที่คุณต้องการด้วยเอ็นจิ้น NoSQL เช่น MongoDB หรือ CouchDB สองบริการที่ฉันคุ้นเคยคือEnterpriseDBสำหรับ PostgreSQL และXeroundสำหรับ MySQL ฉันเห็นโพสต์ในเชิงลึกโดย Xeround ซึ่งอธิบายว่าทำไมการขยายฐานข้อมูล SQL จึงยากและวิธีที่พวกเขาทำมันแตกต่างกัน - รักษาสิ่งนี้ด้วยเม็ดเกลือเพราะเป็นโพสต์ของผู้ขาย ตรวจสอบรายการฐานข้อมูลคลาวด์ของ Wikipedia ด้วยมีคำอธิบายที่ดีเกี่ยวกับ SQL กับ NoSQL และการบริการเทียบกับโฮสต์ของตัวเองรายชื่อผู้ขายและตัวเลือกการปรับขนาดสำหรับชุดค่าผสมแต่ละชุด ;)

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

Couchbase ยังเป็นฐานข้อมูล NoSQL Horizontal Scaling ที่ยอดเยี่ยมซึ่งใช้ในแอพพลิเคชั่นและเกมที่มีความพร้อมใช้งานสูงในเชิงพาณิชย์และเป็นสุดยอดนักแสดงในหมวดนี้ มันแบ่งพาร์ติชั่นข้อมูลโดยอัตโนมัติข้ามคลัสเตอร์การเพิ่มโหนดนั้นง่ายและคุณสามารถใช้ฮาร์ดแวร์สินค้าโภคภัณฑ์อินสแตนซ์ vm ที่ราคาถูกกว่า (ใช้ Large แทน High Mem, High Disk machines ที่ AWS เป็นต้น) มันถูกสร้างขึ้นจาก Membase (Memcached) แต่เพิ่มความคงทน นอกจากนี้ในกรณีของ Couchbase ทุก ๆ โหนดสามารถอ่านและเขียนได้และมีค่าเท่ากับในคลัสเตอร์โดยมีการจำลองแบบ failover เท่านั้น (ไม่ใช่การจำลองแบบชุดข้อมูลแบบเต็มในเซิร์ฟเวอร์ทั้งหมดเช่นใน mySQL)

คุณสามารถดูประสิทธิภาพที่ยอดเยี่ยมของ Cisco มาตรฐาน: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

นี่คือบล็อกโพสต์ที่ยอดเยี่ยมเกี่ยวกับสถาปัตยกรรม Couchbase: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ NuoDB อ่านของพวกเขากระดาษสีขาวทางเทคนิค

ฐานข้อมูล SQL เช่น Oracle, db2 ยังสนับสนุนการปรับขนาดแนวนอนผ่านดิสก์คลัสเตอร์ที่ใช้ร่วมกัน ตัวอย่างเช่น Oracle RAC, IBM DB2 purescale หรือ Sybase ASE Cluster edition โหนดใหม่สามารถเพิ่มเข้ากับระบบ Oracle RAC หรือระบบ DB2 purescale เพื่อให้เกิดการปรับสเกลแนวนอน

แต่วิธีการนั้นแตกต่างจากฐานข้อมูล noSQL (เช่น mongodb, CouchDB หรือ IBM Cloudant) นั่นคือ data sharding ไม่ได้เป็นส่วนหนึ่งของ Horizontal Scaling ในข้อมูลฐานข้อมูล noSQL จะถูกย่อระหว่างการปรับสเกลแนวนอน

คุณมี บริษัท และมีพนักงานเพียง 1 คน แต่คุณได้รับโครงการใหม่ 1 โครงการในเวลานั้นที่คุณจ้างผู้สมัครใหม่ - นี่คือการปรับขนาดในแนวนอน ที่ผู้สมัครใหม่เป็นเครื่องจักรใหม่และโครงการคือการรับส่งข้อมูล / การโทรไปยัง API ใหม่ของคุณ

ในกรณีที่ 1 โครงการที่มี IIT / NIT guy จัดการคำขอทั้งหมดไปยัง api / traffic ของคุณ หากมีการร้องขอไปยัง api ของคุณอีกครั้งให้ยิงเขาและแทนที่เขาด้วยคนที่แต่งตัวประหลาด IQ NIT / IIT สูง - นี่เป็นการปรับขนาดตามแนวตั้ง

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

ฉันคิดว่าในระบบจริงเราควรใช้ทั้งฐานข้อมูล sql และ nosql เพื่อใช้ประโยชน์จากความสามารถในการประมวลผลแบบมัลติคอร์และคลาวด์ของระบบในปัจจุบัน

ในทางกลับกันการทำธุรกรรมที่ซับซ้อนมีประสิทธิภาพสูงหากฐานข้อมูล sql เช่น oracle ถูกใช้ NoSql สามารถใช้สำหรับ bigdata และ scalability ในแนวนอนได้โดย sharding

คำตอบที่ได้รับการยอมรับคือจุดที่คำจำกัดความพื้นฐานของการปรับสเกลแนวนอนกับ แต่แตกต่างจากความเชื่อทั่วไปที่ว่าการขยายสเกลในแนวนอนของฐานข้อมูลเป็นไปได้เฉพาะกับ Cassandra, MongoDB และอื่น ๆ ฉันต้องการเพิ่มว่าการปรับสเกลแนวนอนนั้นเป็นไปได้ด้วย RDMS แบบดั้งเดิมเช่นกัน เช่นกันโดยไม่ใช้โซลูชันของบุคคลที่สามใด ๆ

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

จากนั้นเพียงส่งคำขอจากลูกค้าแต่ละรายไปยังเซิร์ฟเวอร์ฐานข้อมูลที่พวกเขาทำแผนที่

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

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