ข่าว

วงการฐานข้อมูลโอเพนซอร์สมีผู้เล่นรายใหม่กับการเปิดตัวของ HelixDB ซึ่งเป็นฐานข้อมูลแบบ graph-vector ที่เขียนด้วยภาษา Rust ออกแบบมาเฉพาะสำหรับ RAG (Retrieval Augmented Generation) และแอปพลิเคชัน AI สิ่งที่ดึงดูดความสนใจของชุมชนคือการกล่าวอ้างเรื่องประสิทธิภาพที่โดดเด่นและแนวทางที่เป็นเอกลักษณ์ในการผสมผสานฟังก์ชันการทำงานของ graph และ vectorหน้า GitHub ของ HelixDB นี้แสดงให้เห็นโครงสร้างของมันในฐานะฐานข้อมูลกราฟ-เวกเตอร์แบบโอเพนซอร์สสำหรับแอปพลิเคชัน AIการกล่าวอ้างเรื่องประสิทธิภาพที่สร้างความสงสัยทีมพัฒนา HelixDB อ้างว่าฐานข้อมูลของพวกเขาเร็วกว่า Neo4j 1000 เท่าและเร็วกว่า TigerGraph 100 เท่า ในขณะที่มีประสิทธิภาพเทียบเท่ากับ Qdrant สำหรับ vectors การกล่าวอ้างนี้ทำให้สมาชิกในชุมชนขอหลักฐาน โดยมีผู้ใช้คนหนึ่งถามตรงๆ ถึงการทดสอบประสิทธิภาพเพื่อสนับสนุนข้อกล่าวอ้างเหล่านี้ ทีม HelixDB ยอมรับว่าพวกเขาได้ทำการทดสอบประสิทธิภาพแล้ว แต่ยังไม่ได้เผยแพร่ก่อนการประกาศโครงการ และสัญญาว่าจะเพิ่มข้อมูลประสิทธิภาพโดยละเอียดในเอกสารประกอบคุณสมบัติหลักของ HelixDBรวดเร็วและมีประสิทธิภาพ: อ้างว่าเร็วกว่า Neo4j 1000 เท่า, เร็วกว่า TigerGraph 100 เท่า, และมีความเร็วเทียบเท่ากับ Qdrant สำหรับข้อมูลเวกเตอร์ออกแบบมาเพื่อ RAG: รองรับข้อมูลประเภทกราฟและเวกเตอร์โดยเฉพาะการผสมผสานกราฟและเวกเตอร์: รองรับความสัมพันธ์ระหว่างโหนด, เวกเตอร์, หรือทั้งโหนดและเวกเตอร์การจัดเก็บข้อมูล: ขับเคลื่อนด้วย LMDB (Lightning Memory-Mapped Database)รองรับ ACID: รับประกันความสมบูรณ์และความสอดคล้องของข้อมูลมิติเวกเตอร์: ปัจจุบันไม่มีการจำกัด แต่ในอนาคตอาจจะจำกัดที่ประมาณ 64,000 มิติภาษาสำหรับคิวรี: DSL แบบกำหนดเองพร้อมการตรวจสอบประเภทข้อมูลใบอนุญาต: AGPL (Affero General Public License)ความสามารถด้าน Vector และมิติฐานข้อมูลนี้ดูเหมือนจะมีการรองรับ vector ที่แข็งแกร่ง โดยนักพัฒนายืนยันว่าปัจจุบันไม่มีการจำกัดมิติของ vector พวกเขากล่าวว่าในอนาคตอาจจะมีการกำหนดขีดจำกัดที่ประมาณ 64,000 มิติ คล้ายกับฐานข้อมูล vector อื่นๆ เช่น Qdrant และ Pinecone ทีมยังเปิดเผยแผนการที่จะใช้ binary quantization ในอีกไม่กี่เดือนข้างหน้าเพื่อปรับปรุงประสิทธิภาพกับ vector ที่มีมิติสูงขึ้น แสดงให้เห็นถึงความตระหนักในการแลกเปลี่ยนประสิทธิภาพที่เกี่ยวข้องกับการดำเนินการ vectorการผสมผสาน Graph-Vector ที่ทำให้แตกต่างสิ่งที่ทำให้ HelixDB แตกต่างจากคู่แข่งเช่น KuzuDB คือแนวทางในการผสมผสานฟังก์ชันการทำงานของ graph และ vector ตามที่นักพัฒนากล่าว HelixDB รองรับการทำ incremental indexing บน vector ซึ่งอนุญาตให้มีการอัปเดตโดยไม่จำเป็นต้องทำการ re-indexing ของ vector ทั้งหมด นี่แก้ปัญหาที่มีอยู่ในบางโซลูชันที่มีอยู่ซึ่ง vector index แยกออกจากโครงสร้าง graph อย่างสมบูรณ์ ซึ่งต้องการการ re-indexing ทั้งหมดเมื่อมีการอัปเดตPretty much the same way you would with any graph DB, with the added benefit of being able to treat a vector as a node by creating those explicit relationships between them.ภาษาคิวรี่ที่กำหนดเองสร้างการถกเถียงภาษาคิวรี่ที่กำหนดเองของ HelixDB ได้สร้างปฏิกิริยาที่หลากหลาย ผู้ใช้บางคนแสดงความกังวลเกี่ยวกับการต้องเรียนรู้ภาษาเฉพาะทาง (DSL) ใหม่ โดยเฉพาะอย่างยิ่งเกี่ยวกับความสามารถในการใช้งานกับ LLM สำหรับการสร้างคิวรี่ นักพัฒนาได้ปกป้องทางเลือกนี้ โดยอธิบายว่าไม่มีภาษาที่มีอยู่ใดที่รวมฟังก์ชันการทำงานของ graph และ vector ได้อย่างเหมาะสม และพวกเขาต้องการสร้างภาษาคิวรี่ที่มีความปลอดภัยในเรื่องประเภท (type-safe) พวกเขากล่าวว่ากำลังทำงานเพื่อรวมไวยากรณ์ของพวกเขาเข้ากับโค้ด LLaMa CPP เพื่อให้แน่ใจว่า LLM สามารถสร้างคิวรี่ที่ถูกต้องตามหลักไวยากรณ์ในภาษาของพวกเขาความเข้ากันได้กับเบราว์เซอร์และการใช้งานแบบฝังตัวผู้ใช้หลายคนสอบถามเกี่ยวกับการเรียกใช้ HelixDB ในเบราว์เซอร์ผ่าน WebAssembly (WASM) สำหรับแอปพลิเคชันที่เน้นความเป็นส่วนตัวและเกี่ยวกับการใช้งานเป็นฐานข้อมูลแบบฝังตัวคล้ายกับ SQLite ทีมยอมรับว่า LMDB ซึ่งเป็นเครื่องมือจัดเก็บข้อมูลปัจจุบันของพวกเขา เป็นอุปสรรคต่อความเข้ากันได้กับเบราว์เซอร์ แต่กล่าวว่าพวกเขามีแผนที่จะพัฒนาเครื่องมือจัดเก็บข้อมูลของตัวเองที่รองรับ WASM ในขณะนี้ HelixDB ไม่สามารถทำงานเป็นฐานข้อมูลแบบฝังตัวได้ ซึ่งจำกัดกรณีการใช้งานที่เป็นไปได้บางอย่างรายการแผนงานการขยายความสามารถของประเภทข้อมูลเวกเตอร์สำหรับแอปพลิเคชัน RAGการปรับปรุงภาษาคิวรีด้วยการตรวจสอบประเภทที่แข็งแกร่งมากขึ้นการใช้งานชุดทดสอบสำหรับการทดสอบคิวรีแบบครบวงจรการสร้างเครื่องมือทดสอบการจำลองแบบกำหนดได้การเพิ่มการบีบอัดแบบไบนารีเพื่อประสิทธิภาพที่ดีขึ้นการใช้งาน BM25 สำหรับการค้นหาแบบสปาร์สการพัฒนาเครื่องมือจัดเก็บกราฟ-เวกเตอร์ภายในองค์กร (เพื่อทดแทน LMDB)การสร้างโปรโตคอลเครือข่ายและไลบรารีการแปลงข้อมูลภายในองค์กรการพัฒนาในอนาคตและแผนงานทีม HelixDB ได้วางแนวทางฟีเจอร์ที่กำลังจะมาถึงหลายอย่าง รวมถึงการค้นหาแบบ sparse โดยใช้ BM25 โดยมีสมาชิกในชุมชนบางคนแนะนำให้พิจารณาโมเดล SPLADE สำหรับความสามารถในการค้นหาที่เพิ่มขึ้น แผนงานของพวกเขายังรวมถึงการขยายความสามารถด้าน vector การเพิ่มประสิทธิภาพภาษาคิวรี่ การใช้งานชุดทดสอบ การสร้างเครื่องมือทดสอบการจำลองแบบกำหนดได้ และในที่สุดก็พัฒนาเครื่องมือจัดเก็บข้อมูล graph-vector ของตัวเองเพื่อแทนที่ LMDBเมื่อ HelixDB เข้าสู่พื้นที่การแข่งขันที่เพิ่มขึ้นของฐานข้อมูล vector และ graph การกล่าวอ้างเรื่องประสิทธิภาพและแนวทางที่เป็นเอกลักษณ์ในการรวมฟังก์ชันการทำงานเหล่านี้ได้ดึงดูดความสนใจอย่างแน่นอน ชุมชนดูเหมือนจะมีความหวังอย่างระมัดระวัง โดยหลายคนแสดงความสนใจที่จะลองใช้ฐานข้อมูลและให้ข้อเสนอแนะ ยังไม่ชัดเจนว่า HelixDB จะแตกต่างจากผู้เล่นที่มีอยู่และผู้มาใหม่รายอื่นๆ ในระยะยาวอย่างไร แต่การมุ่งเน้นที่ประสบการณ์ของนักพัฒนาและประสิทธิภาพสำหรับแอปพลิเคชัน AI ดูเหมือนจะได้รับการตอบรับที่ดีจากผู้ใช้ที่มีศักยภาพอ้างอิง: HelixDB/helix-db