แนวคิดของดัชนีคลัสเตอร์ในการออกแบบ DB มีความหมายเมื่อใช้ SSD หรือไม่

เมื่อออกแบบ SQL data data schema ของเซิร์ฟเวอร์และเคียวรีที่ตามมา, sprocs, views, ฯลฯ แนวคิดของดัชนีคลัสเตอร์และลำดับของข้อมูลบนดิสก์มีเหตุผลหรือไม่ที่จะต้องพิจารณาการออกแบบ DB ที่ทำให้ติดตั้งบนแพลตฟอร์ม SSD อย่างชัดเจน ?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"ดัชนีคลัสเตอร์กำหนดลำดับทางกายภาพของข้อมูลในตาราง"

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

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

ความคิดเริ่มต้นของฉันคือว่าไม่ใช่เพราะแนวคิดของ "ข้อมูลที่สั่งซื้อ" ไม่ได้ใช้กับการจัดเก็บข้อมูล SSD และการค้นหา / การเพิ่มประสิทธิภาพการกู้คืน

แก้ไข:ฉันรู้ว่า SQL Server จะสร้างหนึ่งฉันแค่ปรัชญาเกี่ยวกับว่ามันเหมาะสมที่จะคิดในระหว่างการออกแบบ / การเพิ่มประสิทธิภาพ

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

คำตอบสำหรับคำถามนี้จะขึ้นอยู่กับรูปแบบการเข้าถึงของคุณ ในกรณีส่วนใหญ่การเข้าถึงของคุณต้องการการค้นหาแถวเดียว (เช่นการค้นหา) และการสแกนแบบช่วง รูปแบบการเข้าถึงเหล่านี้ต้องการ B-Tree ไม่เช่นนั้นจะไม่มีประสิทธิภาพ รูปแบบการเข้าถึงอื่น ๆ ที่ใช้กันทั่วไปใน DW และ OLAP มักจะทำการรวมกันตลอดทั้งแบบ end-to-end ของตารางทั้งหมดและพวกเขาจะไม่ได้รับประโยชน์จากการสแกนแบบช่วง เมื่อคุณเจาะลึกความต้องการอื่น ๆ ก็เพิ่มขึ้นเช่นความเร็วของการแทรกและการจัดสรรลงในกองกับ B-Tree อาจมีบทบาทสำหรับงานถ่ายโอน ETL ขนาดใหญ่ แต่ส่วนใหญ่แล้วคำตอบจะเพิ่มขึ้นเป็นหนึ่งคำถาม: คุณค้นหาหรือสแกนช่วงหรือไม่? จำนวนครั้งที่คำตอบคือใช่ ดังนั้นจำนวนครั้งที่การออกแบบจำเป็นต้องมีดัชนีแบบกลุ่ม

ในคำอื่น ๆ : เพียงเพราะถูกอ่านจากดิสก์ในลำดับแบบสุ่มไม่ได้หมายความว่าคุณสามารถถังขยะ TLBs และ L2 ของคุณใน 64GB RAM สแกนโบนันซ่า ...

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

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

ความคิดเห็นของ Re @Matthew PK

แน่นอนว่าตำแหน่ง A ใน RAM นั้นเร็วพอ ๆ กับตำแหน่ง B ใน RAM นั่นไม่ใช่ประเด็น. ฉันกำลังพูดถึงกรณีที่ข้อมูลทั้งหมดที่คุณต้องการไม่พอดีกับ RAM หากข้อมูลกระจัดกระจายในหลาย ๆ หน้า หน้าใดก็ตามที่ระบุอาจมีข้อมูลเพียงเล็กน้อยเท่านั้นที่คุณสนใจดังนั้น RDBMS จะต้องทำการโหลดและกวาดล้างหน้าเว็บเมื่อคุณเข้าถึง A, B และแถวอื่น ๆ นั่นคือสิ่งที่คุณจะได้รับการลงโทษ

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

ใช่มันยังคงสมเหตุสมผล คุณกำลังคิดระดับต่ำเกินไปในแนวทางของคุณ SQL Server (ในมาก มากคำอธิบายแบบง่าย) ร้านค้าคลัสเตอร์ข้อมูลในสถาปัตยกรรม B ต้นไม้ สิ่งนี้ช่วยให้สามารถดึงข้อมูลได้รวดเร็วขึ้นอยู่กับค่าคีย์ดัชนีคลัสเตอร์

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

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

การอ้างอิง: http://msdn.microsoft.com/en-us/library/ms189051.aspx