semadb
v2.0.2
ไม่มีฐานข้อมูลเวกเตอร์ไฮบริดหลายดัชนี / เครื่องมือค้นหา
SEMADB เป็นหลายดัชนีหลายช่องทาง, ฐานข้อมูลเวกเตอร์ที่ทำจากเอกสารที่ทำจากเอกสาร / เครื่องมือค้นหา มันถูกออกแบบมาเพื่อนำเสนอ API JSON RESTFUL ที่ชัดเจนและใช้งานง่าย ส่วนประกอบดั้งเดิมของ Semadb ถูกสร้างขึ้นสำหรับโครงการจัดการความรู้ที่ Semafind ก่อนที่จะได้รับการพัฒนาเป็นโครงการแบบสแตนด์อโลน เป้าหมายคือการจัดหาเครื่องมือค้นหาที่เรียบง่ายทันสมัยและมีประสิทธิภาพซึ่งสามารถใช้ในแอพพลิเคชั่นที่หลากหลาย
กำลังมองหาวิธีแก้ปัญหาโฮสต์? Semadb Cloud Beta มีให้บริการบน Rapidapi
ในการเริ่มต้นจากแหล่งที่มาโปรดทำตามคำแนะนำในการติดตั้ง นั่นคือการพึ่งพาเพียงอย่างเดียวที่จำเป็นในการเรียกใช้ semadb เราพยายามที่จะทำให้ semadb เป็นตัวเองมากที่สุดและทันสมัยด้วยการเปิดตัวล่าสุด
Semadb อ่านการกำหนดค่าทั้งหมดจากไฟล์ YAML มีตัวอย่างบางส่วนที่มีอยู่ในโฟลเดอร์ config คุณสามารถเรียกใช้เซิร์ฟเวอร์เดียวโดยใช้:
SEMADB_CONFIG=./config/singleServer.yaml go run ./หากคุณใช้รหัส VS เป็นตัวแก้ไขของคุณก็มีงานที่ทำไว้ล่วงหน้าแล้วที่ทำสิ่งเดียวกัน แต่ยังเปิดคลัสเตอร์ในท้องถิ่นด้วยในโหมดดีบั๊ก
หลังจากที่คุณมีเซิร์ฟเวอร์ที่ทำงานอยู่คุณสามารถใช้ไฟล์ตัวอย่างเพื่อดูคำขอตัวอย่างที่สามารถทำได้กับเซิร์ฟเวอร์ เพื่อให้ได้ประโยชน์สูงสุดให้ติดตั้งส่วนขยายไคลเอนต์ REST ซึ่งจะช่วยให้คุณสามารถร้องขอได้โดยตรงในตัวแก้ไขและแสดงผลลัพธ์
คุณสามารถเรียกใช้ Semadb เวอร์ชันล่าสุดโดยใช้อิมเมจคอนเทนเนอร์ที่เก็บต่อไปนี้:
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:mainซึ่งจะเรียกใช้สาขาหลัก นอกจากนี้ยังมีรุ่นที่ติดแท็กสำหรับรุ่นเฉพาะ ดูรีจิสทรีคอนเทนเนอร์ของที่เก็บเสถียรและรุ่นพร้อมการผลิต
คุณสามารถสร้างและเรียกใช้ภาพคอนเทนเนอร์โดยใช้:
docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb การคงอยู่ของข้อมูล: SEMADB จัดเก็บข้อมูลในไดเรกทอรีบนดิสก์ซึ่งระบุไว้ในไฟล์กำหนดค่าเป็น rootDir โดยค่าเริ่มต้นไดเร็กทอรีข้อมูลคือ ./data และ semadb Consenable อยู่ที่ / ให้ /data เป็นจุดเมานต์ในคอนเทนเนอร์
โปรดทราบว่าเมื่อใช้ Docker ชื่อโฮสต์และการอนุญาตให้ใช้งานของ IPS อาจจำเป็นต้องปรับขึ้นอยู่กับการกำหนดค่าเครือข่ายของ Docker ปล่อยให้ชื่อโฮสต์เป็นสตริงว่างเปล่าและการตั้งค่าการอนุญาตให้ใช้งานเพื่อ '*' เปิด semadb สำหรับการเชื่อมต่อทุกครั้งที่ทำในการกำหนดค่า singleServer.yaml
ยินดีต้อนรับ! โปรดอ่านไฟล์คู่มือการสนับสนุนสำหรับข้อมูลเพิ่มเติม คู่มือการสนับสนุนยังมีข้อมูลเกี่ยวกับสถาปัตยกรรมของ SEMADB และวิธีการเริ่มต้นด้วยการพัฒนา
อัลกอริทึมการค้นหาเวกเตอร์หลักของ Semadb ขึ้นอยู่กับเอกสารการวิจัยที่ยอดเยี่ยมต่อไปนี้:
ดัชนีอื่น ๆ เช่นสตริงหรือข้อความตามวิธีดัชนีกลับด้าน ดัชนีคว่ำเป็นโครงสร้างข้อมูลที่เก็บการแมปจากเนื้อหาเช่นคำหรือตัวเลขไปยังตำแหน่งในไฟล์ฐานข้อมูลหรือในเอกสารหรือชุดเอกสาร วัตถุประสงค์ของดัชนีคว่ำคือการอนุญาตการค้นหาข้อความเต็มรูปแบบที่รวดเร็วการค้นหาคำนำหน้าสตริงการค้นหาช่วงจำนวนเต็ม ฯลฯ
Semadb ที่มีค่าการกำหนดค่าเริ่มต้นบน Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz Workstation Workstation ที่มี 16GB RAM ได้รับการเรียกคืนที่ดีในการวัดมาตรฐานมาตรฐานคล้ายกับผลลัพธ์ที่รายงาน:
| V1 | V2 | V2-PQ | V2-BQ | |||||
|---|---|---|---|---|---|---|---|---|
| ชุดข้อมูล | ระลึกถึง | QPS | ระลึกถึง | QPS | ระลึกถึง | QPS | ระลึกถึง | QPS |
| ถุงมือ -100-angular | 0.924 | 973.6 | 0.853 | 773.9 | 0.526 | 628.6 | ||
| DBPEDIA-OPENAI-100K-angular | 0.990 | 519.9 | 0.920 | 240.8 | 0.766 | 978.6 | ||
| ถุงมือ -25 แบบ | 0.999 | 1130.3 | 0.992 | 914.4 | 0.989 | 805.8 | ||
| MNIST-784-Euclidean | 0.999 | 2441.6 | 0.999 | 1267.4 | 0.928 | 571.6 | 0.667 | 2369.7 |
| Nytimes-256-angular | 0.903 | 1020.6 | 0.891 | 786.7 | 0.438 | 983.6 | ||
| SIFT-128-Euclidean | 0.999 | 1537.7 | 0.991 | 1272.9 | 0.696 | 967.4 |
ผลลัพธ์ได้รับโดยใช้มาตรฐาน Ann แบบสอบถามต่อวินาที (QPS) ใช้แคชหน่วยความจำเต็มรูปแบบที่มีเธรดเดียวคล้ายกับวิธีอื่น ๆ แต่ไม่ใช่ตัวบ่งชี้ประสิทธิภาพโดยรวมที่ดี ไปป์ไลน์เต็มจะช้าลงเนื่องจากการเดินทางแบบ end-to-end ของคำขอมีค่าใช้จ่ายของการจัดการ HTTP, การเข้ารหัส, การถอดรหัสการสืบค้น, การแยกวิเคราะห์, การตรวจสอบความถูกต้อง, การกำหนดเส้นทางคลัสเตอร์, การโทรขั้นตอนระยะไกล, การโหลดข้อมูลจากดิสก์ ฯลฯ อย่างไรก็ตามประสิทธิภาพดิบของอัลกอริทึมการค้นหาภายใน Shard เดียวในทางทฤษฎีจะคล้ายกับที่รายงานในงานวิจัย
เวอร์ชัน 1 (v1) คือการใช้การค้นหาเวกเตอร์บริสุทธิ์ดั้งเดิมของ Semadb เวอร์ชัน 2 (v2) คือการใช้งานหลายดัชนีไฮบริดการค้นหาคำหลัก ฯลฯ ซึ่งมีค่าใช้จ่ายสูงกว่าของการถอดรหัสการจัดส่งข้อมูลลงในดัชนีและการใช้ปริมาณ เวอร์ชัน 2 ด้วยการหาปริมาณผลิตภัณฑ์ (V2-PQ) และการหาปริมาณแบบไบนารี (V2-BQ) ใช้วิธีการเชิงปริมาณที่เกี่ยวข้องเพื่อลดการใช้หน่วยความจำ เราคาดว่าการเรียกคืนจะต่ำกว่าเนื่องจากวิธีการหาปริมาณสูญเสียและการค้นหานั้นประมาณ
การเริ่มต้นดิสก์เย็น อาจช้ามาก ที่ด้านล่างของโซ่ตั้งอยู่ที่ดิสก์ที่เก็บข้อมูลทั้งหมด มีแคชสองตัวในการเล่น: แคชในหน่วยความจำและแคชไฟล์ระบบปฏิบัติการ แคช OS ไม่ได้อยู่ในการควบคุมของเราและได้รับการเติมเต็มเนื่องจากไฟล์ถูกอ่านหรือเขียนถึง เมื่อมีการร้องขอกราฟดัชนีจะถูกสำรวจและโหลดคะแนนจากดิสก์ไปยังแคชระบบปฏิบัติการและถอดรหัสลงในชุดของจุดในหน่วยความจำ การดำเนินการค้นหามักจะทำการอ่านแบบสุ่มจากดิสก์เนื่องจากมันผ่านกราฟความคล้ายคลึงกัน ดังนั้นในระหว่างการเริ่มต้นเย็นอาจใช้เวลานาน (1 วินาที, 10 วินาทีหรือมากกว่า) ขึ้นอยู่กับฮาร์ดแวร์ แนะนำให้ใช้ดิสก์โซลิดสเตต (SSD) ด้วยเหตุผลนี้เนื่องจากพวกเขาให้บริการการอ่านแบบสุ่มดีขึ้น สำหรับการปรับใช้แอปพลิเคชันเดียวนี่ไม่ใช่ข้อกังวลหลักเพราะเราคาดว่าส่วนหนึ่งของข้อมูล / ดัชนีจะถูกแคชทั้งในหน่วยความจำหรือโดยระบบปฏิบัติการในระหว่างการดำเนินการ อีกทางเลือกหนึ่งคือการใช้เค้าโครงจัดเก็บข้อมูลที่กำหนดเองบนดิสก์ดังนั้นบล็อก / หน้าจะจัดเรียงได้ดีขึ้นกับเพื่อนบ้านของโหนดในกราฟความคล้ายคลึงกัน
การปรับสเกลแนวนอนอัตโนมัติ : จำนวนเซิร์ฟเวอร์ใน SEMADB สามารถปรับได้ แต่จะซิงค์เฉพาะเมื่อเริ่มต้น การแฮ็ก rendezvous ที่ใช้จะย้ายจำนวนข้อมูล 1/n ไปยังเซิร์ฟเวอร์ใหม่หรือย้ายข้อมูลเซิร์ฟเวอร์ที่ถูกลบกลับไปยังส่วนที่เหลือ เนื่องจากสิ่งนี้เกิดขึ้นเมื่อเริ่มต้นมันจึงมุ่งเน้นไปที่การปรับขนาดการปรับใช้ล่วงหน้ามากกว่าภายใต้โหลดสด การปรับสเกลอัตโนมัติแบบสดนั้นยากที่จะดำเนินการอย่างปลอดภัยในขณะที่ฐานข้อมูลทำงานเนื่องจากสภาพการแข่งขันทั่วทั้งเซิร์ฟเวอร์ ข้อผิดพลาดบางอย่างคือ: เซิร์ฟเวอร์ล้าหลังในการกำหนดค่าการส่งข้อมูลไปยังเซิร์ฟเวอร์เก่าในขณะที่การถ่ายโอนข้อมูลกำลังเกิดขึ้นคำขอของผู้ใช้จะต้องจัดการข้อมูลที่ผิดพลาดใด ๆ จะต้องมาถึงเซิร์ฟเวอร์ที่ถูกต้องในที่สุดระบบจะต้องกู้คืนจากสถานการณ์แยกสมองหากเครือข่ายถูกพาร์ติชัน ฐานข้อมูลแบบกระจายจำนวนมากรวมเครื่องจักรเพิ่มเติมที่เพิ่มความซับซ้อนอย่างมีนัยสำคัญในการจัดการเหล่านี้เช่นคีย์เวอร์ชันนาฬิกาเวกเตอร์ ฯลฯ ในขณะนี้คุณสามารถปรับเซิร์ฟเวอร์และรีสตาร์ทคลัสเตอร์เพื่อแจกจ่ายข้อมูลอีกครั้ง
ไม่มีการเขียนความพร้อมใช้งานสูง : SEMADB ได้รับการปรับให้เหมาะสมสำหรับการค้นหาปริมาณงานหนัก การดำเนินการรวบรวมและการเขียนจุดต้องการทั้งหมดที่เกี่ยวข้อง (เซิร์ฟเวอร์ที่ได้รับข้อมูลแจกจ่าย) เพื่อเข้าร่วม ในเส้นทางการค้นหาความล้มเหลวสามารถทนได้เนื่องจากเป็นการค้นหาแบบสุ่มและการลดลงของประสิทธิภาพเป็นครั้งคราวเนื่องจากเศษที่ไม่สามารถใช้งานได้สามารถยอมรับได้ เราขนถ่ายระบบที่มีสุขภาพดีในความล้มเหลวของเซิร์ฟเวอร์ทางกายภาพไปยังเครื่องมือ orchestration คอนเทนเนอร์เช่น Kubernetes เราคิดว่าสถานะที่กำหนดค่าของ SEMADB จะได้รับการดูแลอย่างแข็งขันและดังนั้นจึงไม่มีอัลกอริทึมการค้นพบเพียร์หรือฉันทามติในการออกแบบ ตัวเลือกการออกแบบนี้ทำให้สถาปัตยกรรมของ SEMADB และช่วยง่ายขึ้นอีกครั้งด้วยการพัฒนาอย่างรวดเร็ว การออกแบบดั้งเดิมรวมถึงกลไกฉันทามติเช่นแพและระบบกระจายตัวเองอย่างเต็มที่พร้อมการค้นพบเพียร์ แต่สิ่งนี้ถือว่าเป็นไปมากเกินไป
มีการค้นหาเวกเตอร์โอเพนซอร์ซและโครงการค้นหาเครื่องมือค้นหามากมาย อาจเป็นประโยชน์ในการเปรียบเทียบ semadb กับบางส่วนของพวกเขาเพื่อดูว่าหนึ่งเหมาะกับกรณีการใช้งานของคุณดีกว่า:
