Mysql: สร้างดัชนีใน 1.4 พันล้านบันทึก


9

ฉันมีตารางที่มี 1.4 พันล้านบันทึก โครงสร้างของตารางมีดังนี้:

CREATE TABLE text_page (
    text VARCHAR(255),
    page_id INT UNSIGNED
) ENGINE=MYISAM DEFAULT CHARSET=ascii

textความต้องการคือการสร้างดัชนีมากกว่าคอลัมน์

ขนาดโต๊ะประมาณ 34G

ฉันพยายามสร้างดัชนีโดยคำสั่งต่อไปนี้:

ALTER TABLE text_page ADD KEY ix_text (text)

หลังจากรอ 10 ชั่วโมงในที่สุดฉันก็ยอมแพ้วิธีนี้

มีวิธีแก้ปัญหาที่ใช้การได้กับปัญหานี้หรือไม่?

UPDATE : ตารางไม่น่าจะถูกปรับปรุงหรือแทรกหรือลบ สาเหตุที่สร้างดัชนีในคอลัมน์textเป็นเพราะแบบสอบถามชนิดนี้จะถูกเรียกใช้งานบ่อย:

SELECT page_id FROM text_page WHERE text = ?

UPDATE : ฉันได้แก้ไขปัญหาด้วยการแบ่งตาราง

ตารางจะแบ่งออกเป็น 40 textชิ้นในคอลัมน์ จากนั้นการสร้างดัชนีบนตารางจะใช้เวลาประมาณ 1 ชั่วโมงจึงจะเสร็จสมบูรณ์

ดูเหมือนว่าการสร้างดัชนี MySQL ช้ามากเมื่อขนาดของตารางใหญ่มาก และการแบ่งพาร์ติชั่นช่วยลดตารางให้เล็กลง


1
เกิดอะไรขึ้นกับการใช้CREATE INDEXคำสั่งปกติ?

ฉันขอแนะนำคำถามนี้อาจจะดีกว่าใน ServerFault - เป็นผู้ดูแลระบบ DB ได้มากกว่าคำถามการตั้งโปรแกรม
จากนั้น

@Derk: วิธี CREATE INDEX ปกติช้าเกินไป ฉันต้องทำงานให้เสร็จภายใน 1 วัน

1
อืม ... ฉันไม่คิดว่าคุณจะหลีกเลี่ยงสิ่งนี้ได้ การสร้างดัชนีนั้นจำเป็นต้องใช้ DBMS ในการสแกนข้อมูลทั้งหมดรวบรวมฟิลด์ "ข้อความ" ของพวกเขาและแทรก / เปลี่ยนโหนด / ทรีย่อยที่เกี่ยวข้อง และนี้ต้องใช้เวลามากสำหรับ 34g ...
chiccodoro

เซิร์ฟเวอร์ DB ของคุณมีหน่วยความจำเท่าใด คุณได้กำหนดค่า MySQL ให้ใช้หน่วยความจำทั้งหมดหรือไม่?

คำตอบ:


4

มันอาจเป็นระบบของคุณไม่ได้ขึ้นอยู่กับงานหรือไม่ ฉันไม่ได้ใช้ MySQL (SQL Server ที่นี่) แต่ฉันรู้ถึงความเจ็บปวดของการทำดัชนีตารางรายการ 800 ล้าน โดยทั่วไป .... คุณต้องการฮาร์ดแวร์ที่เหมาะสมสำหรับสิ่งนั้น (เช่นเดียวกับ: ดิสก์ที่เร็วจำนวนมาก) ตอนนี้ฉันใช้ Velociraptors เกือบโหลและการแสดงยอดเยี่ยม;)

เซิร์ฟเวอร์ SQL (ไม่ใช่ MS SQL Server แต่เป็นเซิร์ฟเวอร์ฐานข้อมูลที่ใช้ SQL) อยู่และตายด้วยการเข้าถึงดิสก์และดิสก์ปกติไม่เพียงขึ้นอยู่กับภารกิจของการดำเนินงานขนาดใหญ่


ข้อสงสัยของฉันคือการสร้างดัชนีมักจะเร็วมากหากจำนวนระเบียนมีน้อย พูดล้าน แต่เมื่อการนับเป็นพันล้านการสร้างดัชนีจะช้ามาก ดูเหมือนว่าการเติบโตของเวลาเป็นสิ่งที่อธิบาย

ไม่ควรที่จะเป็น โดยทั่วไปแล้ว MySQL มีข้อ จำกัด แต่มันก็ไม่ใช่ฐานข้อมูลอึและมันก็แย่มาก การสร้างดัชนีช้าลง แต่ด้วย log (n) ไม่ใช่ (n) ดังนั้นจึงไม่ควรแย่ขนาดนั้น
TomTom

4

คุณอาจต้องการสร้างดัชนีในอักขระแรก (ตัวอย่างเช่น 10) ของฟิลด์ข้อความ

จากเอกสาร:

สามารถสร้างดัชนีที่ใช้เฉพาะส่วนนำของค่าคอลัมน์โดยใช้ไวยากรณ์ col_name (ความยาว) เพื่อระบุความยาวของคำนำหน้าดัชนี:

CREATE INDEX ix_text ON text_page (text(10))

4

ฉันแก้ไขปัญหาด้วยการแบ่งตาราง

ตารางจะแบ่งออกเป็น 40 textชิ้นในคอลัมน์ จากนั้นการสร้างดัชนีบนตารางจะใช้เวลาประมาณ 1 ชั่วโมงจึงจะเสร็จสมบูรณ์

ดูเหมือนว่าการสร้างดัชนี MySQL ช้ามากเมื่อขนาดของตารางใหญ่มาก และการแบ่งพาร์ติชั่นช่วยลดตารางให้เล็กลง


ดังนั้น 40 x 1 ชั่วโมงน้อยกว่า 10 ชั่วโมง?
symcbean

3

ตั้งค่า sort_buffer_size เป็น 4GB (หรือคุณสามารถขึ้นอยู่กับว่าคุณมีหน่วยความจำเท่าใด)

ตอนนี้การสร้างดัชนีกำลังทำการเรียงลำดับ แต่เนื่องจากคุณมี sort_buffer_size ขนาด 32 MB มันเป็นเรื่องที่ทยอยฮาร์ดไดรฟ์โดยไม่จำเป็น


โพสต์เหล่านี้ไม่เห็นด้วยกับคุณโดยตรง: xaprb.com/blog/2010/05/09/how-to-tune-mysqls-sort_buffer_sizeและronaldbradford.com/blog/ดีกว่า ดูเหมือนว่านั่นไม่ใช่ค่าทั่วโลก ต่อการค้นหานั่นคือ 4GB ต่อการค้นหาที่คุณแนะนำ นอกจากนี้เมื่อเกิน 256K มันจะได้รับ mem-mapped ไปยังดิสก์แทนที่จะเป็นหน่วยความจำในหน่วยความจำจริง หากคุณทำให้มันเล็กมันต้องผ่านหลาย แต่มันหลีกเลี่ยงดิสก์ (มันไม่สลับ)
Ry4an Brase

3

หากคุณไม่ต้องการสอบถามเช่น:

SELECT page_id FROM text_page WHERE text LIKE '?%';

ฉันขอแนะนำให้สร้างคอลัมน์แฮชใหม่และทำดัชนีตารางตามคอลัมน์ ขนาดส่วนเกินของตาราง + ดัชนีอาจมีขนาดเล็กกว่ามาก

UPD : ยังไงก็ตามเลขจำนวนเต็มหลัก 1.4 พันล้านตัวใช้เวลาประมาณ 6 GB นั่นคือความยาวโดยเฉลี่ยของสตริงนั้นมีน้อยกว่า 30 ตัวอักษรนั่นคือการสร้างดัชนีในคำนำหน้าอาจเป็นที่นิยมมากกว่า

คุณควรดูที่เครื่องมือจัดเก็บข้อมูลของMERGE


2

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

นอกจากนี้ตรวจสอบให้แน่ใจว่าคุณมีพื้นที่ชั่วคราวเพียงพอ


1
ฉันลองวิธีนี้แล้ว หลังจากคัดลอกข้อมูลน้อยกว่า 1% 10 ชั่วโมงไปยังตารางใหม่

1
เพื่อน ... มันคือ 1.4 พันล้านบันทึก ไม่ใช่ล้านล้าน นั่นเป็นจำนวนมาก มันจะใช้เวลาสักครู่โดยไม่คำนึงถึง

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

1
@ decompiled การแบ่งเป็นส่วนย่อย ๆ จะไม่ทำอะไรเลย (จริง ๆ แล้วมันอาจทำให้ประสิทธิภาพลดลง) @Bryan แม้จะมี 1.4 พันล้านแผ่น แต่ก็ไม่ควรใช้เวลา 1,000 ชั่วโมง

0

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

มีหลายคนบนอินเทอร์เน็ตหนึ่งในคนดังคือ:

เรามีปัญหาเดียวกันกับตารางขนาดใหญ่ (มากกว่า 500mil บันทึก) และการเปลี่ยนแปลงที่สมบูรณ์แบบ มันสร้างตาราง tmp ใหม่เพิ่มทริกเกอร์ในตารางเดิม (สำหรับบันทึกใหม่ update / ลบ / แทรก) และในเวลาเฉลี่ยมันจะคัดลอกระเบียนทั้งหมดไปยังตารางใหม่ (ด้วยโครงสร้างใหม่)

โชคดี!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.