▲

jq보다 빠른 jsongrep

 (micahkepe.com)
6P by GN⁺ 20시간전 | ★ favorite | 댓글 2개
  • JSON 문서를 경로 기반으로 탐색하는 Rust CLI 도구로, 기존 jq, jmespath, jsonpath-rust, jql보다 검색 속도가 빠름
  • 쿼리를 정규 언어로 표현해 DFA로 컴파일하고, JSON 트리를 단일 패스로 탐색하는 구조로 O(n) 시간에 처리
  • zero-copy 파싱을 지원하는 serde_json_borrow를 사용해 메모리 할당을 최소화하고, ripgrep의 성능 철학을 참고해 설계됨
  • 벤치마크 결과, 대용량 JSON에서도 엔드투엔드 성능이 가장 우수하며, 검색 중심의 단순 쿼리 언어를 제공
  • MIT 라이선스로 공개되어 있으며, DFA 기반 쿼리 엔진을 Rust 라이브러리로 재사용 가능함

jsongrep 개요

  • jsongrep은 JSON 문서에서 경로 기반으로 값을 검색하는 Rust 기반 CLI 도구로, jq, jmespath, jsonpath-rust, jql보다 빠른 성능을 목표로 함
  • JSON 문서를 트리로 보고, 경로(path) 를 정규 언어(regular language) 로 표현해 DFA(Deterministic Finite Automaton) 로 컴파일 후 단일 패스로 탐색 수행
  • 쿼리 언어는 단순하며, 검색 중심으로 설계되어 변환이나 계산 기능은 없음
  • serde_json_borrow를 이용한 zero-copy 파싱으로 메모리 할당을 최소화
  • ripgrep의 설계 철학과 성능 접근 방식을 참고해 개발됨

jsongrep 사용 예시

  • 명령어 jg는 쿼리와 JSON 입력을 받아, 경로가 쿼리와 일치하는 모든 값을 출력
  • 점 표기(dot path) 로 중첩 필드 접근
    • jg 'roommates[0].name' → "Alice"
  • 와일드카드(*, [*])로 모든 키나 인덱스 매칭
  • Alternation(|)으로 여러 경로 중 하나 선택
  • 재귀 탐색((* | [*])*)으로 임의 깊이의 필드 검색
  • Optional(?)로 0회 또는 1회 매칭 지원
  • -F 옵션으로 특정 필드명을 빠르게 검색 가능
  • 파이프(| less, | sort) 사용 시 자동으로 경로 출력 생략, --with-path로 강제 표시 가능

jsongrep의 핵심 개념

  • JSON은 트리 구조이며, 객체 키와 배열 인덱스가 엣지(edge) 역할을 함
  • 쿼리는 루트에서 특정 노드까지의 경로 집합을 정의
  • 쿼리 언어는 정규 언어로 설계되어 DFA로 변환 가능
  • DFA는 입력을 한 번만 읽으며, 백트래킹 없이 O(n) 시간에 탐색 수행
  • 기존 도구(jq, jmespath 등)는 쿼리를 인터프리트하며 재귀적으로 탐색하지만, jsongrep은 사전 컴파일된 DFA로 단일 패스 탐색 수행

DFA 기반 쿼리 엔진 구조

  • 파이프라인은 5단계로 구성
    1. serde_json_borrow로 JSON을 트리로 파싱
    2. 쿼리를 AST로 파싱
    3. Glushkov 알고리듬으로 NFA 생성
    4. Subset Construction으로 DFA로 변환
    5. DFA 전이를 따라 JSON 트리를 단일 DFS로 탐색

  • 쿼리 파싱

    • PEG 문법(pest 라이브러리 사용)으로 쿼리를 Query AST로 변환
    • 주요 구문 요소: Field, Index, Range, FieldWildcard, ArrayWildcard, Optional, KleeneStar, Disjunction, Sequence
    • 예: roommates[*].name → Sequence(Field("roommates"), ArrayWildcard, Field("name"))

  • JSON 트리 모델

    • 객체 키와 배열 인덱스는 엣지, 값은 노드
    • 예: roommates[*].name은 roommates → [0] → name 경로를 탐색

  • NFA 구성 (Glushkov 알고리듬)

    • ε-전이 없는 NFA 생성
    • 단계
      1. 쿼리 심볼에 위치 번호 부여
      2. First/Last/Follows 집합 계산
      3. 각 위치 간 전이 구성
    • 예시 쿼리 roommates[*].name의 NFA는 4개 상태로 구성된 단순 선형 구조

  • DFA 변환 (Subset Construction)

    • NFA의 상태 집합을 기반으로 결정적 DFA 생성
    • 각 상태는 하나의 NFA 상태 집합에 대응
    • Other 심볼을 추가해 불필요한 키를 효율적으로 건너뜀
    • 단순 쿼리는 NFA와 동일한 구조의 DFA로 변환됨

  • DFS 기반 탐색

    • 루트에서 시작해 각 엣지를 따라 DFA 전이 수행
    • 전이가 없으면 해당 서브트리 가지치기(prune)
    • DFA 상태가 accepting이면 경로와 값을 기록
    • 각 노드는 최대 한 번 방문하며, 전체 탐색은 O(n)
    • serde_json_borrow로 문자열 복사 없이 원본 버퍼 참조

벤치마크 방법론

  • Criterion.rs로 통계 기반 벤치마크 수행

  • 데이터셋

    • simple.json (106B), kubernetes-definitions.json (~992KB), kestra-0.19.0.json (~7.6MB), citylots.json (~190MB)

  • 비교 도구

    • jsongrep, jsonpath-rust, jmespath, jaq, jql

  • 벤치마크 그룹

    1. document_parse: JSON 파싱 속도
    2. query_compile: 쿼리 컴파일 시간
    3. query_search: 탐색만 수행
    4. end_to_end: 전체 파이프라인

  • 공정성 고려

    • zero-copy 파싱 이점은 별도 측정
    • DFA 컴파일 비용은 분리 측정
    • 기능이 없는 도구는 해당 테스트 제외
    • 데이터 복제 비용은 분리 처리

벤치마크 결과

  • 문서 파싱 시간: serde_json_borrow가 가장 빠름
  • 쿼리 컴파일 시간: jsongrep은 DFA 생성으로 가장 큰 비용 발생, jmespath는 훨씬 빠름
  • 검색 시간: jsongrep이 모든 도구 중 가장 빠름
  • 엔드투엔드 성능: 190MB 데이터셋 기준으로도 jq, jmespath, jsonpath-rust, jql보다 압도적으로 빠름
  • 전체 결과는 라이브 벤치마크 사이트에서 확인 가능

라이선스 및 활용

  • MIT 라이선스의 오픈소스 소프트웨어
  • GitHub, Crates.io, Docs.rs에서 이용 가능
  • DFA 기반 쿼리 엔진을 라이브러리 형태로 재사용 가능, Rust 프로젝트에 직접 통합 가능

참고 문헌

  • Glushkov, V. M. (1961), The Abstract Theory of Automata
  • Rabin, M. O., & Scott, D. (1959), Finite Automata and Their Decision Problems
▲
lamanus 17시간전  [-]

| 파이프 표시가 왜 본문에서는 다르게 보일까요? 신기하네요..

답변달기
▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • jq의 문법이 너무 난해해서 매번 단순한 JSON 값 하나를 가져오려 해도 검색해봐야 함

    • 흥미로움. 나는 jq의 문법이 직관적이라 느끼며, 쉘 파이프라인처럼 점, 파이프, 대괄호만 쓰는 게 익숙함
      주로 일회성 필터를 작성하기 때문에 읽는 시간보다 쓰는 시간이 많음
      아마 내 사용 사례가 단순하거나 jq가 내 사고방식에 잘 맞는 듯함
      모든 CLI 도구가 JSON을 입출력하고 jq로 연결되는 세상을 꿈꾸지만, 그건 당신에게는 악몽일 듯함
    • jq는 자주 쓰지 않아서 ‘배움의 골짜기’ 에 머무는 도구임
      쓸 때마다 새로 배워야 해서 직관적이지 않음
      sed도 Turing 완전함에도 불구하고 대부분은 정규식 치환 정도만 씀
    • 내가 만든 celq를 추천함
      jq를 좋아하지만, 예전에 내가 쓴 쿼리를 이해 못할 때가 있었음
      celq는 더 익숙한 CEL 언어를 사용함
    • 나도 비슷한 이유로 dq라는 도구를 직접 만듦
      단순히 JavaScript로 JSON을 다루는 방식인데, 놀랍게도 jq보다 빠름
      $ cat package.json | dq 'Object.keys(data).slice(0, 5)' 같은 식으로 사용함
    • JSON 자체가 불필요한 구문적 잡음이 많아서 귀찮음
      나는 Clojure를 배운 덕분에 이제는 JSON 대신 EDN을 씀
      더 간결하고 읽기 쉬우며 구조적으로 다루기 쉬움
      요즘은 borkdude/jet이나 babashka로 데이터를 다루고, djblue/portal로 시각화함
      jq의 복잡한 연산자를 고집하는 이유를 이해 못하겠음

  • 성능을 중요하게 생각하지만, 나노초 단위의 비교는 과시적 퍼포먼스처럼 느껴짐
    대부분의 경우 지금 쓰는 도구로 충분함
    예를 들어, 나는 큰 파일에서만 grep 대신 rg를 씀

    • 이런 생각이 들면 “나는 타깃 사용자가 아니다”라고 생각하면 됨
      2ms와 0.2ms의 차이는 사소해 보여도, TB 단위의 스트림을 처리하는 사람에게는 중요함
    • 하지만 모두가 그렇게 생각하면 결국 작은 비효율이 누적되어 전체가 느려짐
      하드웨어는 빨라졌는데 소프트웨어는 오히려 느려지는 현실임
    • jq가 차별화되려면 직관적인 문법과 실전 예시가 더 많아야 함
    • “충분히 빠르다”는 말이 늘 마음에 걸림
      최적화를 거부하는 건 게으름과 상상력 부족처럼 느껴짐
      네트워크 지연보다 빠르다는 이유로 안심하는 건 변명처럼 들림
    • 나도 속도보다 사용성과 기능을 더 중요하게 생각함
      만약 JSON이 너무 크다면, JSON 대신 이진 포맷을 써야 함
      CLI에서 복잡한 파이프라인을 짜야 한다면, 차라리 프로그램을 작성하는 게 낫다고 봄

  • 많은 새로운 CLI 도구들이 “더 빠르다”를 내세우지만, 실제로 jq가 느리다고 느낀 적은 거의 없음

    • 나는 TB 단위의 ndjson 파일을 다룸
      jq로 필드 이름만 바꾸는 단순 작업도 너무 느려서 Node나 Rust 스크립트로 직접 처리함
    • 초대형 로그 파일을 다루는 경우 jq가 느리게 느껴질 수 있음
      하이퍼스케일러 환경에서는 수 TB의 로그를 직접 내려받아 분석함
    • 우리는 수천 개의 노드에서 JSON 응답을 파싱함
      모니터링 해상도에 따라 성능 차이가 체감될 수 있음
    • 새로운 도구가 나올 때마다 “Rust로 다시 만든 더 빠른 버전” 패턴이 반복됨
      기능 일부만 구현하고 벤치마크로 승리를 주장하는 식임
      이번 프로젝트도 그런 ‘부분집합이 더 빠르다’ 트렌드의 일환으로 보임
    • 어떤 도구가 느리다는 건 실제로 느려지는 순간에만 깨닫게 됨
      그때부터는 모든 게 느리게 느껴짐
      ripgrep처럼 한 번 빠른 도구를 쓰면 다시 돌아가기 어려움

  • jq와 yq를 모두 써봤지만, yq는 훨씬 느림에도 불만이 없었음
    jq보다 빠른 도구가 있다면 멋지지만, 그건 특정 사용자층에게만 필요함
    그래도 최적화를 사랑하는 사람으로서 존경을 표함

    • 어떤 yq를 말하는지 궁금함 — Go 버전인지 Python 버전인지?
    • 서버 통합 환경에서는 성능이 중요하지만, CLI에서는 대부분 충분히 빠름
    • 나는 ArcGIS에서 내보낸 GeoJSON 수 GB를 jq로 처리함
      ETL 단계에서 시간이 꽤 걸림
    • 모든 사람이 같은 방식으로 도구를 쓰는 건 아님

  • 페이지를 처음 열었을 때 라이트 모드 색상 깨짐이 있었음
    다크 모드로 전환했다가 돌아오면 해결됨

    • 사이트도 도구처럼 ‘vibe-coded’ 된 느낌임
    • 작성자인 내가 라이트 모드를 안 써서 테스트를 깜빡했음, 바로 수정 예정임
    • CSS에서 다크 모드 스타일이 일부 새어 나왔던 문제였음
    • Android Firefox에서는 괜찮았지만, 차트 스케일이 제각각이라 비교가 어려움
    • 이제 수정 완료됨

  • 나는 정확성 때문에 Jaq으로 갈아탐
    성능도 jq보다 낫다고 함

    • 추천 고마움. jaq는 jsongrep보다 올바른 방향으로 더 발전한 듯함
    • 다만 jaq 3.0이 배포판 jq보다 빠르지만, 직접 빌드한 jq가 더 빠름
      jq의 느리다는 평판은 배포 패키징 문제 때문으로 보임

  • 나는 업무상 newline-delimited JSON(jsonl) 을 자주 다룸
    각 줄이 완전한 JSON 객체인데, 주요 CLI 도구들이 이 포맷을 지원하는지 궁금함

  • jq, mlr, htmlq, xsv, yq 등 여러 데이터 처리 CLI 도구를 써봤지만,
    Nushell을 발견한 뒤로는 전부 대체됨
    하나의 문법으로 모든 포맷을 다룰 수 있어 신선한 경험이었음

    • 나도 2023년 중반부터 Nushell을 주력 쉘로 사용 중임
      동료들과 협업할 때만 jq, yq, mlr을 병행함
    • 나도 Nushell로 대부분 대체함
      자동완성 설정과 명령어 검색성에 약간의 불편이 있지만, oh-my-zsh보다 훨씬 낫음
      타입 주석 강제, 정적 바이너리 컴파일, TUI 라이브러리까지 생기면 소규모 앱 작성에도 쓸 듯함
    • 나도 동의함. Nushell은 직관적이고 일관된 문법 덕분에 자동화가 훨씬 쉬워짐

  • 멋진 도구임! 다만 벤치마크 시각화가 조금 아쉬움
    모든 도구가 같은 색이라 jsongrep이 어디 있는지 찾기 어려움
    jq 자체도 그래프에 없어서 혼란스러웠음
    xLarge 파일이 190MiB라 작은 편인데, 나는 400MiB~1GiB JSON을 자주 다룸

    • 작성자인 내가 답변함. 현재 벤치마크 범위는 106B~190MB 정도임
      더 큰 공개 JSON 문서가 있다면 알려주면 좋겠음

  • 벤치마크 시각화가 거칠게 느껴짐
    색상이나 형태를 활용해 더 많은 차원을 표현하면 좋겠음
    파일 경로를 직접 읽어야 결과를 이해할 수 있는 건 불편함

답변달기