B-Trees และโครงสร้างข้อมูลอื่น ๆ จะล้าสมัยเมื่อมีการถือกำเนิดของ Solid State Drive หรือไม่?

ปัจจุบันแอพพลิเคชั่นฐานข้อมูลจำนวนมาก (อาจจะมากที่สุด) ใช้ B-Trees และรูปแบบที่หลากหลายในการจัดเก็บข้อมูลเนื่องจากโครงสร้างข้อมูลนี้ปรับการดำเนินการอ่านเขียนและค้นหาบนฮาร์ดดิสก์ให้เหมาะสม (และการดำเนินการเหล่านี้จะมีบทบาทสำคัญในประสิทธิภาพโดยรวมของ ฐานข้อมูล)

Solid State Drives (SSDs) ควรจะแทนที่ฮาร์ดดิสก์แบบดั้งเดิม (HDDs) อย่างสมบูรณ์หรือไม่เราสามารถพูดได้ว่า B-Trees และรูปแบบต่างๆจะล้าสมัยทำให้มีที่ว่างสำหรับโครงสร้างข้อมูลที่มีประสิทธิภาพมากขึ้นในหน่วยความจำโดยตรง ถ้าเป็นเช่นนั้นโครงสร้างเหล่านั้นจะเป็นอย่างไร (เช่นตารางแฮชต้นไม้ AVL)

B-Trees มักใช้สำหรับดัชนีฐานข้อมูลบนฮาร์ดดิสก์ แต่ก็มีข้อได้เปรียบแม้ในโครงสร้างข้อมูลในหน่วยความจำทำให้หน่วยความจำสมัยใหม่มีความหลากหลายของแคชและหน่วยความจำเสมือน แม้ว่าหน่วยความจำเสมือนจะอยู่บน SSD แต่นั่นจะไม่เปลี่ยนแปลง

ฉันใช้ไลบรารีต้นไม้แบบหลายทางในหน่วยความจำ B + - style ที่ฉันเขียนค่อนข้างมากใน C ++ มันอาจมีข้อได้เปรียบด้านประสิทธิภาพ - เหตุผลที่เขียนขึ้นครั้งแรกคือพยายามใช้แคชให้ดีขึ้น - แต่ฉันต้องยอมรับว่าบ่อยครั้งที่มันไม่ทำงาน ปัญหาคือการแลกเปลี่ยนซึ่งหมายความว่ารายการจะต้องย้ายไปรอบ ๆ ภายในโหนดบนแทรกและลบซึ่งจะไม่เกิดขึ้นสำหรับต้นไม้ไบนารี นอกจากนี้การแฮ็กโค้ดระดับต่ำบางรหัสที่ฉันใช้ในการปรับให้เหมาะสม - ดีพวกเขาอาจสร้างความสับสนและเอาชนะผู้เพิ่มประสิทธิภาพความจริงบอก

อย่างไรก็ตามแม้ว่าฐานข้อมูลของคุณจะถูกเก็บไว้ใน SSD ซึ่งยังคงเป็นอุปกรณ์จัดเก็บข้อมูลแบบบล็อกและยังคงมีความได้เปรียบในการใช้ B-Trees และต้นไม้หลายทางอื่น ๆ

แต่ประมาณสิบปีที่ผ่านมาอัลกอริธึมที่หลงลืมแคชและโครงสร้างข้อมูลถูกประดิษฐ์ขึ้น สิ่งเหล่านี้ไม่ได้คำนึงถึงขนาดและโครงสร้างของแคช ฯลฯ - มันทำให้ (asymptotically) เป็นวิธีที่ดีที่สุดในการใช้หน่วยความจำแบบ heirarchy B-Trees จำเป็นต้อง "ปรับ" ให้กับหน่วยความจำที่เฉพาะเจาะจงเพื่อให้เกิดประโยชน์สูงสุด (แม้ว่ามันจะทำงานได้ค่อนข้างดีสำหรับการเปลี่ยนแปลงที่หลากหลาย)

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

เลย์เอาต์ Van Emde Boas มีความสำคัญมากในโครงสร้างข้อมูลที่ไม่สนใจแคช

หลักสูตรขั้นตอนวิธี MIT OpenCourseware นั้นครอบคลุมถึงบางส่วนของโครงสร้างข้อมูลที่ลบล้างแคช

ข้อสังเกตใช่เครื่องมือฐานข้อมูลส่วนใหญ่จะต้องเขียนใหม่เนื่องจาก B-Tree จะไม่เป็นโครงสร้างข้อมูลที่มีประสิทธิภาพมากที่สุดในการจัดเก็บข้อมูลอีกต่อไปเนื่องจากพื้นที่นั้นมีความสำคัญในฮาร์ดไดรฟ์ที่ดิสก์เคลื่อนที่ช้าและดึงข้อมูล ในบล็อกหมายความว่าการเปลี่ยนแปลงใด ๆ กับข้อมูลจำเป็นต้อง:

1. ย้ายหัวไปยังตำแหน่งที่ถูกต้องบนดิสก์ (~ 10ms)
2. รอให้ดิสก์หมุน (ที่ 10k รอบต่อนาทีนั่นหมายถึงการหมุน 167 ครั้งต่อวินาที แต่โดยเฉลี่ยแล้วเรารอเพียงครึ่งหมุนดังนั้น ~ 3ms)
3. อ่านบล็อก (~ 3ms)
4. แก้ไขใน RAM (~ 10ns)
5. ย้ายหัวไปยังตำแหน่งที่ถูกต้องบนดิสก์อีกครั้ง (~ 10ms อีกครั้ง)
6. รอให้ดิสก์หมุนอีกครั้ง (~ 3ms อีกครั้ง)
7. เขียนบล็อก (~ 3ms)

นั่นคือ 10 + 3 + 3 + 10 + 3 + 3 = 34 ms

โดยเฉลี่ยแล้วการทำเช่นเดียวกันกับ SSD นั้นมีเพียง 1 มิลลิวินาทีโดยไม่คำนึงถึงตำแหน่งบนดิสก์

และเนื่องจาก hashtable นั้นเร็วกว่าเราจึงคิดว่า hashtable นั้นจะมาทดแทนที่ดีกว่า

ปัญหาเดียวคือแฮชเทเบิลไม่ได้ถูกเก็บรักษาไว้และดังนั้นจึงเป็นไปไม่ได้ที่จะพบสิ่งต่อไปและก่อนหน้าเช่น Van Emde Boas

ดู:

1. http://en.wikipedia.org/wiki/Van_Emde_Boas_tree
2. http://bryanpendleton.blogspot.com/2009/06/cache-oblivious-data-structures.html

ทำไมค้นหาถัดไปและก่อนหน้ามีความสำคัญ ลองนึกภาพการทำให้องค์ประกอบทั้งหมดมีขนาดใหญ่กว่า x และเล็กกว่า z คุณต้องใช้ดัชนีพร้อมค้นหาก่อนหน้าและค้นหาถัดไป

ปัญหาเดียวคือเราไม่พบแฮชเทเบิ้ลที่มีความสามารถในการรักษาคำสั่งซื้อ บางทีขนาดของที่ฝากข้อมูลใน B-tree อาจมีความสำคัญ แต่ก็ถูกแก้ไขด้วยอัลกอริธึมที่หลงลืม

ดังนั้นฉันจะบอกว่านี่เป็นปัญหาปลายเปิด