1억 벡터 메모리 95.4%·지연 80% 감소, 진창 AI 네이티브 DB

안녕하세요, 저는 샤오예입니다. 이 글은 제가 밟았던 지뢰를 여러분은 밟지 않으시라고 쓰는 것입니다!

RAG(검색 증강 생성)를 하는 개발자라면 대부분 이런 고통을 겪어봤을 겁니다:

기업의 사설 구조화 데이터(예: 주문, 사용자 프로필)와 반구조화 데이터(예: 문서)를 대형 모델에 먹이기 위해, 우리는 비즈니스 DB(MySQL/PG) 외부에 벡터 데이터베이스(Milvus/Faiss)를 억지로 하나 더 조립해야 합니다.

이 "외장형" 아키텍처의 대가는 무엇일까요?

링크가 지나치게 김: 비즈니스 DB에 변경 발생 -> 애플리케이션 계층에서 수집 -> Embedding 모델 호출해 벡터화 -> 벡터 DB에 기록. 지연이 밀리초 수준에서 초 수준으로 치솟습니다.

일관성 재앙: 관계형 DB의 데이터는 업데이트됐는데 벡터 DB는 아직 동기화되지 않아, 대형 모델이 오래된 데이터를 들고 "헛소리"를 늘어놓습니다.

메모리 블랙홀: 벡터 인덱스(예: HNSW)는 악명 높은 메모리 킬러입니다.

바로 며칠 전, 전커진창(电科金仓)이 베이징에서 "Hello, AI 데이터베이스" 제품 발표회를 열었습니다. 일선 개발자로서 저는 그들의 거대한 서사에는 별로 관심을 두지 않고, 그들이 공개한 실측 데이터를 집요하게 파고들었습니다: 1억 건의 768차원 벡터, 98% 재현율 조건에서 피크 메모리 오버헤드가 업계 대비 95.4% 낮고, 쿼리 지연이 80% 낮습니다.

이 데이터에 물이 없다면 상당히 놀라운 수준입니다. 오늘은 그들이 내세운 "데이터가 DB를 떠나지 않아도 AI를 쓸 수 있다"는 것이 밑바탕에서 대체 어떻게 재구성된 것인지 파헤쳐 보겠습니다.

1. 왜 "외장형" 벡터 DB가 메모리 킬러가 되는가?

먼저 계산을 해봅시다. 1억 건의 데이터, 각각은 768차원 벡터입니다.

Float32로 저장한다면(숫자당 4바이트), 순수 벡터 데이터만 해도: 1억 × 768 × 4바이트 ≈ 307GB 입니다.

밀리초 수준의 유사도 검색을 하려면, 전통적인 벡터 데이터베이스는 보통 전체 HNSW 그래프 인덱스 구조를 메모리에 로드해야 합니다. 여기에 그래프 구조의 포인터 오버헤드는 아직 계산하지도 않았습니다. 수백 GB, 심지어 수 TB의 물리 메모리가 없다면 시스템은 곧바로 OOM이 납니다.

진창은 어떻게 메모리를 95.4%나 낮췄을까요? 단순한 알고리즘 최적화일 리가 없고, 그 이면에는 반드시 아키텍처 차원의 유전자 재조합이 있을 것입니다.

2. 심층 분석: 네이티브 AI 데이터베이스의 밑단 재조합 논리

발표회 정보와 데이터베이스 커널 원리를 종합해 보면, 저는 그들이 밑단에서 다음과 같은 일들을 했다고 추측합니다. 이것이 바로 "네이티브 융합"과 "외장형拼接(짜깁기)"의 본질적 차이입니다:

1. 독립 프로세스의 메모리 전량 로딩을 버림(아키텍처 차원의 비용 절감)

외장형 벡터 DB는 독립 프로세스이며, 모든 인덱스를 자신의 메모리 풀로 끌어와야 합니다. 반면 진창의 AI 데이터베이스는 벡터 검색을 커널의 일부로 만들었습니다. 관계형 데이터베이스의 강력한 Buffer Pool(버퍼 풀) 메커니즘을 그대로 재사용합니다.

이는 벡터 인덱스가 일반 데이터 페이지처럼 필요에 따라 로드되고, 콜드/핫 데이터가 분리될 수 있음을 의미합니다. 더 이상 1억 건의 벡터를 전부 메모리에 억지로 붙잡아 둘 필요 없이, 메모리 교체 알고리즘(LRU 변형)을 통해 동적으로 스케줄링합니다. 이것이 그 95.4%의 메모리 감소를 바로 설명해 줍니다.

2. 관계형 쿼리와 벡터 연산의 오퍼레이터 융합(지연 감소)

예전에 데이터를 조회할 때는 애플리케이션 계층이 먼저 SELECT로 관계형 테이블을 조회해 사용자의 컨텍스트를 얻고, 그 컨텍스트를 가지고 벡터 DB에서 유사 문서를 조회한 다음, 마지막으로 애플리케이션 계층에서 조립해야 했습니다.

진창의 커널에서는 이것이 하나의 SQL이 됩니다: 관계형 테이블의 조건 필터링과 벡터 인덱스의 유사도 계산이 실행 계획(Execution Plan)에서 협력 하향 전달(co-pushdown)되어, 하나의 엔진 안에서 동시에 완료됩니다. 프로세스 간 네트워크 전송이 줄고, 애플리케이션 계층의 직렬화와 역직렬화가 줄어드니 지연이 자연히 크게 떨어집니다.

3. DB 내부 시맨틱 구축과 보안 폐쇄 루프

외장형 아키텍처의 가장 큰 컴플라이언스 위험은 "데이터가 DB를 나가는 것"입니다. 데이터가 API를 통해 외부로 전달되면 가로채이거나 권한을 초과한 접근이 발생하기 쉽습니다.

네이티브 방식은 이렇습니다: 대형 모델이 표준 인터페이스를 통해 데이터베이스를 호출하고, AI의 추론 능력은 "DB 내부"에서 완료됩니다. 데이터는 데이터베이스의 보안 방어선을 떠날 필요가 없어, 데이터 유출에 따른 권한 무력화 문제를 근원에서 해결합니다.

3. 개발자에게 주는 시사점

업계에서 AI를 하는 사람들은 지난 2년 동안 줄곧 "애플리케이션 계층"에만 몰두해 왔는데, 이제 드디어 밑단 기반 소프트웨어가 힘을 내기 시작했습니다.

이번에 진창이 AI 데이터베이스를 발표하고, 동시에 풀스택 지능형 데이터 개발 도구까지 내놓은 것은 명확한 트렌드를 보여줍니다: RAG 애플리케이션 개발의 진입 장벽이 크게 허물질 것입니다. 개발자는 더 이상 복잡한 시스템 간 동기화 링크를 유지하는 데 많은 정력을 쏟지 않고, "비즈니스 시맨틱을 어떻게 정의할 것인가"와 "AI 애플리케이션 시나리오를 어떻게 설계할 것인가"에 정력을 쏟으면 됩니다.

물론 네이티브 융합도 만능 해결책은 아닙니다. 데이터베이스가 트랜잭션을 이해하는 것을 넘어 벡터 인덱스와 멀티모달까지 이해해야 하기 때문입니다. 이는 데이터베이스 벤더의 밑단 커널 연구 개발 역량을 시험하는 문제입니다.

다음에 다시 아키텍처를 선정할 때, 여러분의 비즈니스 데이터가 이미 1억 건을 넘고 RAG에 heavily 의존한다면, 어쩌면 정말로 그 복잡한 벡터 DB 클러스터를 힘들여 구축할 필요가 없을지도 모릅니다. 밑단의 DB가 스스로 어떻게 진화했는지 한번 보러 가세요.

샤오예가 있으면 SQL 걱정 없다

더 알고 싶은 것이 있으면 언제든 댓글 남겨 주세요! 샤오예는 아는 대로 다 말씀드리고, 남김없이 알려드리겠습니다…… 다음에 만나요~

이 DBA는 좀 예(耶)스럽네

241

글

33k

조회

26

팬