โครงสร้างพื้นฐานสำหรับฐานข้อมูลการเขียนสูงพร้อมกันสูง

ความต้องการของฉันคือ:

• การเชื่อมต่อ 3000
• 70-85% เขียน vs อ่าน

ขณะนี้เรากำลังใช้งาน CPU ระดับสูง, ขนาดใหญ่พิเศษเป็นพิเศษที่ 700 การเชื่อมต่อ 8 แกนทั้งหมดมีค่าสูงสุด เราคิดว่ามันเป็นจำนวนของการเชื่อมต่อพร้อมกันเนื่องจากหน่วยความจำดี การเขียนนั้นง่ายมาก (การตรวจสอบความถูกต้องช้า) หากต้องการขยายขนาดเป็น 3000 เราต้องไปที่เซิร์ฟเวอร์หลายตัวเลือกปัจจุบัน:

• MySQL Sharding
• MongoDB คลัสเตอร์
• คาสซานดรา
• Hadoop & MySQL (แคช Hadoop, ดัมพ์เดี่ยวไปยัง MySQL)
• MongoDB & MySQL (แทนที่จะเป็น Hadoop เราใช้ Mongo เป็นแคช)

เพื่อจัดการกับจำนวนการเชื่อมต่อนี้จำนวนคำถาม:

1. MySQL Sharding สามารถจัดการการเชื่อมต่อพร้อมกันได้หรือไม่?
2. มาสเตอร์คนใดคนหนึ่งสามารถจัดการการเชื่อมต่อที่เกิดขึ้นพร้อมกันเหล่านี้หรือตัวเลือกที่ดีกว่าหลายอย่างเช่น Mongo ได้หรือไม่?

ฉันขอโทษถ้าฉันอธิบายปัญหาไม่ได้ กรุณาถามคำถาม

หากคุณใช้ MySQL เป็นฐานข้อมูลหลักคุณอาจต้องการใช้ Star Topology ผ่านการจำลองแบบ MySQL

ตอนนี้ก่อนที่คุณจะพูดว่า UGHHH, ROFL และ OMG ถึงการจำลองแบบ MySQL ได้ยินฉันออกมา

Star topology อนุญาตให้คุณเขียนไปยังเซิร์ฟเวอร์ DB หนึ่งเซิร์ฟเวอร์ (เรียกว่า Distribution Mster [DM]) และส่งคำสั่ง SQL ไปยังเซิร์ฟเวอร์ DB หลายตัว คุณจะติดตั้งโครงสร้างพื้นฐานของ DB ได้อย่างไร?

นี่คือคำอธิบาย

คุณมีเซิร์ฟเวอร์ 5 DB (เซิร์ฟเวอร์ A, B, C, D, E)

เซิร์ฟเวอร์ A

• ในการตั้งค่าการจำลองแบบ MySQL มันจะเป็นหลัก
• มีบทบาทพิเศษในฐานะ DM
• เซิร์ฟเวอร์หลัก B, C, D, E
• ตารางทั้งหมดใช้เครื่องมือเก็บข้อมูล BLACKHOLE (/ dev / null)
• เก็บบันทึกไบนารีเท่านั้น
• เครื่องโลหะเปลือย
• ประโยชน์ที่ได้รับ
  • เขียนเร็วมากเนื่องจากตารางทั้งหมดใน DM ใช้ BLACKHOLE
  • Network Latency มีปัญหาน้อยเนื่องจากการอ่านเป็น 15-30% ของกิจกรรม DB
  • ทาสทั้งหมดได้รับการอัพเดทอย่างเข้มงวดจาก DM

เซิร์ฟเวอร์ B, C, D, E

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

ฉันได้เขียนบทความเกี่ยวกับเรื่องนี้ก่อน

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

เพื่อให้การจำลองแบบ MySQL ในรูปทรงด้านบนสุด

• ใช้ MySQL 5.5
• ใช้การจำลองแบบ Semisynchronous
• ปรับแต่ง InnoDB เพื่อดึงดูดซีพียูมากขึ้น

MySQL Cluster อาจเป็นอีกวิธีหนึ่งในการกำหนด ตรวจสอบการโพสต์ที่นี่

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

หากคุณกำลังจะไปหลายหัว (ซึ่งคุณอาจต้องถ้าคุณต้องการการเชื่อมต่อที่ใช้งาน 3K จริง ๆ ) ฉันอาจจะดู Riak หรือ Cassandra มันขึ้นอยู่กับสิ่งที่แอพของคุณทำขึ้นเกี่ยวกับว่าแอปเหล่านี้จะเข้ากันได้ดีแค่ไหน แต่จากสิ่งที่คุณอธิบายฉันคิดว่ามันเหมาะกับ Riak

ที่กล่าวว่าวิธีการที่ใช้ร่วมกันดูเหมือนจะทำได้ค่อนข้างดีหากคุณสามารถหาวิธีที่ดีในการแบ่งกลุ่มข้อมูลและสามารถลดความต้องการข้ามสิ่งที่แตกออกได้ ฉันจะอยู่ห่างจากสิ่งที่แหวน / ดาว / mmm ใน mysql และเพียงติดกับเศษที่ตรง ที่จริงแล้วถ้าคุณยินดีที่จะใช้ Postgres คุณสามารถสร้างต้นแบบได้อย่างง่ายดายโดยใช้ schemas ในบางอย่างเช่น heroku จากนั้นแยกและแยกฐานข้อมูลเมื่อพวกเขาเริ่มมีจำนวนโหนดมากเกินไป

โอ้และในขณะที่ฉันคิดว่าคุณสามารถลองปรับขนาดแบบนี้ในแนวตั้ง (โหนดเดียวที่จัดการคอนน็อต 3K ทั้งหมด) ฉันไม่คิดว่าคุณจะสามารถทำได้ในระบบคลาวด์

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

ด้วยการแบ่งส่วนโดยทั่วไปคุณสามารถปรับขนาดได้ (2x db-servers == การเชื่อมต่อ 2x) แต่ขึ้นอยู่กับลักษณะของชุดข้อมูลของคุณและวิธีที่คุณสามารถแยกมันออกเป็นเศษส่วน

ฉันเองชอบ MongoDB เพราะความง่ายในการบริหารความยืดหยุ่นและความง่ายในการใช้งานทั่วไป นอกจากนี้ถ้าฉันต้องการ RDBMS จริงๆฉันจะใช้ no-SQL

ตามที่กล่าวไว้ให้เลือกฐานข้อมูลที่เหมาะสมที่สุดสำหรับการสมัครของคุณ หากคุณต้องการธุรกรรมหรือไม่สามารถออกแบบแอปของคุณได้โดยไม่ต้องเข้าร่วม (หรือเพียงแค่ใช้งานง่ายกว่า) ใช้ RDBMS (MySQL, PostGres และอื่น ๆ )

ในขณะที่ฉันชอบ MongoDB โดยส่วนตัวความคิดที่ว่า MySQL ไม่ได้ปรับขนาดหรือไม่สามารถจัดการกับอัตราการทำธุรกรรมที่สูงนั้นเป็นเรื่องผิดพลาดได้ ทีมงานด้านวิศวกรรมของ Facebook (และทีมงาน MySQL อยู่ในนั้น) มีรายละเอียดที่ดีเยี่ยม ตรวจสอบบล็อกของทีม Etsy Ops ด้วย พวกเขารัก MySQL เช่นกัน

ในที่สุดฉันจะไม่ใช้ MongoDB สำหรับแคช MySQL ใช้ Memcached สำหรับสิ่งนั้น

Redis เป็นที่เก็บคีย์ - ค่าใน RAM ซึ่งเหมาะสำหรับการจัดการกรณีใช้งานบางอย่าง มีรายการบล็อกบางรายการใน blog.agoragames.com ที่อธิบายการใช้งานบางกรณี

คุณควรตรวจสอบ CouchDB หากคุณคิดว่าไม่ใช้ SQL เพิ่งทราบว่ามันต้องการการบำรุงรักษาอย่างสม่ำเสมอเพื่อให้มันใช้งานดิสก์ลง (มันแลกเปลี่ยนความเร็วและความสะดวกสบายสำหรับ Disk util ... )

ในที่สุดการวางแผนกำลังการผลิตไม่ใช่เรื่องง่ายที่จะทำนาย คุณต้องทดสอบในสภาพที่เป็นจริงมากที่สุดและเตรียมที่จะแก้ไขตามสิ่งที่คุณเห็น น่าเศร้า "วิทยาศาสตร์คอมพิวเตอร์" เป็นศิลปะมากที่สุดเท่าที่วิทยาศาสตร์