Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

Troubleshooting Slow Elasticsearch Queries: สาเหตุทั่วไปและวิธีแก้ไข

เผยแพร่ครั้งแรกเมื่อวันที่ 29 พฤษภาคม 2561 ที่ ObjectRocket.com/blog

คำขอสนับสนุน Elasticsearch® ที่พบบ่อยที่ Rackspace Technology ได้รับคือ "คุณช่วยเรื่อง response time ได้ไหม?" หรือ "คำขอของผมนานมาก ทำยังไงดี?"

Troubleshooting Slow Elasticsearch Queries: สาเหตุทั่วไปและวิธีแก้ไข

สองแนวทาง

ทุกครั้งที่เราได้คำถามประเภทนี้ เราเริ่มต้นด้วยการดูสองพื้นที่หลัก:

  • Operations Side – ดูทรัพยากรระบบปัจจุบันและตัวเลือก Elasticsearch เริ่มต้น
  • Development Side - ดูคำขอ โครงสร้างของพวกเขา และการแมปปิ้งของข้อมูลที่คุณกำลังค้นหา

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

คำขอของคุณช้ามแค่ไหน?

ขั้นตอนแรกคือดูว่าใช้เวลานานเท่าไรในการส่งคำขอไปยังเคลสเตอร์ เอกสาร Elasticsearch ไม่ชัดเจนเกี่ยวกับวิธีเปิด slow logs ดังนั้นผมจึงแสดงตัวอย่างบางส่วนในโพสต์นี้

ก่อนอื่น มีสองเวอร์ชันของ slow logs ใน Elasticsearch: index slow logs และ search slow logs เนื่องจากปัญหาที่เราพยายามแก้ไขเกี่ยวกับคำขอที่ช้า เราจึงเน้นที่ search slow logs อย่างไรก็ตาม หากนี่เกี่ยวกับปัญหาประสิทธิภาพขณะจัดทำดัชนีหรือเพิ่มเอกสาร เราจะดู index slow logs

ทุกเวอร์ชันของ Elasticsearch ปิด slow logs โดยค่าเริ่มต้น ดังนั้นคุณต้องอัปเดตเล็กน้อยทั้งการตั้งค่าเคลสเตอร์และการตั้งค่าดัชนี ตัวอย่างต่อไปนี้เกี่ยวกับ Elasticsearch 6.2 แต่คุณสามารถหาข้อมูลเกี่ยวกับเวอร์ชันก่อนหน้าได้ที่นี่ แทนที่ $ES_version ด้วยเวอร์ชันที่คุณกำลังทำงาน เช่น เวอร์ชัน 5.5

  • ส่งคำขอ PUT ไปยัง _cluster API เพื่อกำหนดระดับ slow log ที่คุณต้องการเปิด: warn, info, debug, และ trace (ข้อมูลเพิ่มเติมเกี่ยวกับระดับการบันทึก)

    curl -XPUT https://localhost:$ES_PORT/_cluster/settings -H ‘Content-Type: application/json’ -d’

     { 

    “transient” : { “logger.index.search.slowlog” : “DEBUG”, “logger.index.indexing.slowlog” : “DEBUG” } }'

เนื่องจาก Elasticsearch เปิดใช้งาน slow logging ทั้งหมดในระดับดัชนี คุณสามารถส่งคำขอไปยัง API _settings ของดัชนีเพื่อเปิดใช้งาน คุณยังต้องเพิ่มลงใน index template ของคุณหากคุณหมุนดัชนีรายเดือน รายไตรมาส ฯลฯ

  • ปรับการเรียก API การตั้งค่าดัชนีให้ตรงกับ閾值เวลา slow log ที่คุณต้องการ คุณสามารถตั้งค่าเป็นศูนย์เพื่อสร้างโปรไฟล์อินสแตนซ์และรวบรวมคำขอทั้งหมดที่ส่ง หรือ -1 เพื่อปิด slow log

  • ใช้การตั้งค่า log-level เดียวกับที่คุณใช้ใน _clustersettings ในตัวอย่างนี้ DEBUG ES_PORT เป็นตัวแปรสภาพแวดล้อมที่คงที่

    curl -XPUT https://localhost:$ES_PORT/*/_settings?pretty -H ‘Content-Type: application/json’ -d ‘{“index.search.slowlog.threshold.query.debug”: “-1”,“index.search.slowlog. threshold.fetch.debug”: “-1”,}’

ตอนนี้ คุณต้องรวบรวม log Slow logs ถูกสร้างต่อ shard และรวบรวมต่อ data node หากคุณมี data node เพียงตัวเดียวที่มี primary shards ห้า (ค่าเริ่มต้น) คุณจะเห็นรายการห้าสำหรับคำขอหนึ่งใน slow logs เนื่องจากการค้นหาใน Elasticsearch เกิดขึ้นภายในแต่ละ shard คุณจึงเห็นหนึ่งต่อ shard Slow Logs ถูกเก็บต่อ data node ในตำแหน่งเริ่มต้นต่อไปนี้: /var/log/elasticsearch/$ClusterID_index_slowlog_query and /var/log/elasticsearch/$ClusterID_index_slowlog_fetch ตามที่คุณเห็น search slow logs ถูกแบ่งออกเป็นไฟล์ log แยกกันอีกครั้งตามขั้นตอนของการค้นหา: fetch และ query

ตอนนี้เรามีผลลัพธ์ใน log แล้ว เราสามารถดึงรายการหนึ่งมาแยกวิเคราะห์ได้

[2018-05-21T12:35:53,352][DEBUG ][index.search.slowlog.query] [DwOfjJF] [blogpost-slowlogs][4] took[1s], took_millis[0], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[5], source[{"query":{"match":{"name": {"query":"hello world", "operator":"OR","prefix_length":0,"max_expansions":50,"fuzzy_transpositions" :true, "lenient":false,"zero_terms_query": "NONE","boost":1.0}}},"sort":[{"price": {"order":"desc"}}]}], 

ที่นี่ คุณเห็น:

  • Date timestamp
  • Log level
  • Slowlog type
  • Node name
  • Index
  • Shard number
  • Time took
  • The body of the query (_source>)

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

_profile API

_profile API ให้ข้อมูลหน้าหลายหน้ากับคำขอของคุณและแยกวิเคราะห์สิ่งที่เกิดขึ้นในแต่ละ shard ลงถึงการจับเวลาแต่ละส่วนประกอบของการค้นหา — ยิ่งคำขอรายละเอียด _profile output จะยิ่งมากขึ้น

เครื่องมือโปรไฟล์ของ Kibana

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

สองขั้นตอนของ Elasticsearch: query then fetch

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

Query phase

  • Coordinator node ยอมรับคำขอ
  • Coordinator ระบุดัชนี (หรือดัชนี) ที่กำลังถูกค้นหา
  • Coordinator สร้างรายการโหนดที่มี shards สำหรับดัชนี (ในผสมของ primary และ replica ทั้งสอง)
  • Coordinator ส่งคำขอไปยังโหนด
  • Shards บนโหนดประมวลผลคำขอ
  • คำขอถูกให้คะแนน (โดยค่าเริ่มต้น) ไปยังเอกสาร 10 อันดับแรก
  • รายการถูกส่งกลับไปยัง coordinator node

Fetch phase

  • Fetch phase เริ่มต้นด้วย coordinator node ซึ่งกำหนดเอกสาร 10 อันดับแรกจาก 50 ผลลัพธ์ (5 shards x 10) ที่ส่งโดยแต่ละ shard
  • Coordinator ส่งคำขอสำหรับเอกสาร 10 อันดับแรกไปยัง shards (นี่อาจเป็น shard เดียวที่มีเอกสารที่ได้คะแนนสูงสุด หรือพวกมันอาจกระจายไปหลาย shards)

หลังจากรายการคืนค่า master จะนำเสนอเอกสารในส่วน _hits ของคำตอบคำขอ

คะแนนผลลัพธ์

คะแนนผลลัพธ์เป็นสิ่งสำคัญใน Elasticsearch โดยทั่วไป เมื่อคุณใช้เครื่องมือค้นหา คุณต้องการผลลัพธ์ที่แม่นยำที่สุด ตัวอย่างเช่น หากคุณค้นหา kiwi ผลไม้ คุณไม่ต้องการผลลัพธ์รวมถึง Kiwi shoe polish Elasticsearch ให้คะแนนผลลัพธ์คำขอตามพารามิเตอร์ที่คุณให้มา แม้เราจะครอบคลุม query relevance ในโพสต์บล็อกที่แตกต่างกันทั้งหมด แต่สำคัญที่จะกล่าวถึงที่นี่ เพราะหากคุณมีการค้นหาที่เร็วแต่ผลลัพธ์ไม่ใช่สิ่งที่คุณมองหา การค้นหาทั้งหมดก็เป็นการเสียเวลา ดังนั้น คุณจะทำอย่างไรให้การค้นหาเร็วขึ้น?

Filters

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

ด้วย filtered query ทำงานกับ boolean matches คุณสามารถค้นหาเอกสารทั้งหมดที่มี X ก่อนให้คะแนนว่ามี Y หรือไม่ นอกจากนี้ คุณสามารถ cache filters ได้

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

สรุป

คุณสามารถเพิ่มประสิทธิภาพคำขอของคุณได้ในไม่กี่ขั้นตอนง่ายๆ:

  • เปิดใช้งาน slow logging เพื่อให้คุณระบุคำขอที่รันนานได้
  • รันคำขอที่ระบุผ่าน _profiling API เพื่อดูเวลาของส่วนประกอบแต่ละส่วน
  • Filter, filter, filter

มีคำถามเกี่ยวกับการจัดการ Elasticsearch? เรารวมการเข้าถึงผู้ดูแลฐานข้อมูลที่มีความเชี่ยวชาญลึกซึ้งด้าน Elasticsearch ไว้กับทุกอินสแตนซ์ แม้แต่ free trials เริ่มมุ่งเน้นการพัฒนาและให้เราจัดการ Elasticsearch ให้คุณ

อยากลอง Elasticsearch 6 พร้อม Kibana ฟรี? เริ่มต้นเลยและบอกเราถ้ามีคำถาม

ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม คุณยังสามารถคลิก Sales Chat เพื่อแชททันทีและเริ่มสนทนาได้