การจัดทำดัชนีเอกสารน้ำหนักเบาเพื่อจัดการระเบียนที่อาจเกิดขึ้นน้อยกว่า 250k

เมื่อเร็ว ๆ นี้ฉันพบว่าตัวเองกำลังสับสนกับข้อ จำกัด ของเอ็นจิ้นการจัดทำดัชนีเอกสาร ฉันกำลังพัฒนาเว็บไซต์ขนาดเล็กที่ต้องการความสามารถในการค้นหาที่มีประสิทธิภาพ แต่เนื่องจากข้อ จำกัด ด้านฮาร์ดแวร์ของพวกเขาฉันจึงไม่สามารถปรับใช้โซลูชัน Lucene-ish (เช่น Solr หรือ ElasticSearch ได้ตามปกติ) เพื่อจัดการกับความต้องการนี้

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

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

• การค้นหา wildcard แบบเต็มครอบคลุมอาจทำให้ระบบช้าลงอย่างเจ็บปวด (โดยเฉพาะโฮสต์ที่ใช้ร่วมกัน) และทำให้ฐานข้อมูลของคุณชะงักงันโดยเฉพาะอย่างยิ่งถ้าคุณมีคำถามที่ซับซ้อนและมีการเข้าร่วมจำนวนมาก

• คุณต้องทำหลายแบบสอบถามในคำขอเดียวจากผู้ใช้ คุณอาจได้รับสิ่งนี้ด้วยข้อความค้นหาที่ซับซ้อนมากขึ้น แต่ดูจุดก่อนหน้า

• โดยทั่วไปแล้วฟีเจอร์ที่ขาดอยู่ในเอ็นจิ้นข้อความแบบเต็ม

ฐานข้อมูลมีปัญหาแบบเดียวกันกับที่ต้องติดตั้งเป็นเซิร์ฟเวอร์จากนั้น SQLite ก็มาพร้อมกันและทันใดนั้นเราก็สามารถปรับใช้ฐานข้อมูลที่อยู่ในตัวเองในไฟล์เดียว Googling ของฉันไม่ได้ทำอะไรเลย - สงสัยว่ามีบางอย่างที่เป็นเช่นนี้สำหรับการจัดทำดัชนี / การค้นหาข้อความแบบเต็ม

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

คุณก็รู้ว่าฉันต้องบอกว่าใช้ Redis

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

• นับเอกสารของคำแต่ละคำในพจนานุกรมคำหลัก ติดตามการนับความนิยมของแต่ละคำสำหรับโครงการทั้งหมด เพิ่มน้ำหนักให้กับตัววนซ้ำสำหรับการนับนี้หากคุณสามารถตรวจจับความเกี่ยวข้องสูงในเอกสารหรือชุด
  
  สิ่งแรกที่คุณทำคือให้รายการคำที่รวมทุกอย่างในชุดทั้งหมดของคุณ ไม่พบสิ่งใดในรายการนั้นคืนค่าอัตโนมัติของ 'ไม่มีผลลัพธ์' ฉันขอแนะนำให้จัดอันดับผลลัพธ์ที่ต่ำกว่า 5-20% ของความนิยมต่ำสุด (เมื่อเรียกใช้คำค้นหาในดัชนี) เพียงแค่บอกว่าไม่มีผลลัพธ์ '

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

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

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

• ยิ่งคุณแยกข้อมูลของคุณและรักษากลุ่มที่เกี่ยวข้องซึ่งกันและกันในการใช้งานจริงได้ดีเท่าไร

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

• คุณต้องคอยดูการอัพเดทเอกสารหรือไม่? Chronjobs / shell script หรืองานที่กำหนด / สคริปต์ชุดสามารถช่วยได้ มีตัวเลือกต่าง ๆ สำหรับการตั้งเวลาและการเขียนสคริปต์แม้ว่าจะชัดเจน

• ดิสก์เสียเพิ่มความเร็วลดความซับซ้อน บันทึกต้นไม้หลายต้นของเอกสารของคุณและ / หรือต้นไม้แห่งการเชื่อมโยงไปยังเอกสาร ค้นหาเฉพาะต้นไม้ที่ตรงตามเกณฑ์หรืออย่างน้อยก็ต้องการให้ได้ผลเร็วกว่าในกรณีส่วนใหญ่

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

• หลายสิ่งหลายอย่าง

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