Mysql: ทำงานกับ 192 ล้านล้านระเบียน… (ใช่ 192 ล้านล้าน)

นี่คือคำถาม ...

พิจารณา 192 ล้านล้านบันทึกสิ่งที่ฉันควรพิจารณา

ความกังวลหลักของฉันคือความเร็ว

นี่คือตาราง ...

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

นี่คือข้อความค้นหา ...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

นี่คือบันทึกบางส่วน ...

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

อัปเดต (08/11/2010)

น่าสนใจฉันได้รับตัวเลือกที่สอง ...

แทนที่จะเป็น 192 ล้านล้านฉันสามารถเก็บ2.6 * 10 ^ 16 (15 ศูนย์, หมายถึง 26 Quadrillion) ...

แต่ในตัวเลือกที่สองนี้ฉันจะต้องเก็บหนึ่ง bigint (18) เป็นดัชนีในตาราง แค่นั้น - คอลัมน์เดียว ดังนั้นฉันจะตรวจสอบการมีอยู่ของค่า การเพิ่มบันทึกเป็นครั้งคราวไม่ต้องลบทิ้ง

ดังนั้นที่ทำให้ฉันคิดว่าจะต้องมีทางออกที่ดีกว่าแล้ว mysql เพียงเก็บหมายเลข ...

ให้ตัวเลือกที่สองนี้ฉันควรจะเอามันหรือติดกับตัวแรก ...

[แก้ไข]เพิ่งทราบข่าวว่ามีการทดสอบเสร็จแล้ว - 100 ล้านแถวด้วยการตั้งค่านี้จะส่งคืนข้อความค้นหาใน 0.0004 วินาที[/ แก้ไข]

การประมาณ 7PB ของ pQd นั้นสมเหตุสมผลและนั่นเป็นข้อมูลจำนวนมากสำหรับ RDBMS ฉันไม่แน่ใจว่าฉันเคยได้ยินว่ามีคนกำลังทำ 7PB กับระบบดิสก์ที่ใช้ร่วมกันโดยเฉพาะ MySQL การสอบถามปริมาณข้อมูลนี้ด้วยระบบดิสก์ที่ใช้ร่วมกันจะช้าลงอย่างผิดปกติ ฮาร์ดแวร์ SAN ที่เร็วที่สุดจะให้ความเร็วสูงสุดที่ 20GB / วินาทีแม้ว่าจะทำการปรับสำหรับการค้นหาแบบสตรีมมิ่งขนาดใหญ่ หากคุณสามารถซื้อฮาร์ดแวร์ SAN ของสเป็คนี้คุณสามารถใช้สิ่งที่เหมาะกับงานมากกว่า MySQL

ในความเป็นจริงฉันกำลังดิ้นรนที่จะเข้าใจสถานการณ์ที่คุณอาจมีงบประมาณสำหรับระบบย่อยดิสก์ของข้อมูลจำเพาะนี้ แต่ไม่ใช่สำหรับแพลตฟอร์ม DBMS ที่ดีกว่า แม้แต่การใช้ดิสก์ 600GB (ไดรฟ์ที่ใหญ่ที่สุดขององค์กร '15K ในตลาดปัจจุบัน) คุณก็พร้อมที่จะใช้งานเช่นดิสก์ไดรฟ์กายภาพ 12,000 ชุดเพื่อจัดเก็บ 7PB ดิสก์ SATA จะมีราคาถูกกว่า (และดิสก์ 2TB คุณจะต้องมีประมาณ 1/3 ของจำนวน) แต่ค่อนข้างช้ากว่าเล็กน้อย

SAN ของสเป็คนี้จากผู้ค้ารายใหญ่เช่น EMC หรือ Hitachi จะวิ่งไปหลายล้านดอลลาร์ ครั้งล่าสุดที่ฉันทำงานกับอุปกรณ์ SAN จากผู้จำหน่ายรายใหญ่ค่าใช้จ่ายในการโอนพื้นที่ใน IBM DS8000 มากกว่า 10kk / TB ไม่รวมค่าเผื่อทุนสำหรับผู้ควบคุม

คุณต้องการระบบที่ไม่มีการแบ่งปันใด ๆ เช่น Teradata หรือ Netezza สำหรับข้อมูลจำนวนมากนี้ การแบ่งฐานข้อมูล MySQL อาจใช้งานได้ แต่ฉันขอแนะนำแพลตฟอร์ม VLDB ที่สร้างขึ้นเพื่อการใช้งาน ระบบไม่มีอะไรที่ใช้ร่วมกันยังช่วยให้คุณใช้ดิสก์แนบโดยตรงที่ราคาถูกกว่ามาก - ดูที่แพลตฟอร์ม X4550 (thumper) ของซันเพื่อดูความเป็นไปได้ครั้งเดียว

คุณต้องคิดถึงความต้องการด้านประสิทธิภาพของคุณด้วย

• เวลาเรียกใช้ที่ยอมรับได้สำหรับแบบสอบถามคืออะไร
• คุณจะสืบค้นชุดข้อมูลบ่อยแค่ไหน?
• คำถามส่วนใหญ่สามารถแก้ไขได้โดยใช้ดัชนี (เช่นพวกเขากำลังจะดูเศษส่วนเล็ก ๆ - พูดว่า: น้อยกว่า 1% ของข้อมูล) หรือพวกเขาต้องการสแกนตารางเต็มหรือไม่
• ข้อมูลจะถูกโหลดเข้าสู่ฐานข้อมูลเร็วแค่ไหน?
• ข้อความค้นหาของคุณต้องการข้อมูลล่าสุดหรือคุณสามารถใช้ตารางการรายงานที่รีเฟรชเป็นระยะหรือไม่

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

หมายเหตุ:หากคุณแยกฐานปฏิบัติการและฐานข้อมูลออกคุณไม่จำเป็นต้องใช้แพลตฟอร์ม DBMS เดียวกันสำหรับทั้งคู่ การได้รับการแทรกอย่างรวดเร็วและรายงานย่อยวินาทีจากตาราง 7PB เดียวกันจะเป็นความท้าทายทางเทคนิคอย่างน้อยที่สุด

จากความคิดเห็นของคุณว่าคุณสามารถอยู่กับความล่าช้าในการรายงานคุณอาจพิจารณาระบบการดักจับและการรายงานแยกต่างหากและคุณอาจไม่จำเป็นต้องเก็บข้อมูล 7PB ทั้งหมดไว้ในระบบการจับภาพการทำงานของคุณ พิจารณาแพลตฟอร์มการทำงานเช่น Oracle (MySQL อาจทำกับ InnoDB) สำหรับการเก็บข้อมูล (อีกครั้งต้นทุนของดิสก์เพียงอย่างเดียวจะทำให้ต้นทุนของ DBMS น้อยลงเว้นแต่คุณจะมีผู้ใช้จำนวนมาก ) และแพลตฟอร์ม VLDB เช่นTeradata, Sybase IQ, RedBrick, Netezza (หมายเหตุ: ฮาร์ดแวร์ที่เป็นกรรมสิทธิ์) หรือGreenplumสำหรับการรายงาน

หักมัน ที่ขนาดนี้การฆ่าตัวตายเช่นขนาดใหญ่มีหนึ่ง - คิดเกี่ยวกับการคืนค่าการสำรองข้อมูลที่เป็นไปได้ความเสียหายของพื้นที่ตารางเพิ่มคอลัมน์ใหม่หรือกระบวนการ 'การรักษาบ้าน' อื่น ๆ - ทั้งหมดที่เป็นไปไม่ได้ที่จะทำในเวลาที่เหมาะสมในระดับนี้

ด้านหลังของการคำนวณซองจดหมายง่าย ๆ โดยสมมติว่าเป็นจำนวนเต็ม 32 บิตสำหรับคอลัมน์ทั้งหมดยกเว้นรหัส 64 บิต ไม่มีดัชนีรวม:

8 * 4B + 8B = 40B ต่อแถว [และนี่เป็นแง่ดีมาก]

192 ล้านล้านแถว 40B ให้เกือบ 7 PB

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

คำถามที่จะตอบ:

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

ลิงค์แบบสุ่ม - ความเร็วของเม็ดมีด:

• http://highscalability.com/blog/2010/5/20/strategy-scale-writes-to-734-million-records-per-day-using-t.html
• https://stackoverflow.com/questions/654594/

โทรPercona อย่าผ่าน "ไป" อย่าเก็บเงิน $ 200

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

แก้ไข: จริง ๆ แล้วถ้ามันเป็นเพียงแค่การมีอยู่หรือไม่ของ "บันทึก" ที่ตำแหน่ง X ในช่วงของจำนวนเต็มคุณสามารถกำจัด datastore และเพียงแค่ใช้บิตแมป ... ดังนั้น 10 หรือมากกว่านั้นเครื่องที่มีพื้นที่ดิสก์ 100 TB (ดังนั้นคุณมีบิตแมป 10 สำเนาสำหรับประสิทธิภาพและการสำรองข้อมูล) และถ้าคุณทำ RAM ขนาด 128GB ต่อเซิร์ฟเวอร์คุณสามารถใส่ดัชนีกลุ่มบล็อกบล็อกความละเอียดสูงระดับสูงสุดในหน่วยความจำเพื่อทำการตรวจสอบครั้งแรกก่อนกดดิสก์ X บิต 26 Quadrillion .

ฉันจะไปหาตัวเลือก # 2 หากคุณ:

375 เครื่องที่มี 64TB (32 2TB ไดรฟ์) แต่ละเครื่อง (สมจริง 400 เครื่องสำหรับความล้มเหลว) จากนั้นเพียงแมประเบียนไปยัง ZVOL ที่มีขนาด 2TB จากนั้นบนเซิร์ฟเวอร์ดัชนีอย่างน้อยหนึ่งรายการให้เก็บไว้ในอาร์เรย์ Judy หรืออาร์เรย์ critbit หรือเพียงบิตแมปธรรมดาซึ่งเป็นการแมปหากคุณได้เพิ่มระเบียนไปยังตำแหน่ง 1 จาก 26 Quadrillion ดัชนีจะอยู่ระหว่าง 50 ถึง 100TB และคุณสามารถมีดัชนีระดับที่สองบ่งบอกได้หากมีการบันทึกใด ๆ ที่เขียนไปยังบล็อกที่อยู่ 64k ที่แน่นอนซึ่งจะพอดีกับ RAM น้อยกว่า 64 GB และจะให้การตรวจสอบเริ่มต้นอย่างรวดเร็ว หาก "ละแวกใกล้เคียง" บางอย่างว่างเปล่าหรือไม่

จากนั้นให้อ่านเรคคอร์ดนั้นก่อนอื่นคุณต้องตรวจสอบว่ามีเร็กคอร์ดให้ค้นหาหรือไม่โดยดูที่ดัชนี หากมีอยู่ให้ไปที่ machine # (X) / ZOL # (Y) บนเครื่อง / ตำแหน่งการบันทึก # (Z) ภายใน 2TB blob นั้นตามการคำนวณดัชนีอย่างง่าย การค้นหาระเบียนเดียวจะเร็วมากและคุณสามารถทดสอบการโหลดบางส่วนของที่เก็บข้อมูลลงใน dbs ที่แตกต่างกัน (ในขณะที่คุณใช้ที่เก็บข้อมูลสำหรับการทำงานจริง) และทำการทดสอบประสิทธิภาพเพื่อดูว่าพวกเขาสามารถรองรับฐานข้อมูลทั้งหมดของคุณหรือไม่ เพียงใช้แหล่งข้อมูลด้วยวิธีนั้น

ZOL เป็นสิ่ง ZFS ที่อาจนึกถึงไฟล์ที่กระจัดกระจายในระบบไฟล์อื่น ๆ ดังนั้นสิ่งที่คล้ายกันจะนำไปใช้ หรือคุณสามารถทำดัชนีไปยังหมายเลขไบต์ที่แน่นอนบนดิสก์ แต่สิ่งนี้จะยุ่งยากหากดิสก์มีขนาดแตกต่างกันถ้าคุณไม่กำหนดจำนวนไบต์ที่ใช้ต่อดิสก์ในระดับที่เหมาะกับดิสก์ทั้งหมด - เช่น 1.75TB ต่อดิสก์ 2TB . หรือสร้าง metadevices ที่มีขนาดคงที่เป็นต้น

นอกเหนือจากการปรับฐานข้อมูล DB ของคุณอย่างบ้าคลั่ง (ใช้ mysqltuner เพื่อช่วย) เพื่อพยายามเก็บแคชที่คุณเลือกไว้ให้มากที่สุดเท่าที่จะเป็นไปได้มนุษย์สิ่งหนึ่งที่คุณอาจตรวจสอบคือเริ่มต้นธุรกรรม / CoMMIT (สมมติว่า InnoDB) ค่าใช้จ่ายในการล็อคแบบแถวต่อแถวและลดเวลาในการแทรกของคุณลงได้เป็นอย่างมาก ฉันจะสร้างตารางเป็นทั้ง MyISAM และ InnoDB และทำการทดสอบเพื่อดูว่าเร็วขึ้นจริง ๆ เมื่อคุณแคชแน่นขึ้น - ไม่เสมอไปที่ MyISAM จะอ่านได้เร็วขึ้น - ลองดูที่นี่:

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

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

นอกจากนี้หากคุณใช้ MyISAM และ / หรือไฟล์ InnoDB ต่อตารางคุณสามารถตรวจสอบการสร้างจุดเมานต์ระบบไฟล์ที่แตกต่างกันสำหรับ / var / lib / mysql ที่ปรับขนาดบล็อกให้เล็กลงและปรับพารามิเตอร์ fs-type เช่น ext3 / ext4 / resiserfs คุณสามารถใช้ data = writeback สำหรับเจอร์นัลและปิดใช้งานการอัพเดตเวลาเข้าถึงบนระบบไฟล์สำหรับความเร็ว I / O

สำหรับตัวเลือกที่สองจะมีการใส่ตัวเลขจำนวนเท่าใด

หากจะมีเพียงหนึ่งในพันหรือ 10K, 100K ฯลฯ ดังนั้นการเก็บช่วงของหมายเลขที่ใช้ (หรือไม่ได้ใช้) สามารถบันทึกรายการได้หลายล้านล้านรายการ เช่น: การจัดเก็บ ('ฟรี', 0,100000), ('ถ่าย', 100000,100003), ('ฟรี', 10,0004,584234) - แยกแถวออกเป็นสองหรือสามแถวตามต้องการและการสร้างดัชนีในหมายเลขแรก ค้นหา x <= {เข็ม} เพื่อดูว่ามีการค้นหาช่วงที่มีหมายเลขค้นหาหรือไม่

คุณอาจไม่ต้องการสถานะทั้งคู่ เพียงเก็บสถานะใดก็ตามที่มีโอกาสน้อยที่สุด