LatticeDB جست‌وجوی برداری در مقیاس یک میلیون داده را به ۰.۸۳ میلی‌ثانیه رساند

اگر امروز برای مدیریت حافظهٔ عامل‌های هوش مصنوعی خود بین سه پایگاه‌داده مختلف جابه‌جا می‌شوید، LatticeDB می‌تواند کل این زیرساخت را به یک فایل ساده تبدیل کند. این ابزار اکنون قادر است در میان یک میلیون بردار، ۱۰ همسایه نزدیک (10-NN) را در تنها ۰.۸۳ میلی‌ثانیه و با دقت ۱۰۰٪ بازیابی کند.

بسیاری از توسعه‌دهندگان هوش مصنوعی در حال حاضر با یک پشتهٔ تکه‌تکه دست‌وپنجه نرم می‌کنند؛ آن‌ها برای متادیتا از پایگاه‌داده‌های رابطه‌ای، برای بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایهٔ چه کلمات دیگری است — از ذخیره‌سازهای برداری و برای روابط پیچیده از گراف استفاده می‌کنند. این معماری باعث ایجاد تأخیر در شبکه و دشواری در همگام‌سازی داده‌ها می‌شود. LatticeDB به عنوان جایگزینی «محلی-محور» (Local-first) معرفی شده که برای یک پردازش مالک روی یک ماشین طراحی شده و بدون نیاز به هیچ‌گونه پیکربندی (Zero-config) اجرا می‌شود.

تصور کنید ابزاری دارید که می‌توانید در آن یک تکه متن را از طریق شباهت برداری پیدا کنید، سپس به سند مادر آن بروید و در نهایت نویسنده را شناسایی کنید؛ همه این‌ها در یک پرس‌وجوی واحد رخ می‌دهد. این هسته اصلی LatticeDB است که پایگاه‌داده را شبیه به SQLite به یک فایل قابل حمل تبدیل کرده، اما آن را برای ساختارهای متصل مورد نیاز عامل‌های هوش مصنوعی (AI Agents) بهینه کرده است. این رویکرد در راستای بهینه‌سازی زیرساخت‌های محلی است، مشابه آنچه در توسعه BriskDB برای ترکیب سادگی SQLite با قدرت Rust دنبال شد.

فلسفه هسته و زمینه

طبق مستندات پروژه، LatticeDB یک پایگاه‌داده گراف ویژگی (Property-graph) است که نمایه‌سازی برداری و متنی بومی دارد. این موتور به‌طور خاص برای بارهای کاری با روابط زیاد روی یک ماشین واحد طراحی شده است. موتور بر اساس فلسفه «یک فایل، یک لایه پرس‌وجو، یک لاگ رویداد» عمل می‌کند. کل پایگاه‌داده شما یک فایل قابل حمل است و هیچ سروری برای مدیریت وجود ندارد.

این معماری برای بارهای کاری مدرن خاصی ساخته شده است. اگرچه این موارد تعریف خودِ موتور نیستند، اما سیستم برای تولید بازیابی‌افزا (Graph RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد —، حافظهٔ عامل‌ها و ابزارهای دانش محلی بهینه شده است. با ترکیب پیمایش گراف، شباهت برداری HNSW و جست‌وجوی متنی BM25 در یک زبان پرس‌وجو، نیاز به همگام‌سازی سه نوع پایگاه‌داده مختلف از بین می‌رود. این ادغام قابلیت‌های مختلف در یک موتور واحد، یادآور رویکرد Rayforce در ایجاد یک موتور واحد برای تحلیل‌های ستونی و پیمایش گراف است.

اهداف طراحی و سازوکارها

هدف اصلی LatticeDB حذف زیرساخت‌های پیچیده برای داده‌های معنایی و متصل است. این موتور یک لایه پرس‌وجوی واحد فراهم می‌کند که در آن پیمایش گراف، شباهت برداری HNSW و جست‌وجوی متنی BM25 در کنار هم قرار دارند. این قابلیت به توسعه‌دهندگان اجازه می‌دهد پرس‌وجوهای ترکیبی پیچیده را اجرا کنند؛ مثلاً تکه‌های متنی مشابه یک پرس‌وجو را بیابند، به سند آن‌ها بروند و سپس نویسنده را شناسایی کنند، بدون اینکه محیط موتور را ترک کنند.

علاوه بر بازیابی، این موتور یک لاگ رویداد بادوام (Durable Event Log) را ادغام کرده است. استریم‌های نام‌گذاری شده و یک Changefeed داخلی برای گراف، از همان مسیر تراکنش و لاگ پیش‌نویس (WAL) استفاده می‌کنند که نوشته‌های گراف از آن می‌گذرند. این امر تضمین می‌کند که رویدادهای برنامه و تغییرات گراف به‌صورت اتمیک در همان فایل قابل حمل به هم متصل شوند.

از نظر عملیاتی, LatticeDB از مدل سخت‌گیرانه «تک‌نویسنده» (Single-writer) پیروی می‌کند؛ یعنی یک پردازش مالک در یک ماشین مدیریت فایل را بر عهده دارد. این سیستم برای عملیات بدون پیکربندی طراحی شده است؛ شما صرفاً یک فایل را باز می‌کنید و شروع به کار می‌کنید.

برای تضمین قابلیت اطمینان، سیستم از یک لاگ پیش‌نویس (WAL) برای بازیابی پس از خرابی (Crash Recovery) استفاده می‌کند. همچنین از بازاستفاده آنلاین لیست‌های آزاد (Online Freelist Reuse) و مکانیزم "lattice compact" برای بازپس‌گیری ایمن انتهای فیزیکی داده‌ها بهره می‌برد تا ذخیره‌سازی تک‌فایلی در طول زمان کارآمد باقی بماند.

معماری فنی و عملکرد

این موتور با زبان Zig نوشته شده است و از مدل تک‌نویسنده با پشتیبانی WAL برای بازیابی پس از خرابی استفاده می‌کند. بر اساس بنچمارک‌های پروژه روی پردازنده Apple M1 (تک‌رشته‌ای، با بافر پول مقیاس‌پذیر)، کارایی خیره‌کننده‌ای در عملیات پایه ثبت شده است:

• جست‌وجوی گره (Node Lookups): ۰.۱۳ میکروثانیه (۷.۹ میلیون عملیات در ثانیه) — هدف پروژه زیر ۱ میکروثانیه بود. این پیاده‌سازی B+Tree با RocksDB در حافظه برابری کرده و روی دیسک ۲۳ برابر سریع‌تر از SQLite است.
• ایجاد گره (Node Creation): ۰.۶۵ میکروثانیه (۱.۵ میلیون عملیات در ثانیه).
• پیمایش یال (Edge Traversal): ۹ میکروثانیه (۱۱۱ هزار عملیات در ثانیه).
• جست‌وجوی متنی (۱۰۰ سند): ۱۹ میکروثانیه (۵۳ هزار عملیات در ثانیه).

جست‌وجوی برداری در مقیاس بالا

برای بازیابی معنایی، LatticeDB جست‌وجوی تقریبی نزدیک‌ترین همسایه HNSW (Hierarchical Navigable Small World) را پیاده‌سازی می‌کند. این سیستم از انتخاب همسایه اکتشافی (الگوریتم ۴ مقاله HNSW) برای اتصال متنوع گراف و ضرب داخلی پیش‌نرمال‌شده برای محاسبه سریع فاصله کسینوسی استفاده می‌کند. برای بهینه‌سازی حافظه، از تکنیک connection page packing بهره می‌برد که منجر به کاهش حدود ۴.۵ برابری مصرف رم می‌شود.

در تست‌های انجام شده با بردارهای ۱۲۸-بعدی کسینوسی (M=16, ef_construction=200, ef_search=64, k=10)، سیستم مقیاس‌پذیری زیر-خطی (O(log N)) را حفظ می‌کند. معیارهای عملکرد عبارتند از:

• ۱,۰۰۰ بردار: تأخیر میانگین ۶۵ میکروثانیه، بازیابی ۱۰۰٪، ۱ مگابایت حافظه.
• ۱۰,۰۰۰ بردار: تأخیر میانگین ۱۷۴ میکروثانیه، بازیابی ۹۹٪، ۱۰ مگابایت حافظه.
• ۱۰۰,۰۰۰ بردار: تأخیر میانگین ۴۳۸ میکروثانیه، بازیابی ۹۹٪، ۱۰۱ مگابایت حافظه.
• ۱,۰۰۰,۰۰۰ بردار: تأخیر میانگین ۰.۸۳ میلی‌ثانیه، بازیابی ۱۰۰٪، ۱,۰۴۰ مگابایت حافظه.

در مقیاس یک میلیون بردار، تأخیر P99 برابر ۱.۸ میلی‌ثانیه است. این عملکرد با سیستم‌های سرور-محور مثل Weaviate (۱.۴ میلی‌ثانیه میانگین) و Qdrant (حدود ۱ تا ۲ میلی‌ثانیه) رقابت می‌کند، اما بدون تأخیر شبکه. همچنین به‌طور قابل‌توجهی سریع‌تر از جایگزین‌های محلی مثل LanceDB (۳ تا ۵ میلی‌ثانیه) و Chroma (۴ تا ۵ میلی‌ثانیه) است و بسیار سریع‌تر از افزونه‌های brute-force مانند sqlite-vec است که برای یک میلیون بردار ۱۷ میلی‌ثانیه زمان می‌برد.

حساسیت برداری و تنظیمات

کیفیت جست‌وجو از طریق پارامتر ef_search قابل تنظیم است. بنچمارک‌ها در مقیاس یک میلیون بردار، یک توازن (Trade-off) واضح بین تأخیر و دقت بازیابی را نشان می‌دهند:

• ef_search 16: تأخیر ۵۰۶ میکروثانیه، بازیابی ۵۷٪.
• ef_search 32: تأخیر ۱.۹ میلی‌ثانیه، بازیابی ۷۹٪.
• ef_search 64: تأخیر ۹۹۰ میکروثانیه، بازیابی ۱۰۰٪.
• ef_search 128: تأخیر ۳.۲ میلی‌ثانیه، بازیابی ۱۰۰٪.
• ef_search 256: تأخیر ۱۱.۶ میلی‌ثانیه، بازیابی ۱۰۰٪.

پیمایش گراف در برابر SQLite

در حالی که SQLite می‌تواند گراف‌ها را با استفاده از CTEهای بازگشتی (Recursive Common Table Expressions) و حذف تکراری‌ها با UNION شبیه‌سازی کند، LatticeDB از BFS با یک کش مجاورتی (Adjacency Cache) و ردیابی بازدیدشده‌ها با bitset استفاده می‌کند. این انتخاب معماری منجر به افزایش سرعت عظیم با افزایش عمق پیمایش می‌شود.

در یک گراف شبکه اجتماعی با توزیع درجه قانون توان (Power-law) و کش مجاورتی گرم‌شده، تفاوت‌ها چشمگیر است:

• مقیاس کوچک (۱۰ هزار گره، ۵۰ هزار یال): پیمایش ۱-گام ۲۳ برابر سریع‌تر است (۵۶۰ نانوثانیه در برابر ۱۳ میکروثانیه)؛ مسیرهای متغیر (۱ تا ۵) ۵۲ برابر سریع‌تر هستند (۸۲.۴ میکروثانیه در برابر ۴.۳ میلی‌ثانیه).
• مقیاس متوسط (۱۰۰ هزار گره، ۵۰۰ هزار یال): پیمایش ۱-گام ۳۶ برابر سریع‌تر است (۸ میکروثانیه در برابر ۲۹۰ میکروثانیه)؛ مسیرهای متغیر (۱ تا ۵) ۷۵ برابر سریع‌تر هستند (۱۳۴.۴ میکروثانیه در برابر ۱۰.۱ میلی‌ثانیه).
• پیمایش با محدودیت عمق: در عمق ۱۰، LatticeDB حدود ۳۹۰ برابر سریع‌تر است (۳۱۱ میکروثانیه در برابر ۱۲۱ میلی‌ثانیه). در عمق ۲۵، این رقم به ۱,۸۴۸ برابر می‌رسد (۳۱۸ میکروثانیه در برابر ۵۸۷ میلی‌ثانیه). در عمق ۵۰، فاصله به ۲,۸۱۹ برابر افزایش می‌یابد (۵۰۰ میکروثانیه در برابر ۱.۴ ثانیه).

جست‌وجوی متنی (FTS)

فراتر از بردارها و گراف‌ها، این موتور شامل یک نمایه‌ساز معکوس با رتبه‌بندی BM25، توکن‌بندی (Tokenization) و ریشه‌یابی (Stemming) است. این قابلیت اجازه جست‌وجوی لغت‌نامه‌ای و تطبیق فازی با استفاده از فاصله لِوِن‌اشتاین (Levenshtein distance) قابل تنظیم را می‌دهد.

بنچمارک‌ها نشان می‌دهند که FTS در LatticeDB تقریباً ۳۰۰ برابر سریع‌تر از افزونه FTS5 در SQLite است (۱۹ میکروثانیه در برابر کمتر از ۶ میلی‌ثانیه). این عملکرد آن را در همان رده کتابخانه Rust-based Tantivy (۱۰ تا ۱۰۰ میکروثانیه) قرار می‌دهد و به‌طور قابل‌توجهی سریع‌تر از گزینه‌های سرور-محور مانند Elasticsearch (۱ تا ۱۰ میلی‌ثانیه) می‌کند.

ادغام برای توسعه‌دهندگان و API

LatticeDB یک API سی (C) تمیز با بایندینگ‌های سطح بالا برای چندین زبان محبوب ارائه می‌دهد. گزینه‌های نصب و ادغام عبارتند از:

• CLI: نصب از طریق دستور curl -fsSL https://raw.githubusercontent.com/jeffhajewski/latticedb/main/dist/install.sh | bash.
• پایتون: ارائه wheelهای منتشر شده که liblattice را شامل می‌شوند. نصب از سورس می‌تواند از LATTICE_BUNDLE_LIB_DIR=/path/to/lib برای باندل کردن کتابخانه بومی استفاده کند.
• تایپ‌اسکریپت/Node.js: در دسترس از طریق npm (@hajewski/latticedb). در نصب از سورس می‌توان از LATTICE_BUNDLE_LIB_DIR و دستور npm run bundle:native استفاده کرد.
• گو (Go): از گردش‌کار cgo استفاده می‌کند. توسعه در مخزن می‌تواند از تگ -tags repolocal در برابر zig-out/lib استفاده کند.

زبان پرس‌وجو و ویژگی‌ها

این موتور زیرمجموعه‌ای از زبان پرس‌وجوی Cypher را پشتیبانی می‌کند. کاربران می‌توانند از دستورات MATCH, WHERE, RETURN, CREATE, DELETE, SET, REMOVE, ORDER BY, LIMIT, SKIP و DETACH DELETE استفاده کنند. همچنین از MERGE, WITH, UNWIND و توابع تجمیعی مانند count, sum, avg, min, max و collect پشتیبانی می‌کند.

عملگرهای تخصصی عبارتند از:

• <=> برای محاسبه فاصله برداری.
• @@ برای جست‌وجوی متنی.
• $name برای تعریف پارامترها.

سازوکارهای پیشرفته داده

LatticeDB فراتر از پرس‌وجوهای ساده، چندین سازوکار داده بادوام را ارائه می‌دهد:

• استریم‌های نام‌گذاری شده بادوام: شامل آفست‌های صریح مصرف‌کننده و قابلیت‌های trim دستی.
• Changefeedهای گراف: یک changefeed داخلی که مسیر تراکنش/WAL را با نوشته‌های گراف به اشتراک می‌گذارد تا سازگاری سخت‌گیرانه (Strict Consistency) تضمین شود.
• نمایه‌سازی ویژگی‌ها: پشتیبانی از نمایه‌سازهای برابری صریح و بادوام برای ویژگی‌های محدود شده گره‌ها و یال‌ها.
• قابلیت‌های پیمایش: پشتیبانی از پیمایش چند-گام و مسیرهای با طول متغیر (مثلاً *1..3).

مثال پیاده‌سازی

در یک پیاده‌سازی معمولی پایتون، توسعه‌دهنده می‌تواند یک گراف دانش با اسناد و نویسندگان ایجاد کند، بردارها را ذخیره نماید و متن‌ها را در یک تراکنش نمایه‌سازی کند. سپس یک پرس‌وجو می‌تواند هر سه حالت را ترکیب کند:

MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person) WHERE chunk.embedding <=> $query_vector < 0.3 AND doc.content @@ "neural networks" RETURN doc.title, chunk.text, author.name ORDER BY chunk.embedding <=> $query_vector LIMIT 10

چه زمانی از LatticeDB استفاده نکنیم؟

با وجود سرعت بالا، توسعه‌دهندگان پروژه اشاره می‌کنند که در سناریوهای خاص، ابزارهای دیگر برتری دارند:

• دسترسی شبکه‌ای هم‌زمان: به دلیل مدل تک‌نویسنده محلی، برای برنامه‌هایی که نیاز به چندین نویسنده هم‌زمان روی شبکه دارند مناسب نیست. در این موارد، Neo4j، PostgreSQL یا سایر پایگاه‌داده‌های کلاینت-سرور توصیه می‌شوند.
• داده‌های جدولی: اگر داده‌ها به‌طور طبیعی در سطر و ستون می‌گنجند (مانند سوابق فروش یا سری‌های زمانی)، یک پایگاه‌داده رابطه‌ای مثل SQLite یا PostgreSQL ساده‌تر و به همان اندازه سریع است.
• مقیاس عظیم: برای مجموعه‌داده‌هایی که فراتر از یک ماشین به میلیاردها گره می‌رسند و نیاز به sharding یا replication دارند، سیستم‌های توزیع‌شده مثل Neo4j cluster، Dgraph یا Amazon Neptune انتخاب درست هستند.
• نیاز به Cypher کامل: LatticeDB هنوز OPTIONAL MATCH یا رویه‌های CALL را پیاده‌سازی نکرده است. اگر این‌ها ضروری هستند، Neo4j پیاده‌سازی کامل است.
• نیازهای اکوسیستم: برای کسانی که به ابزارهای بصری‌سازی بالغ، داشبوردهای مدیریتی و دهه‌ها منابع جامعه کاربری نیاز دارند، PostgreSQL یا Neo4j برتر هستند.

این تغییر به سمت پایگاه‌داده‌های چند-مدالی محلی، نشان‌دهنده آینده‌ای است که در آن عامل‌های هوش مصنوعی «مغز» خود را به صورت یک فایل واحد حمل می‌کنند. با حذف فاصله بین نمایه‌ساز برداری و یال‌های گراف، LatticeDB پیچیدگی معماری خط‌لوله‌های Graph RAG را کاهش می‌دهد.