MySQL Sharding กับ MySQL Cluster

เมื่อพิจารณาถึงประสิทธิภาพเท่านั้น MySQL Cluster สามารถเอาชนะข้อมูลที่กำหนดเองได้ซึ่งจะทำให้โซลูชัน MySQL แตกหักได้หรือไม่? sharding = การแบ่งพาร์ติชันในแนวนอน

เมื่อฉันอ้างถึงการจัดเรียงฉันกำลังพิจารณาการแบ่งส่วนที่เกิดขึ้นในเลเยอร์แอปพลิเคชัน สำหรับเซิร์ฟเวอร์สองเครื่องอาจเป็น (key mod 2)

การเปิดเผยข้อมูล: ฉันเป็นพนักงาน MySQL กำลังทำงานกับ MySQL Cluster

ฉันจะบอกว่า MySQL Cluster สามารถบรรลุ throughput / host ที่สูงกว่า MySQL + InnoDB ที่ถูกจัดให้โดย:

• การค้นหานั้นง่าย
• ข้อมูลทั้งหมดเหมาะกับในหน่วยความจำ

ในแง่ของเวลาแฝง MySQL Cluster น่าจะมีเวลาแฝงที่เสถียรมากกว่าการหักเห MySQL เวลาแฝงที่เกิดขึ้นจริงสำหรับข้อมูลในหน่วยความจำล้วนอาจคล้ายคลึงกัน

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

ขณะนี้ MySQL Cluster ถูก จำกัด ให้ 'sharding' มากกว่า 48 โฮสต์ ทฤษฎีของ MySQL ที่ไม่มีการ จำกัด อย่างไรก็ตามสำหรับปริมาณงานเป้าหมายที่กำหนดอาจจำเป็นต้องใช้โฮสต์ MySQL Cluster น้อยกว่าโฮสต์ MySQL ที่แบ่งทิ้ง

ความแตกต่างที่น่าสนใจคือเมื่อคุณดูที่ส่วนอื่น ๆ นอกเหนือจากประสิทธิภาพ:

• MySQL Cluster รองรับการสืบค้นโดยพลการในทุกส่วน
• MySQL Cluster รองรับการทำธุรกรรมโดยพลการในทุกส่วน
• MySQL Cluster รองรับการเรพลิเคทของส่วนที่มีการซิงโครไนซ์อัตโนมัติและการกู้คืน
• MySQL Cluster รองรับการเพิ่มโหนดออนไลน์ (การขยายคลัสเตอร์)
• Sharded MySQL เป็นมากกว่า 'ม้วนตัวคุณเอง'

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

เกี่ยวกับคำตอบก่อนหน้านี้มีการชี้แจงเล็กน้อย:

"ถึงแม้ว่า MySQL Cluster เป็นคำร้องเรียนเรื่องกรด แต่มันก็ไม่ได้จัดเตรียมเอ็นจิ้นการจัดเก็บที่เหมาะสมสำหรับข้อมูลที่มีคีย์ผสม"

MySQL Cluster รองรับคีย์หลักและรอง ไม่แน่ใจว่าสิ่งที่ 'ไม่เหมาะสม' เกี่ยวกับเรื่องนี้ บางทีโปสเตอร์ก่อนหน้านี้สามารถอธิบายได้?

"เพื่อให้มีข้อมูลที่มีลักษณะสำคัญเหมือนกันเก็บไว้ในโหนดข้อมูลชุดหนึ่งคุณสามารถทำสิ่งต่อไปนี้:

1. ใช้โหนดข้อมูลทั้งหมดแบบออฟไลน์โดยปล่อยเฉพาะโหนดข้อมูลเหล่านั้นที่คุณต้องการจัดเก็บข้อมูลที่มีลักษณะสำคัญเหมือนกัน
2. โหลดข้อมูลของคุณลงใน MySQL Cluster ซึ่งจะเติมเฉพาะโหนดข้อมูลที่คุณเลือก
3. นำโหนดข้อมูลทั้งหมดกลับมาออนไลน์ "

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