ดัชนีฐานข้อมูลมีจำนวนมากเกินไป?

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

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

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

จำนวนดัชนีที่ถือว่ามากเกินไป? 10? 25? 50? หรือฉันควรจะครอบคลุมกรณีที่พบได้บ่อยและชัดเจนจริงๆและเพิกเฉยต่อสิ่งอื่น ๆ ?

ขึ้นอยู่กับการดำเนินการที่เกิดขึ้นบนโต๊ะ

หากมีการเลือกจำนวนมากและการเปลี่ยนแปลงน้อยมากให้ทำดัชนีทั้งหมดที่คุณต้องการ .... สิ่งเหล่านี้จะ (อาจ) เร่งความเร็วของคำสั่ง SELECT

หากตารางได้รับผลกระทบอย่างหนักจากการอัปเดต INSERTs + DELETEs ... สิ่งเหล่านี้จะช้ามากโดยมีดัชนีจำนวนมากเนื่องจากจำเป็นต้องแก้ไขทุกครั้งที่มีการดำเนินการเหล่านี้เกิดขึ้น

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

ฉันมักจะดำเนินการเช่นนี้

1. รับบันทึกการสืบค้นจริงที่เรียกใช้ข้อมูลในวันปกติ
2. เพิ่มดัชนีเพื่อให้คำค้นหาที่สำคัญที่สุดเข้าสู่ดัชนีในแผนการดำเนินการ
3. พยายามหลีกเลี่ยงการทำดัชนีฟิลด์ที่มีการอัปเดตหรือส่วนแทรกจำนวนมาก
4. หลังจากจัดทำดัชนีแล้วให้รับบันทึกใหม่และทำซ้ำ

เช่นเดียวกับการเพิ่มประสิทธิภาพใด ๆ ฉันจะหยุดเมื่อถึงประสิทธิภาพที่ร้องขอ (สิ่งนี้บ่งบอกอย่างชัดเจนว่าจุด 0 จะได้รับข้อกำหนดด้านประสิทธิภาพเฉพาะ)

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

alter index my_index_name monitoring usage;

จากนั้นคุณสามารถตรวจสอบว่าดัชนีถูกใช้หรือไม่จากจุดนั้นไปข้างหน้าโดยการสอบถาม v $ object_usage ข้อมูลเกี่ยวกับเรื่องนี้สามารถพบได้ในคู่มือของผู้ดูแลระบบฐานข้อมูล Oracle?

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

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

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

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

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

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

ในการถอดความของEinsteinเกี่ยวกับความเรียบง่ายให้เพิ่มดัชนีมากเท่าที่คุณต้องการและไม่ต้องเพิ่ม

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

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

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

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

เช่นเคยไม่มีอะไรเรียบง่าย หากมีคอลัมน์และฮิสโทแกรมที่บิดเบี้ยวอาจเป็นความคิดที่ไม่ดี

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

ฉันทำการทดสอบง่ายๆในโครงการจริงและฐานข้อมูล MySql จริง ฉันตอบไปแล้วในหัวข้อนี้: ค่าใช้จ่ายในการจัดทำดัชนีหลายคอลัมน์ db คืออะไร?

แต่ฉันคิดว่ามันจะดีกว่าถ้าฉันพูดที่นี่:

ฉันได้ทำการทดสอบง่ายๆโดยใช้โครงการจริงและฐานข้อมูล MySql จริง

ผลลัพธ์ของฉันคือการเพิ่มดัชนีเฉลี่ย (1-3 คอลัมน์ในดัชนี) ลงในตาราง - ทำให้เม็ดมีดช้าลง 2.1% ดังนั้นหากคุณเพิ่ม 20 ดัชนีเม็ดมีดของคุณจะช้าลง 40-50% แต่การเลือกของคุณจะเร็วขึ้น 10-100 เท่า

ดังนั้นจึงสามารถเพิ่มดัชนีจำนวนมากได้หรือไม่? - ขึ้นอยู่กับ :) ฉันให้ผลลัพธ์ของฉัน - คุณตัดสินใจ!

ในที่สุดจำนวนดัชนีที่คุณต้องการขึ้นอยู่กับพฤติกรรมของแอปพลิเคชันของคุณที่อยู่บนเซิร์ฟเวอร์ฐานข้อมูลของคุณ

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

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

ไม่มีคำตอบที่คงที่ในความคิดของฉันสิ่งนี้อยู่ภายใต้ 'การปรับแต่งประสิทธิภาพ'

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

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

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

สำหรับ SQL Server ฉันพบว่าที่ปรึกษาการปรับแต่งฐานข้อมูลเครื่องยนต์มีประโยชน์ - คุณตั้งค่าปริมาณงาน 'ทั่วไป' และสามารถให้คำแนะนำเกี่ยวกับการเพิ่ม / ลบดัชนีและสถิติได้ ฉันแน่ใจว่าฐานข้อมูลอื่นมีเครื่องมือที่คล้ายกันไม่ว่าจะเป็น "อย่างเป็นทางการ" หรือของบุคคลที่สาม

นี่เป็นคำถามเชิงทฤษฎีมากกว่าการปฏิบัติ ผลกระทบของดัชนีต่อประสิทธิภาพของคุณขึ้นอยู่กับฮาร์ดแวร์ที่คุณมีเวอร์ชันของ Oracle ประเภทดัชนีและอื่น ๆ เมื่อวานนี้ฉันได้ยินว่า Oracle ประกาศพื้นที่จัดเก็บข้อมูลเฉพาะที่ผลิตโดย HP ซึ่งคาดว่าจะทำงานได้เร็วขึ้น 10 เท่าด้วยฐานข้อมูล 11g สำหรับกรณีของคุณสามารถแก้ไขได้หลายวิธี: 1. มีดัชนีจำนวนมาก (> 20) และสร้างใหม่ทุกวัน (ทุกคืน) สิ่งนี้จะเป็นประโยชน์อย่างยิ่งหากตารางได้รับการอัปเดต / ลบหลายพันรายการทุกวัน 2. แบ่งตารางของคุณ (หากใช้โมเดลข้อมูลของคุณ) 3. ใช้ตารางแยกต่างหากสำหรับข้อมูลใหม่ / ที่อัปเดตและเรียกใช้กระบวนการทุกคืนซึ่งรวมข้อมูลเข้าด้วยกัน สิ่งนี้จะต้องมีการเปลี่ยนแปลงตรรกะของแอปพลิเคชันของคุณ 4. เปลี่ยนเป็น IOT (ตารางที่จัดดัชนี) หากข้อมูลของคุณรองรับสิ่งนี้

แน่นอนว่าอาจมีวิธีแก้ปัญหาอื่น ๆ อีกมากมายสำหรับกรณีดังกล่าว คำแนะนำแรกของฉันสำหรับคุณคือการโคลน DB ไปยังสภาพแวดล้อมการพัฒนาและเรียกใช้การทดสอบความเครียดกับมัน

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

สิ่งหนึ่งที่คุณอาจพิจารณาคือการสร้างดัชนีเพื่อกำหนดเป้าหมายการค้นหาแบบผสมมาตรฐาน หากมีการค้นหาโดยทั่วไป column1 และ column2 มักใช้ร่วมกับคอลัมน์นี้และบางครั้ง column3 จะใช้กับ column2 และ column1 ดังนั้นดัชนีใน column1, column2 และ column3 ในลำดับนั้นสามารถใช้กับสถานการณ์ใด ๆ ในสามสถานการณ์นั้นได้แม้ว่าจะเป็น ดัชนีเดียวที่ต้องได้รับการดูแล

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

คุณสามารถอดทนต่อเวลาเพิ่มเติมที่ต้องใช้ในการอัปเดตได้หรือไม่?

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

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

มีกี่คอลัมน์ ฉันมักจะได้รับคำสั่งให้สร้างดัชนีคอลัมน์เดียวไม่ใช่ดัชนีหลายคอลัมน์ ดังนั้นจึงไม่มีดัชนีมากไปกว่าจำนวนคอลัมน์ IMHO

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

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

Sql server มีเครื่องมือดีๆที่ช่วยให้คุณเห็นว่ามีการใช้ดัชนีใดบ้าง บทความนี้http://www.mssqltips.com/tip.asp?tip=1239จะให้คุณได้รับข้อมูลเชิงลึกที่ช่วยให้คุณได้รับข้อมูลเชิงลึกที่ดีขึ้นเกี่ยวกับปริมาณดัชนีที่ใช้เมื่อเทียบกับจำนวนการอัปเดต

มันขึ้นอยู่กับคอลัมน์ที่ใช้ใน Where Clause และในฐานะ Thumb of Rule เราต้องมีดัชนีใน Foreign Key Columns เพื่อหลีกเลี่ยง DEADLOCKS รายงาน AWR ควรวิเคราะห์เป็นระยะเพื่อทำความเข้าใจความต้องการของดัชนี