jesterj

ตัวตลกเจ

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

งานสร้างดำเนินการบนโครงสร้างพื้นฐานที่ได้รับความกรุณาบริจาคจาก

ปัญหา

บ่อยครั้งที่โปรเจ็กต์การค้นหาเริ่มต้นด้วยการป้อนเอกสารสองสามรายการด้วยตนเองไปยังเครื่องมือค้นหา ซึ่งมักจะผ่านคุณสมบัติการประมวลผล "เพียงเพื่อการทดสอบ" ในตัวของ Solr เช่น SolrCell หรือ post.jar คุณลักษณะเหล่านี้ได้รับการจัดทำเป็นเอกสารและรวมไว้เพื่อช่วยให้ผู้ใช้เข้าใจถึงสิ่งที่พวกเขาสามารถทำได้กับ Solr โดยมีการตั้งค่าที่ยุ่งยากน้อยที่สุด

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

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

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

วิธีแก้ปัญหาของ JesterJ

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

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

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

ดูเว็บไซต์และเอกสารประกอบสำหรับข้อมูลเพิ่มเติม

เริ่มต้นใช้งาน

โปรดดูเอกสารประกอบในวิกิ

สถานะโครงการ

รุ่นปัจจุบัน : 1.0-Beta3 นี่เป็นเวอร์ชันที่ดีที่สุดที่จะใช้ และควรใช้งานได้เป็นส่วนใหญ่ (ปัญหาที่ทราบ: #189)

รุ่นถัดไป: 1.0-Beta4 จะถูกเผยแพร่เร็วๆ นี้ หากไม่พบปัญหาร้ายแรงภายในสองสัปดาห์ 1.0 จะถูกปล่อยออกมา

หมายเหตุ: รหัสปัจจุบันและรุ่น 1.0 ที่กำลังจะมาถึงมีเป้าหมายไปที่การออกแบบและโหลดใดๆ ที่สามารถให้บริการได้ด้วยเครื่องเดียว JesterJ ได้รับการออกแบบอย่างชัดเจนเพื่อใช้ประโยชน์จากเครื่องที่มีโปรเซสเซอร์จำนวนมาก คุณสามารถออกแบบแผนโดยทำซ้ำขั้นตอนที่ช้าที่สุดเพื่อบรรเทาปัญหาคอขวด แต่ละรายการที่ซ้ำกันหมายถึงเธรดเพิ่มเติมที่ทำงานในขั้นตอนนั้น มีการวางแผนการปรับขนาดเธรดอัตโนมัติสำหรับ 1.1 และการปรับขนาดข้ามเครื่องหลาย ๆ เครื่องถือเป็นสิ่งสำคัญอันดับแรกสำหรับการเปิดตัว 2.x และเช่นเคย หากคุณต้องการฟีเจอร์เหล่านี้เร็วกว่านี้ โปรดเริ่มการสนทนาและสนับสนุนการประชาสัมพันธ์หากคุณทำได้!

เวอร์ชัน JDK

ปัจจุบันมีเพียง JDK 11 เท่านั้นที่ได้รับการทดสอบเป็นประจำ การแจกจ่าย JDK 11 ใด ๆ ควรใช้งานได้ การสนับสนุน Java 17 และเวอร์ชัน LTS ในอนาคตมีการวางแผนสำหรับการเปิดตัวในอนาคต

เซิร์ฟเวอร์ดิสคอร์ด

หารือเกี่ยวกับคุณสมบัติต่างๆ ถามคำถาม ฯลฯ บน Discord: https://discord.gg/RmdTYvpXr9

คุณสมบัติ:

ในรุ่นนี้เรามีคุณสมบัติดังต่อไปนี้

• ความสามารถในการเห็นภาพโครงสร้างของแผนของคุณ (รูปแบบ .dot หรือ .png: ตัวอย่างจากการทดสอบหน่วยที่นี่ )
• เครื่องสแกนระบบไฟล์อย่างง่ายสำหรับไดรฟ์ที่ติดตั้งในเครื่อง (แทนที่สำหรับ post.jar)
• เครื่องสแกน JDBC (แทนที่ Data Import Handler!)
• เครื่องสแกนสามารถจดจำเอกสารที่พวกเขาเห็นได้ (หรือไม่ใช่แฟล็กบูลีน)
• เครื่องสแกนสามารถจดจำเนื้อหาที่อัปเดตได้ (หรือไม่ใช่แฟล็กบูลีน)
• ส่งไปยังโปรเซสเซอร์ Solr พร้อมขนาดแบตช์ที่ปรับแต่งได้
• โปรเซสเซอร์ Tika เพื่อแยกเนื้อหาจาก Word/PDF/xml/html ฯลฯ (แทนที่สำหรับ SolrCell!)
• ตัวประมวลผลแยก Stax สำหรับการแยกเอกสาร xml โดยตรง
• คัดลอกตัวประมวลผลฟิลด์เพื่อเปลี่ยนชื่อฟิลด์ต้นทางเป็นฟิลด์ดัชนีที่ต้องการ
• Regexp แทนที่โปรเซสเซอร์เพื่อแก้ไขเนื้อหาฟิลด์ หรือปล่อยฟิลด์ที่ไม่ตรงกัน
• แยกตัวประมวลผลฟิลด์เพื่อแยกค่าที่คั่นสำหรับฟิลด์หลายค่า
• วางโปรเซสเซอร์ฟิลด์เพื่อกำจัดฟิลด์ส่วนเกินที่น่ารำคาญ
• ตัวประมวลผลเทมเพลตฟิลด์สำหรับการเขียนเนื้อหาฟิลด์โดยใช้เทมเพลตความเร็ว
• ตัวประมวลผลการเข้ารหัส URL เพื่อเข้ารหัสค่าของฟิลด์และทำให้ปลอดภัยสำหรับการใช้ใน URL
• ดึงข้อมูลโปรเซสเซอร์ URL เพื่อรับหรือปรับปรุงเนื้อหาโดยติดต่อกับระบบอื่น
• บันทึกและวางโปรเซสเซอร์เมื่อคุณระบุเอกสารที่ไม่ถูกต้อง
• ตัวประมวลผลการฟอร์แมตวันที่ เนื่องจากวันที่ การจัดรูปแบบ... เสมอ ( ถอนหายใจ )
• โปรเซสเซอร์ขนาดไฟล์ที่มนุษย์สามารถอ่านได้
• ผู้ส่ง Solr เพื่อส่งเอกสารไปยัง solr เป็นกลุ่ม
• วิเคราะห์โปรเซสเซอร์ล่วงหน้าเพื่อย้ายปริมาณงานการวิเคราะห์ Solr ออกจาก Solr (เพียงให้ schema.xml ของคุณ!)
• เซิร์ฟเวอร์ Cassandra แบบฝัง (ไม่จำเป็นต้องติดตั้ง Cassandra ด้วยตัวเอง!)
• กำหนดค่า Cassandra และตำแหน่งข้อมูลได้ โดยมีค่าเริ่มต้นอยู่ที่ ~/.jj/cassandra
• รองรับเหตุการณ์การเปลี่ยนแปลงสถานะการเขียนความทนทานต่อข้อผิดพลาดไปยังเซิร์ฟเวอร์ Cassandra แบบฝัง
• API/กระบวนการเริ่มต้นสำหรับตัวประมวลผลเอกสารที่ผู้ใช้เขียน (ดูเอกสารประกอบ)
• ความครอบคลุมการทดสอบ 60% (จาโคโค)
• ไฟล์ Java ไฟล์เดียวที่เรียบง่ายเพื่อกำหนดค่าทุกอย่าง โปรแกรมเมอร์ที่ไม่ใช่ Java ต้องการเพียงทำตามตัวอย่างง่ายๆ เท่านั้น (สำหรับกรณีการใช้งานที่ไม่ต้องใช้โค้ดที่กำหนดเอง)
• หากคุณต้องการโค้ดที่กำหนดเอง โค้ดนั้นสามารถบรรจุเป็น uno-jar เพื่อให้การขึ้นต่อกันที่จำเป็นทั้งหมดและ Escape จากเวอร์ชันไลบรารีใด ๆ ที่ JesterJ ใช้! คุณแค่ต้องจัดการกับนรกขวดโหลของคุณเอง ไม่ใช่ของเรา! แน่นอนว่าคุณสามารถพึ่งพาสิ่งที่เราเตรียมไว้ให้ได้เช่นกัน classloaders สำหรับโค้ดที่กำหนดเองชอบ uno-jar ของคุณ จากนั้นตั้งค่าเริ่มต้นกลับไปเป็นอะไรก็ตามที่ JesterJ มีอยู่บน classpath
• ตัวอย่างที่รันได้เพื่อดำเนินการตามแผนที่สแกนระบบไฟล์และจัดทำดัชนีเอกสารในรูปแบบ solr

สิ่งที่ต้องทำสำหรับรุ่นสุดท้าย 1.0

• ปัญหาที่เหลืออยู่
• รุ่นเบต้า, การทดสอบ

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

แผนที่ถนน

การคาดเดาได้ดีที่สุดว่าอะไรจะเกิดขึ้นในอนาคตจะได้รับจากตัวกรองเหตุการณ์สำคัญในหน้าปัญหาของเรา