เผยแพร่ครั้งแรกเมื่อวันที่ 27 พ.ย. 2020 ที่ ObjectRocket.com/blog
Elasticsearch® นั้นยอดเยี่ยมในการกระจายข้อมูลทั่วทั้งคลัสเตอร์ของคุณด้วยการตั้งค่าเริ่มต้น แต่หลังจากที่คลัสเตอร์ของคุณเริ่มเติบโต คุณควรปรับการตั้งค่าเริ่มต้นของคุณเพื่อเพิ่มประสิทธิภาพ มาดูข้อมูลเบื้องต้นเกี่ยวกับการแบ่งกลุ่มย่อยและจัดทำดัชนีและแนวทางปฏิบัติที่ดีที่สุดสำหรับกลุ่มย่อย
ข้อมูลเบื้องต้นเกี่ยวกับการแบ่งกลุ่มของ Elasticsearch
มีเอกสารมากมายเกี่ยวกับวิธีการทำงานของชาร์ดของ Elasticsearch แต่แนวคิดพื้นฐานของการแบ่งกลุ่มคือแบ่งข้อมูลของคุณออกเป็นชิ้นเล็ก ๆ หลายชิ้นเพื่อให้การค้นหาสามารถทำงานได้หลายส่วนพร้อมกัน เพื่อความสะดวกในการจัดกลุ่มและการทำให้ฟังก์ชันดัชนีเป็นแบบคู่ขนาน ให้แบ่งแต่ละดัชนีในอินสแตนซ์ Elasticsearch ของคุณออกเป็นชิ้นๆ ที่มีตัวเลข ชิ้นส่วนเหล่านี้เรียกว่าเศษ มาดูพฤติกรรมหลักของพวกเขากัน:
- ส่วนแบ่งข้อมูลแต่ละส่วนจำลองขึ้นอยู่กับ จำนวนการจำลอง การตั้งค่าสำหรับดัชนี ดังนั้นสำหรับ จำนวนแบบจำลอง การตั้งค่าหนึ่ง มีสำเนาของแต่ละชาร์ดสองชุด:หนึ่ง หลัก ชาร์ดและ แบบจำลองหนึ่งอัน เศษ ชาร์ดหลักคือส่วนหลักและใช้สำหรับ
indexing/writeและsearch/readการดำเนินการ ในขณะที่ส่วนจำลองใช้สำหรับsearch/read. เท่านั้น และสำหรับการกู้คืนหากระบบหลักล้มเหลว - ชาร์ดแบบจำลองต้องอยู่บนโฮสต์อื่นที่ไม่ใช่ พาเรนต์ ชาร์ดหลัก
- ชาร์ดจะกระจายไปตามจำนวนโฮสต์ในคลัสเตอร์โดยอัตโนมัติตามค่าเริ่มต้น แต่โฮสต์จริงเดียวกันอาจมีชาร์ดหลักหลายรายการ คุณสามารถใช้การตั้งค่า Elasticsearch เพื่อแก้ไขพฤติกรรมนี้ (การปรับสมดุล การจัดสรรชาร์ด และอื่นๆ) แต่ขั้นตอนนั้นอยู่นอกเหนือขอบเขตของโพสต์นี้
- ชาร์ดแต่ละส่วนต้องอยู่ในโฮสต์เดียวเท่านั้น เนื่องจากชาร์ดจะแบ่งแยกไม่ได้
- คุณสามารถกำหนดจำนวนชาร์ดที่ดัชนีสร้างระหว่างการสร้างดัชนี หรือคุณสามารถใช้ค่าเริ่มต้นส่วนกลางก็ได้ หลังจากที่คุณสร้างดัชนีแล้ว คุณจะไม่สามารถเปลี่ยนจำนวนชาร์ดโดยไม่ทำดัชนีใหม่ได้
- คุณสามารถกำหนดจำนวนแบบจำลองที่ดัชนีมีระหว่างการสร้างดัชนี หรือคุณสามารถใช้ค่าเริ่มต้นส่วนกลางก็ได้ คุณสามารถเปลี่ยนหมายเลขนี้ได้หลังจากสร้างดัชนีแล้ว
มาดูตัวอย่างเล็กๆ น้อยๆ ฉันสร้างดัชนีโดยมีจำนวนชาร์ดเป็นสามและตั้งค่าแบบจำลองหนึ่งรายการ ดังที่คุณเห็นในไดอะแกรมก่อนหน้านี้ Elasticsearch จะสร้างชาร์ดหกส่วนให้คุณ:ชาร์ดหลักสามรายการ (Ap, Bp และ Cp) และชาร์ดแบบจำลองสามรายการ (Ar, Br และ Cr)
Elasticsearch ช่วยให้แน่ใจว่าเรพลิกาและไพรมารีอยู่บนโฮสต์ที่ต่างกัน แต่คุณสามารถจัดสรรชาร์ดหลักหลายรายการให้กับโฮสต์เดียวกันได้ ในส่วนของเจ้าของที่พัก มาดูกันว่าคุณจัดสรรชาร์ดให้กับโฮสต์ของคุณอย่างไร
การจัดสรรชาร์ดและ Elasticsearch แบบคลัสเตอร์
Elasticsearch พยายามจัดสรรชาร์ดในโฮสต์ที่มีอยู่ทั้งหมดตามค่าเริ่มต้น ที่ Rackspace ObjectRocket แต่ละคลัสเตอร์ประกอบด้วยโหนดหลัก โหนดไคลเอ็นต์ และโหนดข้อมูล โหนดข้อมูลในสถาปัตยกรรมของเราสร้าง ที่เก็บข้อมูล ซึ่งคุณสามารถกำหนดชาร์ดได้
จากตัวอย่างก่อนหน้านี้ ให้นำชาร์ดทั้งหกนั้นมากำหนดให้กับคลัสเตอร์ ObjectRocket สำหรับ Elasticsearch ที่มีโหนดข้อมูลสองโหนด (ขั้นต่ำ) ในไดอะแกรมต่อไปนี้ คุณจะเห็นว่าสำหรับชาร์ดแต่ละส่วน โหนดหลักจะไปที่โหนดข้อมูลหนึ่ง ในขณะที่แบบจำลองรับประกันว่าจะอยู่บนโหนดอื่น โปรดทราบว่าตัวอย่างในที่นี้แสดงการจัดสรรที่เป็นไปได้เพียงครั้งเดียว ไม่ว่าการจัดสรรจะเป็นอย่างไรก็ตาม สิ่งเดียวที่แน่นอนก็คือการจำลองจะถูกวางบนโหนดข้อมูลที่แตกต่างจากโหนดหลักเสมอ
ตอนนี้ มาขยายตัวอย่างนี้และเพิ่มโหนดข้อมูลที่สาม โปรดสังเกตว่าชาร์ดสองส่วนถูกย้ายไปยังโหนดข้อมูลใหม่ ดังนั้นคุณจึงมีชาร์ดสองส่วนในแต่ละโหนด
สุดท้าย มาเพิ่มดัชนีใหม่ให้กับคลัสเตอร์นี้โดยมีจำนวนชาร์ดเป็น 2 และตั้งค่าเรพพลิกาเป็นสองชุด สิ่งนี้ทำให้คุณมีไพรมารีใหม่สองตัว (Xp และ Yp) และแบบจำลองสี่แบบ (Xr0, Xr1, Yr0, Yr1) ที่คุณสามารถกระจายไปทั่วคลัสเตอร์ดังที่เห็นในภาพต่อไปนี้:
แค่นั้นแหละ.
หลุมพราง
Elasticsearch ทำงานหนักทั้งหมดให้กับคุณ แต่มีข้อผิดพลาดบางประการที่ควรหลีกเลี่ยง
Pitfall #1—ดัชนีขนาดใหญ่และชาร์ดขนาดใหญ่
การแก้ไขปัญหาดัชนีขนาดใหญ่ที่มีชาร์ดขนาดใหญ่เป็นหนึ่งในปัญหาที่ง่ายที่สุดในการบรรเทาใน Elasticsearch ผู้ใช้เริ่มต้นด้วยดัชนีเดียวที่สามารถจัดการได้มาก อย่างไรก็ตาม เมื่อแอปพลิเคชันเติบโตขึ้น ดัชนีของพวกเขาก็เช่นกัน สิ่งนี้นำไปสู่ชาร์ดขนาดใหญ่เนื่องจากขนาดของชาร์ดเกี่ยวข้องโดยตรงกับปริมาณข้อมูลคลัสเตอร์
ปัญหาแรกสาเหตุนี้คือประสิทธิภาพต่ำในการใช้คลัสเตอร์ เมื่อชาร์ดโตขึ้น จะวางบนโหนด adata ได้ยากขึ้น ต้องใช้พื้นที่ว่างของโหนดข้อมูลจำนวนมากในการจัดเก็บชาร์ดที่นั่น เงื่อนไขนี้นำไปสู่โหนดที่มีจำนวนมากที่ไม่ได้ใช้พื้นที่ที่สูญเปล่า ตัวอย่างเช่น หากฉันมีโหนดข้อมูล 8 GB แต่ชาร์ดแต่ละส่วนมี 6 GB ฉันจะวาง 2 GB บนดาต้าโหนดแต่ละอัน ฉบับที่ 2 Hot Spotting . หากคุณรวมข้อมูลของคุณไว้ในชาร์ดบางส่วน การสืบค้นที่ซับซ้อนจะไม่สามารถแยกโหนดจำนวนมากขึ้นและดำเนินการพร้อมกันได้
อย่าตระหนี่กับดัชนี
ใช้ดัชนีหลายรายการเพื่อแก้ไขปัญหาพื้นที่จนตรอก กระจายข้อมูลของคุณในหลายดัชนีเพื่อเพิ่มจำนวนชาร์ดในคลัสเตอร์และกระจายข้อมูลอย่างเท่าเทียมกัน นอกจากนี้ เช่นเดียวกับเกม Tetris เมื่อ Elasticsearch วางชาร์ด ดัชนีหลายรายการจะง่ายต่อการดูแลจัดการ ความสามารถของนามแฝงใน Elasticsearch ยังคงทำให้หลายอินสแตนซ์ปรากฏเป็นดัชนีเดียวสำหรับแอปของคุณ Elastic Stack ส่วนใหญ่สร้างดัชนีรายวันตามค่าเริ่มต้น ซึ่งเป็นวิธีปฏิบัติที่ดี จากนั้นคุณสามารถใช้นามแฝงเพื่อจำกัดขอบเขตการค้นหาในช่วงวันที่ที่ระบุ ใช้ภัณฑารักษ์เพื่อลบดัชนีเก่าตามอายุ และแก้ไขการตั้งค่าดัชนีเมื่อข้อมูลของคุณเติบโตขึ้นโดยไม่ต้องทำดัชนีข้อมูลเก่าใหม่
เพิ่มจำนวนชาร์ดเมื่อขนาดดัชนีของคุณเพิ่มขึ้น
เพิ่มดัชนีบ่อยขึ้นและเพิ่มจำนวนชาร์ดเมื่อดัชนีของคุณเติบโตขึ้น หลังจากที่คุณเห็นขนาดชาร์ดเริ่มเกินพื้นที่ที่คุณต้องการ คุณสามารถอัปเดตเทมเพลตดัชนีของคุณ (หรืออะไรก็ตามที่คุณใช้เพื่อสร้างดัชนีใหม่) เพื่อใช้ชาร์ดเพิ่มเติมสำหรับแต่ละดัชนี อย่างไรก็ตาม วิธีนี้จะช่วยคุณได้ก็ต่อเมื่อคุณสร้างดัชนีใหม่บ่อยๆ ดังนั้นคำแนะนำนี้ อยู่ในอันดับที่สอง ไม่เช่นนั้น คุณจะต้องสร้างดัชนีใหม่เพื่อแก้ไขจำนวนชาร์ด ซึ่งแสดงถึงการทำงานมากกว่าการจัดการดัชนีหลายรายการ
กฎทั่วไปของเรา:หากชาร์ดมีขนาดใหญ่กว่า 40% ของขนาดของโหนดข้อมูล ชาร์ดนั้นก็อาจจะใหญ่เกินไป ในกรณีนี้ แนะนำให้ทำดัชนีใหม่กับดัชนีที่มีชาร์ดมากขึ้นหรือเลื่อนขึ้นเป็นแผนขนาดใหญ่ขึ้น (ความจุต่อโหนดข้อมูลมากขึ้น)
หลุมพราง #2—ดัชนีหรือชาร์ดมากเกินไป
ค่าผกผันคือดัชนีหรือชาร์ดมากเกินไป หลังจากอ่านหัวข้อที่แล้ว คุณอาจพูดว่า “ก็ได้ ฉันจะใส่ทุกเอกสารในดัชนีและสร้างชาร์ดนับล้าน” ปัญหาคือดัชนีและชาร์ดมีค่าใช้จ่าย ค่าโสหุ้ยที่แสดงออกในการจัดเก็บ ทรัพยากรหน่วยความจำ และประสิทธิภาพการประมวลผล
เนื่องจากคลัสเตอร์ต้องรักษาสถานะของชาร์ดทั้งหมดและตำแหน่งของชาร์ด ชาร์ดจำนวนมากจึงกลายเป็นการดำเนินการทำบัญชีที่ใหญ่ขึ้น ซึ่งส่งผลกระทบต่อการใช้หน่วยความจำ นอกจากนี้ เนื่องจากคุณจำเป็นต้องแยกการสืบค้นข้อมูลด้วยวิธีต่างๆ มากขึ้น คุณจึงใช้เวลามากขึ้นในการกระจายหรือรวบรวมคำค้นหา หลุมพรางนี้ขึ้นอยู่กับขนาดของคลัสเตอร์ กรณีใช้งาน และปัจจัยอื่นๆ อย่างมาก แต่โดยทั่วไป เราสามารถบรรเทาปัญหานี้ได้ด้วยคำแนะนำบางประการ
ชาร์ดไม่ควรเกิน 50 GB
โดยทั่วไป 25 GB เป็นขนาดในอุดมคติสำหรับชาร์ดขนาดใหญ่ และ 50 GB ต้องมีการทำดัชนีใหม่ การพิจารณานี้เกี่ยวข้องกับประสิทธิภาพของชาร์ดและกระบวนการย้ายชาร์ดนั้นเมื่อจำเป็น เมื่อทำการปรับสมดุล ให้ย้ายชาร์ดไปยังโหนดอื่นในคลัสเตอร์ การถ่ายโอนข้อมูลขนาด 50 GB อาจใช้เวลานานเกินไปและผูกสองโหนดระหว่างกระบวนการทั้งหมด
รักษาขนาดชาร์ดให้น้อยกว่า 40% ของขนาดโหนดข้อมูล
ตามที่กล่าวไว้ก่อนหน้านี้ เมตริกขนาดชาร์ดที่สองที่เราสนใจคือเปอร์เซ็นต์ของความจุโหนดข้อมูลที่ชาร์ดใช้ ในบริการ Rackspace ObjectRocket เราขอเสนอขนาดแผนต่างๆ ที่เกี่ยวข้องกับปริมาณพื้นที่เก็บข้อมูลบนโหนดข้อมูล พยายามปรับขนาดคลัสเตอร์และชาร์ดเพื่อให้แน่ใจว่าชาร์ดที่ใหญ่ที่สุดใช้ความจุของโหนดข้อมูลไม่เกิน 40% ในคลัสเตอร์ที่มีดัชนีหลายขนาดหลายขนาด สิ่งนี้ค่อนข้างมีประสิทธิภาพ อย่างไรก็ตาม ในคลัสเตอร์ที่มีดัชนีขนาดใหญ่น้อยมาก ให้ใส่ในเชิงรุกมากขึ้นและพยายามรักษาความจุของโหนดข้อมูลให้ต่ำกว่า 30%
ตามหลักการแล้ว ให้ตรวจสอบให้แน่ใจว่าคุณไม่ได้รวมความจุไว้บนโหนดข้อมูล หากชาร์ดของคุณมีขนาดประมาณ 45% ของโหนดข้อมูล คุณต้องมีโหนดข้อมูลที่ใช้งานได้ประมาณครึ่งหนึ่งเพื่อวางชาร์ดนั้น นั่นเป็นความจุสำรองที่ไม่ได้ใช้มากมาย!
บทสรุป
การเลือกชาร์ดและการตั้งค่าการจัดทำดัชนีที่เหมาะสมอาจเป็นเรื่องยาก แต่ด้วยการวางแผน การตัดสินใจที่ดีล่วงหน้า และการปรับแต่งในขณะที่คุณดำเนินการ คุณสามารถรักษาคลัสเตอร์ของคุณให้อยู่ในสถานะที่ดีและทำงานอย่างเหมาะสม เราช่วยธุรกิจปรับแต่ง Elasticsearchinstances ของตนตลอดเวลา
เรียนรู้เพิ่มเติมเกี่ยวกับ Rackspace DBA Services
ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม คุณยังสามารถคลิกแชทขาย เพื่อแชทตอนนี้และเริ่มการสนทนา
