ทำไมคาสซานดราแนะนำให้สร้างดัชนีในคอลัมน์ที่มีภาวะหัวใจเต้นสูง?

เอกสารประกอบของ Cassandra

อย่าใช้ดัชนีในสถานการณ์เหล่านี้:

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

มันเกิดขึ้น

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

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

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

แต่ถ้าฉันมีคอลเล็กชั่นที่มีสิ่งของมูลค่ามากถึงพันล้าน - ในโอกาสที่หายาก - ต้องได้รับการค้นหาโดยคุณลักษณะที่แตกต่าง แต่ไม่เหมือนใคร ... นี่เป็นการใช้ที่เหมาะสมใช่ไหม?

_{¹Every? IDK ถ้าการจำลองแบบหมายความว่าสิ่งนี้สามารถเข้าถึง 1/3 ของคลัสเตอร์สำหรับปัจจัยการจำลองที่ 3 หรือไม่?}

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

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

เพิ่มเติมที่มีประสิทธิภาพวิธีการในแง่ของการค้นหาความถูกต้องอาจจะมีการรักษาสองตาราง , ค่อนข้างกว่าดัชนีรอง ตารางซึ่งตรงข้ามกับดัชนีจะได้รับการปฏิบัติเช่นเดียวกับตารางอื่น ๆ พวกเขามีมากขึ้นแนวโน้มที่จะให้ใบสมัครของคุณผลการค้นหาก็คาดว่า ข้อเสียคือการบำรุงรักษาตารางในฐานะดัชนีเมื่อเทียบกับ Cassandra "ดัชนีรอง" เป็นข้อ จำกัด ของแอปพลิเคชัน ( เช่นรหัสแอปพลิเคชันของคุณตอนนี้ต้องรู้ว่าจะแทรก / ลบแถวจากตาราง "ดัชนี" และ เพื่อทำให้ทั้งสองตารางซิงค์กันผ่านแอปพลิเคชัน "การปรับยอด" ระดับแอปพลิเคชัน

หวังว่านี่จะช่วยได้!

คำศัพท์บางคำ: ตารางหลักคือตารางที่สร้างดัชนี ตารางดัชนีรองคือตารางที่สร้างขึ้นเพื่อรักษาดัชนีในตารางอื่น

ข้อมูลของตารางดัชนีรองถูกเก็บไว้ในโหนดเดียวกับข้อมูลของตารางหลัก ตัวแยกส่วน Cassandra ไม่ได้แบ่งพาร์ติชันและกระจายข้อมูลตารางดัชนี ดังนั้นหากคุณต้องการทำการค้นหาในคอลัมน์ดัชนีโหนดทั้งหมดจะถูกสอบถามไม่ใช่แค่โหนดจำลองที่มีข้อมูล (โหนดผู้ประสานงานไม่รู้ว่าข้อมูลอยู่ที่ไหน) https://www.datastax.com/dev/blog/cassandra-native-secondary-index-deep-dive

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