Inside Omnigraph: Lakehouse Graph Engine with Git-Style Branching for Fleets of AI Agents Khám Phá Omnigraph: Lakehouse Graph Engine Với Nhánh Rẽ Git Dành Cho Đội Ngũ Tác Tử AI

1. 🌐 Khủng Hoảng Đồng Bộ Dữ Liệu Trong Đội Ngũ Tác Tử AI

Khi hàng trăm tác tử AI (autonomous coding agents hoặc reasoning assistants) cùng vận hành song song trên một cơ sở tri thức đồ thị chung, các mô hình cơ sở dữ liệu truyền thống thường gặp bế tắc trước hai rào cản kỹ thuật cốt lõi:

1. Xung đột ghi và ô nhiễm ngữ cảnh: Nếu các agent cùng ghi trực tiếp vào một đồ thị biến đổi (mutable graph), xung đột dữ liệu (race conditions) và sự cố topo không nhất quán sẽ lập tức làm ô nhiễm bộ nhớ của toàn hệ thống. Ngược lại, nếu mỗi agent làm việc trong một cơ sở dữ liệu cô lập hoàn toàn, tri thức mới được tạo ra sẽ bị phân mảnh và không thể tổng hợp về trung tâm.
2. Gánh nặng chi phí vận hành: Các cơ sở dữ liệu đồ thị truyền thống (như Neo4j, TigerGraph) đòi hỏi các server cấu hình RAM khủng, ổ cứng khối (block storage) liên tục hoạt động. Để phục vụ truy vấn đa dạng của agent, hệ thống còn phải tích hợp thêm Milvus/Pinecone cho vector và Elasticsearch cho tìm kiếm từ khóa, dẫn đến kiến trúc vô cùng cồng kềnh.

flowchart LR
    subgraph Traditional ["Kiến Trúc Truyền Thống: Phân Mảnh & Nặng Nề"]
        direction TB
        A1[Đội Ngũ AI Agent] --> DB[(Database Đồ Thị\nNeo4j / Tốn RAM)]
        A1 --> VEC[(Vector Index\nMilvus / Pinecone)]
        A1 --> FTS[(Search Engine\nElasticsearch)]
        DB -.-> Sync["Xung Đột Đồng Bộ & Tranh Chấp Khóa Phức Tạp"]
    end

    subgraph OmnigraphArch ["Omnigraph: Kiến Trúc Lakehouse Đồ Thị Chuẩn"]
        direction TB
        B1[Đội Ngũ Agent Trên Nhánh Cô Lập] --> Engine[Omnigraph Engine\nRust + Arrow + DataFusion]
        Engine --> Manifest["Cửa Commit Duy Nhất CAS\n(Nhật ký __manifest)"]
        Manifest --> Storage[("Object Storage\nS3 / MinIO / R2 / RustFS\nĐịnh Dạng Cột Lance")]
    end

Để giải quyết triệt để bài toán này, Omnigraph (ModernRelay/omnigraph) mang đến một kiến trúc cơ sở dữ liệu đồ thị chuẩn lakehouse hoàn toàn mới được viết bằng Rust. Bằng cách vận hành trực tiếp trên object storage (AWS S3, Cloudflare R2, MinIO hoặc RustFS) thông qua định dạng cột Lance, Omnigraph quản lý đồ thị giống như một kho mã nguồn Git: hỗ trợ phân nhánh cô lập cho từng agent, tiếp quản con trỏ không sao chép dữ liệu (zero-copy), thuật toán hợp nhất đồ thị 3 chiều (3-way merge) và hợp nhất truy vấn đa phương thức trong một runtime duy nhất.

2. 🏛️ Kiến Trúc Hệ Thống & Các Lớp Phân Tách

Mã nguồn Omnigraph được chia nhỏ thành các crate độc lập trong workspace Cargo, đảm bảo ranh giới chịu trách nhiệm rõ ràng giữa trình biên dịch, tối ưu kế hoạch thực thi và lớp lưu trữ:

flowchart TB
    CLI[omnigraph CLI] --> CLUSTER[omnigraph-cluster]
    CLI --> ENGINE[omnigraph Engine Core]
    HTTP[omnigraph-server] --> ENGINE
    HTTP --> POLICY[omnigraph-policy / Cedar]

    CLUSTER --> STORAGE[omnigraph-storage]
    CLUSTER --> ENGINE

    ENGINE --> COMPILER[omnigraph-compiler\nPhân Tích .pg Schema & .gq AST]
    ENGINE --> PLANNER[omnigraph-planner\nTối Ưu Hóa Chi Phí & Kế Hoạch]
    ENGINE --> POLICY
    ENGINE --> STORAGE
    ENGINE --> LANCE[Tầng Lance Substrate\nDataset Cột Apache Arrow]

    STORAGE --> OBJECTS[Object Storage: S3 / Azure Blob / MinIO / Local FS]
    LANCE --> OBJECTS

Chi Tiết Trách Nhiệm Các Module Cốt Lõi

3. 🔒 Giao Thức Commit CAS Qua Cửa Duy Nhất (Single Publication Door)

Trên nền tảng object storage, việc đảm bảo tính toàn vẹn ACID khi thay đổi đồng thời nhiều bảng (bảng nốt và bảng cạnh) mà không sử dụng lock server trung tâm là bài toán cực kỳ hóc búa. Các kiến trúc non nớt rất dễ rơi vào trạng thái nốt đã ghi thành công nhưng cạnh chưa kịp ghi, làm sai lệch topo đồ thị.

Omnigraph hiện thực hóa cơ chế toàn vẹn dữ liệu hoàn hảo bằng Giao thức commit qua cửa duy nhất (crates/omnigraph/src/db/manifest.rs và docs/dev/writes.md):

sequenceDiagram
    autonumber
    participant Agent as Agent / Thao Tác Ghi
    participant Staging as MutationStaging
    participant Tables as Lance Table Datasets
    participant Manifest as Nhật Ký __manifest (CAS)
    participant Promotion as Thăng Hạng Con Trỏ HEAD

    Agent->>Staging: Tập hợp các mutation nốt/cạnh đã kiểm tra hợp lệ
    Staging->>Tables: Stage các transaction Lance (detached commits)
    Note over Tables: Ghi các fragment dữ liệu mới & tạo detached version<br/>Con trỏ HEAD tuyến tính của bảng không bị dịch chuyển
    Staging->>Manifest: Ghi CAS có điều kiện kèm toàn bộ Pin bảng & Lineage
    alt CAS Thành Công
        Manifest-->>Agent: Xác nhận commit đồ thị (Tất cả bảng hiển thị đồng thời)
        Agent-)Promotion: Bất đồng bộ thăng hạng HEAD của bảng lên version đã ghim
    else CAS Bị Xung Đột Điều Kiện
        Manifest-->>Agent: Err(Conflict) - Hủy bỏ staging
        Note over Staging: Các version detached không có ai trỏ tới<br/>GC sẽ tự động dọn dẹp an toàn sau này
    end

Các Đặc Điểm Bất Biến Của Detached Commits

1. Không Di Chuyển HEAD Của Bảng Trước: Khi thêm nốt hoặc cạnh, Omnigraph chỉ ghi các file fragment bất biến lên object storage và tạo ra phiên bản độc lập (detached commit). Con trỏ HEAD của từng bảng hoàn toàn đứng yên.
2. Ghim Trạng Thái Đồng Khối Vào Manifest: Toàn bộ version của các bảng tham gia, transaction UUID và thông tin lịch sử nhánh đồ thị được gói gọn vào một dòng bản ghi duy nhất trong __manifest. Một thao tác ghi nguyên tử CAS duy nhất quyết định sự thay đổi của cả đồ thị.
3. An Toàn Khi Sập Nguồn Mà Không Cần File Undo Log: Nếu máy chủ hoặc agent bị sập giữa chừng trước khi ghi manifest, các mảnh dữ liệu đã đẩy lên S3 hoàn toàn vô hình đối với mọi truy vấn vì không có manifest nào tham chiếu đến chúng. Không cần chạy các tiến trình rollback phức tạp; tác vụ dọn rác nền sẽ thu hồi các mảnh mồ côi này.

4. 🌿 Phân Nhánh & Hợp Nhất Đồ Thị 3 Chiều Kiểu Git

Tương tự như quy trình lập trình viên tạo nhánh Git để phát triển tính năng độc lập, Omnigraph cho phép mỗi tác tử AI tự tạo nhánh đồ thị riêng:

# Agent tạo nhánh làm việc độc lập từ main
omnigraph branch create agent-research-task-42 --from main

Khi agent hoàn thành nhiệm vụ, các thay đổi sẽ được hòa nhập vào nhánh main bằng hàm Omnigraph::branch_merge.

4 Tuyến Đường Hợp Nhất Bảng (Table Merge Routes)

Omnigraph tự động phân loại và áp dụng chiến lược hợp nhất tối ưu cho từng bảng dữ liệu:

flowchart TD
    Start["So Sánh Vòng Đời Của Bảng\n(Base, Nhánh Nguồn, Nhánh Đích)"] --> CheckEq{"Đích == Base?"}
    CheckEq -- Đúng --> Adopt["1. Pointer Adoption\nChuyển giao con trỏ (Zero-copy)\nHợp nhất metadata tức thì không tốn I/O"]
    CheckEq -- Sai --> CheckInsert{"Bằng Chứng Ghi Chèn Contiguous\n(omnigraph.insert_absence = v1)?"}
    CheckInsert -- Đúng --> Replay["2. Proven Insertion Replay\nGhép các fragment bất biến đã chứng thực\nBỏ qua phép join & kiểm tra xung đột ID"]
    CheckInsert -- Sai --> CheckLineage{"Ngân Sách Ứng Viên Lineage\n(< 32 MiB)?"}
    CheckLineage -- Đúng --> Lineage["3. Lineage Candidate Scan\nSo khớp bitmask trên metadata đã ghim"]
    CheckLineage -- Sai --> Walk["4. Duyệt Con Trỏ 2 Pha Bounded Memory\nPha 1: Sắp xếp khóa hẹp (id + rowaddr)\nPha 2: Hydrate toàn bộ dòng trong khối 64 MiB"]

Thuật Toán Duyệt Con Trỏ Giới Hạn Bộ Nhớ (Bounded Memory Walk)

Khi cả hai nhánh cùng sửa đổi dữ liệu phức tạp, Omnigraph kích hoạt cơ chế hợp nhất con trỏ 2 pha giúp đảm bảo mức tiêu thụ RAM luôn trong tầm kiểm soát:

• Pha 1 (Key Sorting): Chỉ đọc và sắp xếp các cột khóa hẹp gồm id, _rowid, và _rowaddr. Các cột dữ liệu nặng (payload/embedding) hoàn toàn bị loại khỏi toán tử sắp xếp SortExec, giảm tải bộ nhớ xuống chỉ còn vài chục byte trên mỗi dòng.
• Pha 2 (Chunked Hydration): Sau khi đã xác định thứ tự và loại bỏ xung đột, engine mới tải đầy đủ dữ liệu theo từng khối nhỏ với giới hạn ngặt nghèo 64 MiB. Nếu dữ liệu thực tế vượt ngưỡng 64 MiB, khối đó sẽ bị hủy và chia đôi kích thước để thử lại, ngăn chặn tuyệt đối lỗi tràn bộ nhớ (OOM).

5. 🔍 Truy Vấn Đa Phương Thức: Đồ Thị + Vector + BM25

Các hệ thống RAG hiện nay thường gặp lỗi nghiêm trọng: tìm kiếm vector thuần túy thường sinh ảo giác vì thiếu ràng buộc logic, trong khi tìm kiếm quan hệ đồ thị thuần túy lại không thể khai thác ngữ nghĩa phi cấu trúc. Omnigraph giải quyết triệt để thông qua ngôn ngữ truy vấn GQ (Graph Query), cho phép kết hợp duyệt đồ thị, tìm kiếm vector HNSW và từ khóa BM25 thông qua thuật toán Reciprocal Rank Fusion (RRF):

// Ví dụ: Truy vấn lắp ráp ngữ cảnh chuyên gia cho Agent
query find_expert_context($query_vec: Vector(1536), $keyword: String) {
    match {
        $author: Person
        $doc: Document
        $author -[:AUTHORED]-> $doc
        search($doc.title, $keyword)
    }
    return {
        $author.name,
        $doc.title,
        $doc.summary
    }
    order {
        // Hợp nhất điểm xếp hạng Vector KNN và điểm tần suất BM25
        rrf(
            nearest($doc.embedding, $query_vec),
            bm25($doc.body, $keyword)
        )
    }
    limit 10
}

Bộ Tối Ưu Chi Phí Duyệt Đồ Thị: BTREE Index vs. In-Memory CSR

Khi thực thi bước mở rộng quan hệ (Expand), bộ lập kế hoạch của Omnigraph đưa ra quyết định thông minh:

• Chế độ Indexed BTREE: Áp dụng khi tập biên đầu vào nhỏ (ví dụ < 1.024 thực thể). Engine thực hiện tra cứu trực tiếp trên chỉ mục BTREE của Lance mà không cần tải toàn bộ đồ thị vào RAM.
• Chế độ CSR (Compressed Sparse Row): Khi truy vấn qua nhiều bước nhảy (multi-hop) hoặc số lượng thực thể lớn, engine tự động dựng cấu trúc mảng nén CSR/CSC trong bộ nhớ để duyệt cực nhanh, loại bỏ hàng ngàn request I/O dư thừa tới object storage.

6. ⚔️ Bảng So Sánh Kỹ Thuật: Omnigraph vs. Các Giải Pháp Truyền Thống

7. 🛠️ Bài Học Kỹ Thuật Đáng Giá

Từ thiết kế kiến trúc của Omnigraph, các kỹ sư phần mềm và kiến trúc sư hệ thống AI có thể rút ra 4 kinh nghiệm quý báu:

1. Khai thác định dạng cột trên Object Storage cho dữ liệu tác vụ (Operational Data): Thay vì chỉ dùng S3 cho Data Lake lưu trữ thụ động, việc kết hợp định dạng cột tối ưu như Lance cho phép thực hiện cả truy vấn vector tốc độ cao lẫn tra cứu điểm dữ liệu với chi phí hạ tầng giảm tới 80%.
2. Đảm bảo tính nguyên tử ở tầng Manifest thay vì khóa file vật lý: Thiết kế các thay đổi dữ liệu dưới dạng phiên bản độc lập (detached commits) và chỉ công bố quyền sở hữu thông qua một lệnh CAS duy nhất trên manifest giúp loại bỏ nhu cầu về cụm lock phân tán phức tạp và loại trừ nguy cơ hỏng dữ liệu khi sập nguồn.
3. Tách biệt khóa định danh khỏi dữ liệu payload khi sắp xếp/hợp nhất: Trong các giải thuật xử lý diff hay merge dữ liệu lớn, việc chỉ sắp xếp các tuple khóa hẹp (id, _rowaddr) rồi mới nạp dữ liệu nặng theo từng khối có chặn ngưỡng trần (bounded memory) là bí quyết cốt lõi để ngăn chặn lỗi Out-Of-Memory (OOM).
4. Chuẩn hóa mô hình phân nhánh cho các hệ thống Multi-Agent: Trong kỷ nguyên các tác tử AI tự chủ, đừng ép các agent phải tranh chấp ghi trên một luồng dữ liệu đơn lẻ. Hãy cung cấp cho chúng các nhánh rẽ dữ liệu cô lập và tự động giải quyết xung đột bằng thuật toán hợp nhất 3 chiều.