clickhouse-js-node-rowbinary

작성자: clickhouse

ClickHouse RowBinary 스트림을 읽고/디코딩하며 쓰고/인코딩하는 TypeScript/JavaScript 코드를 생성합니다. ClickHouse HTTP 서버용입니다. 이 스킬은 다음 상황에서 사용하세요…

npx skills add https://github.com/clickhouse/agent-skills --skill clickhouse-js-node-rowbinary

ClickHouse JS RowBinary Codec Generator for Node.js

This skill generates both directions of the wire format: readers (decode bytes → values) and writers (encode values → bytes, the mirror). A given task normally needs only one side. This file is the shared entry point — the format gate plus the principles common to both directions; the per-direction decisions, guidance, and the per-type reference tables live in two sibling files.

Pick your side — read only the one you need:

  • Decoding a RowBinary* response from ClickHouse into JS values → reader.md. Streaming vs whole-buffer, row-objects vs columnar, fixed vs runtime schema, and the per-type reader reference.
  • Encoding JS values into a RowBinary payload to send to ClickHouse → writer.md. The Sink/writeX building blocks, writeRows streaming, and the per-type writer reference.

The per-type code is real, split by direction under src/readers/ and src/writers/.

First: is RowBinary even the right format?

RowBinary exists for throughput, but it is not automatically the fastest path — match the format to the shape of the data before committing to a bespoke parser.

Prefer a JSON* format (e.g. JSONEachRow) when the result is mostly strings / JSON-like values that you consume wholesale — randomly accessing essentially every field, running string/regexp methods on them, treating values as text. V8's native JSON.parse is heavily optimized C++ and builds JS strings and objects faster than a JS-level RowBinary decoder can; pair it with HTTP response compression (gzip / zstd, which crushes JSON's repetitive keys) and the wire cost shrinks too.

RowBinary clearly wins when the result is dominated by:

  • Wide numericsInt128/Int256/UInt128/UInt256, Decimal128/Decimal256.
  • Binary / fixed-width blobsIPv4, IPv6, UUID, FixedString.
  • High-volume fixed-width numeric columns generally, where each value is a single DataView read.

Prefer the Native format when columnar load and client-side analytics are the main goal (fold/scan/filter columns, feed typed arrays to a Worker or WASM). Native is column-major, so it loads straight into one typed array per column with no transpose.

For help choosing and consuming a JSON* format (or CSV / TSV) instead, use the clickhouse-js-node-coding skill.

Core guidance (both directions)

These principles apply whether you are generating a reader or a writer; the side-specific operational guidance is in reader.md / writer.md.

  • Little-endian only. RowBinary is little-endian; target x86/ARM. Read and write every multi-byte number with DataView accessors passing a literal true for the littleEndian flag.

  • Correct first, then optimize. First emit a correct codec built from the plain per-type API. Only after it's correct (and tested) specialize it. Don't bake performance assumptions in before correctness.

  • Monomorphize generic/composite types. Emit specialized, inlined code per type combination instead of passing functions as arguments where the type is known ahead of time.

  • Inline the leaf ops. The per-type readX/writeX functions are the correct, composable reference; the generated codec should INLINE their bodies, not call them, so the row loop is straight-line with no per-field indirection (and so the fixed-width coalescing can fold the offset arithmetic together).

  • Annotate the type per column. Inlining erases the type structure, so put a short comment above each column's encode/decode block naming the ClickHouse type it handles.

  • Shared scratch is not reentrant. Some hot methods reuse a module-level scratch buffer as a write-then-read pair — correct only because the access is fully synchronous. An async/yield boundary between populating and reading it corrupts the value.

  • TypeScript by default. Generate TypeScript code and helpers unless the user explicitly asks for plain JavaScript.

Worked examples

Six end-to-end examples with real speedup are catalogued in EXAMPLES.md.

Out of scope

  • JSON / CSV / TSV / Parquet parsing → use clickhouse-js-node-coding.
  • Connection errors, hangs, type mismatches → use clickhouse-js-node-troubleshooting.
  • Browser / Web Worker / Edge@clickhouse/client-web.

Still Stuck?

clickhouse의 다른 스킬

clickhouse-best-practices
clickhouse
28개의 ClickHouse 모범 사례 규칙으로, 스키마 설계, 쿼리 최적화, 데이터 수집 전략별로 구성되어 있습니다. 기본 키 및 데이터 유형 선택(변경 불가능한 설계 결정), JOIN 및 쿼리 최적화, 삽입 배치 및 변형 회피 등 세 가지 핵심 영역을 다룹니다. 영향도에 따라 우선순위가 매겨진 28개의 규칙을 포함하며, ClickHouse의 컬럼 기반 스토리지 및 희소 인덱스 메커니즘으로 인해 스키마 설계 및 쿼리 최적화 규칙은 CRITICAL로 표시됩니다. 구조화된 검토 절차를 제공합니다...
official
clickhouse-js-node-coding
clickhouse
Write idiomatic application code with the ClickHouse Node.js client (`@clickhouse/client`). Use this skill whenever a user is *building* against the Node.js…
official
clickhousectl-cloud-deploy
clickhouse
사용자가 ClickHouse를 클라우드에 배포하거나, 프로덕션 환경으로 전환하거나, ClickHouse Cloud를 사용하거나, 관리형 ClickHouse 서비스를 호스팅하거나, 로컬에서 마이그레이션하려는 경우 사용합니다.
official
clickstack-otel-collector
clickhouse
Use when a user wants to wire an OpenTelemetry collector into a Managed ClickStack service on ClickHouse Cloud, either by deploying a new local collector…
official
infra-clickhouse
clickhouse
Sets up and manages ClickHouse using the clickhousectl CLI — installs and runs a local ClickHouse server for development, and creates managed ClickHouse Cloud…
official
infra-postgres
clickhouse
Sets up and manages Postgres using the clickhousectl CLI — runs a local Docker-backed Postgres for development, and creates and operates managed ClickHouse…
official
clickhouse-best-practices
clickhouse
ClickHouse 스키마, 쿼리 또는 구성을 검토할 때 반드시 사용해야 합니다. 권장 사항을 제공하기 전에 반드시 확인해야 하는 31개의 규칙이 포함되어 있습니다. 항상 읽어보세요…
official
setup
clickhouse
이 플러그인에 포함된 ClickHouse MCP 서버 연결 설정을 사용자에게 안내합니다. 사용자가 플러그인을 처음 설치하거나 문제가 있을 때 사용합니다.
official