|
| Time/Time64 | ✔️ | string |
サポートされている ClickHouse フォーマットの完全な一覧は
[こちら](/ja/reference/data-types)で確認できます。
関連項目:
* [Dynamic/Variant/JSON の使用例](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/coding/dynamic_variant_json.ts)
* [Time/Time64 の使用例](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/coding/time_time64.ts)
### Date/Date32 型の注意点
クライアントは追加の型変換を行わずに値を挿入するため、`Date`/`Date32` 型のカラムに挿入できるのは文字列のみです。
**例:** `Date` 型の値を挿入します。
[ソースコード](https://github.com/ClickHouse/clickhouse-js/blob/ba387d7f4ce375a60982ac2d99cb47391cf76cec/__tests__/integration/date_time.test.ts)
```ts theme={null}
await client.insert({
table: 'my_table',
values: [ { date: '2022-09-05' } ],
format: 'JSONEachRow',
})
```
ただし、`DateTime` または `DateTime64` のカラムを使用している場合は、文字列と JS の Date オブジェクトの両方を使用できます。`date_time_input_format` を `best_effort` に設定すると、JS の Date オブジェクトをそのまま `insert` に渡せます。詳細については、こちらの[例](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/coding/insert_js_dates.ts)を参照してください。
### Decimal\* 型の注意事項
`JSON*` 系のフォーマットを使って Decimal を挿入できます。たとえば、次のように定義されたテーブルがあるとします。
```sql theme={null}
CREATE TABLE my_table
(
id UInt32,
dec32 Decimal(9, 2),
dec64 Decimal(18, 3),
dec128 Decimal(38, 10),
dec256 Decimal(76, 20)
)
ENGINE MergeTree()
ORDER BY (id)
```
文字列として表現すれば、精度を失うことなく値を挿入できます。
```ts theme={null}
await client.insert({
table: 'my_table',
values: [{
id: 1,
dec32: '1234567.89',
dec64: '123456789123456.789',
dec128: '1234567891234567891234567891.1234567891',
dec256: '12345678912345678912345678911234567891234567891234567891.12345678911234567891',
}],
format: 'JSONEachRow',
})
```
ただし、`JSON*` フォーマットでデータをクエリする場合、ClickHouse はデフォルトで Decimal を*数値*として返すため、精度が失われる可能性があります。これを避けるには、クエリ内で Decimal を文字列に CAST できます。
```ts theme={null}
await client.query({
query: `
SELECT toString(dec32) AS decimal32,
toString(dec64) AS decimal64,
toString(dec128) AS decimal128,
toString(dec256) AS decimal256
FROM my_table
`,
format: 'JSONEachRow',
})
```
詳しくは、[この例](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/coding/insert_decimals.ts)を参照してください。
### 整数型: Int64, Int128, Int256, UInt64, UInt128, UInt256
サーバーはこれを数値として受け取れますが、これらの型の最大値は `Number.MAX_SAFE_INTEGER` より大きいため、
整数のオーバーフローを避けるため、`JSON*` 系の出力フォーマットでは文字列として返されます。
ただし、この動作は
[`output_format_json_quote_64bit_integers` 設定](/ja/reference/settings/formats#output_format_json_quote_64bit_integers)
で変更できます。
**例:** 64 ビット整数の JSON 出力フォーマットを調整します。
```ts theme={null}
const resultSet = await client.query({
query: 'SELECT * from system.numbers LIMIT 1',
format: 'JSONEachRow',
})
expect(await resultSet.json()).toEqual([ { number: '0' } ])
```
```ts theme={null}
const resultSet = await client.query({
query: 'SELECT * from system.numbers LIMIT 1',
format: 'JSONEachRow',
clickhouse_settings: { output_format_json_quote_64bit_integers: 0 },
})
expect(await resultSet.json()).toEqual([ { number: 0 } ])
```
## ClickHouse settings
クライアントは、[settings](/ja/reference/settings/session-settings)
の仕組みを通じて ClickHouse の動作を調整できます。
これらの settings はクライアントのインスタンスレベルで設定でき、ClickHouse に送信される
すべてのリクエストに適用されます。
```ts theme={null}
const client = createClient({
clickhouse_settings: {}
})
```
また、設定はリクエストレベルで指定することもできます。
```ts theme={null}
client.query({
clickhouse_settings: {}
})
```
サポートされているすべての ClickHouse 設定を含む型宣言ファイルは、
[こちら](https://github.com/ClickHouse/clickhouse-js/blob/main/packages/client-common/src/settings.ts)で確認できます。
クエリを実行するユーザーに、設定を変更するための十分な権限があることを確認してください。
## 応用トピック
### パラメータ付きクエリ
パラメータ付きのクエリを作成し、クライアントアプリケーションからその値を渡すことができます。これにより、クライアント側で
特定の動的な値を使ってクエリをフォーマットする必要がなくなります。
通常どおりにクエリを記述し、次に、アプリのパラメータからクエリに渡したい値を、以下の
形式で波かっこ内に配置します。
```text theme={null}
{: }
```
以下:
* `name` — プレースホルダーの識別子。
* `data_type` - アプリパラメータの値の[データ型](/ja/reference/data-types)。
**例:** パラメータを指定したクエリ。
[ソースコード](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/coding/query_with_parameter_binding.ts)
.
```ts theme={null}
await client.query({
query: 'SELECT plus({val1: Int32}, {val2: Int32})',
format: 'CSV',
query_params: {
val1: 10,
val2: 20,
},
})
```
詳しくは、[https://clickhouse.com/docs/interfaces/cli#cli-queries-with-parameters-syntax](https://clickhouse.com/docs/interfaces/cli#cli-queries-with-parameters-syntax) を参照してください。
### 圧縮
注: 現時点では、リクエストの圧縮は Web 版では利用できません。レスポンスの圧縮は通常どおり機能します。Node.js 版では両方がサポートされています。
ネットワーク経由で大規模なデータを扱うデータアプリケーションでは、圧縮を有効にすることでメリットが得られます。現在サポートされているのは、[zlib](https://nodejs.org/docs/latest-v14.x/api/zlib.html) を使用する `GZIP` のみです。
```typescript theme={null}
createClient({
compression: {
response: true,
request: true
}
})
```
設定パラメータは次のとおりです:
* `response: true` は、ClickHouseサーバーが圧縮されたレスポンスボディを返すよう指定します。デフォルト値: `response: false`
* `request: true` は、クライアントのリクエストボディの圧縮を有効にします。デフォルト値: `request: false`
### ログ (Node.js のみ)
ログは実験的な機能であり、今後変更される可能性があります。
デフォルトのロガー実装では、`console.debug/info` メソッドを通じてログレコードを `stdout` に、`console.warn/error` メソッドを通じて `stderr` に出力します。
`LoggerClass` を指定することでログ出力のロジックをカスタマイズでき、`level` パラメーターで必要なログレベルを選択できます (デフォルトは `WARN`) :
```typescript theme={null}
import type { Logger } from '@clickhouse/client'
// 3つのLogParamsタイプはすべてクライアントからエクスポートされます
interface LogParams {
module: string
message: string
args?: Record
}
type ErrorLogParams = LogParams & { err: Error }
type WarnLogParams = LogParams & { err?: Error }
class MyLogger implements Logger {
trace({ module, message, args }: LogParams) {
// ...
}
debug({ module, message, args }: LogParams) {
// ...
}
info({ module, message, args }: LogParams) {
// ...
}
warn({ module, message, args }: WarnLogParams) {
// ...
}
error({ module, message, args, err }: ErrorLogParams) {
// ...
}
}
const client = createClient({
log: {
LoggerClass: MyLogger,
level: ClickHouseLogLevel.DEBUG,
}
})
```
現在、クライアントは次のイベントをログに出力します。
* `TRACE` - Keep-Alive ソケットのライフサイクルに関する低レベルの情報
* `DEBUG` - レスポンス情報 (認可ヘッダーとホスト情報を除く)
* `INFO` - ほとんど使われません。クライアントの初期化時に現在のログレベルを出力します
* `WARN` - 致命的ではない error。`ping` リクエストの失敗は警告として記録されます。これは、根本原因の error が返される結果に含まれているためです
* `ERROR` - リクエスト失敗など、`query`/`insert`/`exec`/`command` メソッドで発生した致命的な error
デフォルトのロガー実装は[こちら](https://github.com/ClickHouse/clickhouse-js/blob/main/packages/client-common/src/logger.ts)で確認できます。
### TLS 証明書 (Node.js のみ)
Node.js client は、basic (証明機関のみ) TLS と
mutual (証明機関とクライアント証明書) TLS の両方をオプションでサポートしています。
証明書を `certs` フォルダーに配置し、
CA ファイル名が `CA.pem` である場合の basic TLS 構成例を次に示します：
```ts theme={null}
const client = createClient({
url: 'https://:',
username: '',
password: '', // 必要な場合
tls: {
ca_cert: fs.readFileSync('certs/CA.pem'),
},
})
```
クライアント証明書を使用する相互TLS設定の例:
```ts theme={null}
const client = createClient({
url: 'https://:',
username: '',
tls: {
ca_cert: fs.readFileSync('certs/CA.pem'),
cert: fs.readFileSync(`certs/client.crt`),
key: fs.readFileSync(`certs/client.key`),
},
})
```
リポジトリにある [basic](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/security/basic_tls.ts) および [mutual](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/security/mutual_tls.ts) TLS の完全な実装例を参照してください。
### Keep-Alive の設定 (Node.js のみ)
クライアントでは、基盤となる HTTP agent でデフォルトで Keep-Alive が有効になっています。つまり、確立済みのソケットは後続のリクエストで再利用され、`Connection: keep-alive` ヘッダーが送信されます。アイドル状態のソケットは、デフォルトでは 2500 ミリ秒の間、接続プール内に保持されます ([このオプションの調整に関する注記](/ja/integrations/language-clients/js#adjusting-idle_socket_ttl) を参照してください) 。
`keep_alive.idle_socket_ttl` の値は、サーバー/LB の設定より十分に低くする必要があります。主な理由は、HTTP/1.1 ではサーバーがクライアントに通知せずにソケットを閉じることがあるため、サーバーまたはロードバランサーがクライアント *より先に* 接続を閉じると、クライアントが閉じられたソケットを再利用しようとして、`socket hang up` エラーが発生する可能性があるからです。
`keep_alive.idle_socket_ttl` を変更する場合は、常にサーバー/LB の Keep-Alive 設定と整合している必要があり、かつそれより **必ず小さく** 設定する必要があることに注意してください。これにより、サーバーが開いている接続を先に閉じることがないようにできます。
#### `idle_socket_ttl` の調整
クライアントでは、`keep_alive.idle_socket_ttl` を 2500 ミリ秒に設定しています。これは、最も安全なデフォルト値と考えられるためです。サーバー側では、`config.xml` を変更しなくても、[ClickHouse 23.11 より前のバージョンでは `keep_alive_timeout` が最短 3 秒に設定される場合があります](https://github.com/ClickHouse/ClickHouse/commit/1685cdcb89fe110b45497c7ff27ce73cc03e82d1)。
パフォーマンスに満足しており、問題も発生していない場合は、`keep_alive.idle_socket_ttl` 設定の値を**増やさない**ことを推奨します。値を増やすと、"Socket hang-up" エラーが発生する可能性があるためです。さらに、アプリケーションが大量のクエリを送信し、それらの間の待機時間がそれほど長くない場合は、ソケットが十分長くアイドル状態にならず、クライアントがコネクションプール内に保持し続けるため、デフォルト値で十分です。
適切な Keep-Alive タイムアウト値は、次のコマンドを実行してサーバーのレスポンスヘッダーを確認することで取得できます。
```sh theme={null}
curl -is --data-binary "SELECT 1"
```
レスポンスの`Connection`ヘッダーと`Keep-Alive`ヘッダーの値を確認してください。たとえば、次のようになります。
```text theme={null}
Connection: Keep-Alive
Keep-Alive: timeout=10
```
この場合、`keep_alive_timeout` は 10 秒なので、アイドル状態のソケットを既定より少し長く開いたままにするために、`keep_alive.idle_socket_ttl` を 9000、あるいは 9500 ミリ秒まで増やしてみてください。サーバーがクライアントより先に接続を閉じていることを示す "Socket hang-up" エラーが発生しないか注意して確認し、エラーが出なくなるまで値を下げてください。
#### トラブルシューティング
クライアントの最新バージョンを使用していても `socket hang up` エラーが発生する場合は、この問題を解決するために次の方法を試せます。
* 少なくとも `WARN` のログレベル (デフォルト) でログを有効にしてください。これにより、application code 内に未消費の `stream` やぶら下がったままの `stream` がないか確認できます。これらは server 側でソケットが閉じられる原因になり得るため、transport layer が `WARN` レベルでログに記録します。クライアント設定では、次のようにログを有効にできます。
```ts theme={null}
const client = createClient({
log: { level: ClickHouseLogLevel.WARN },
})
```
* 意図した設定が正しいクライアントのインスタンスに適用されていることを確認してください。アプリケーション内に複数のクライアントのインスタンスがある場合は、queries に使用しているインスタンスに正しい `keep_alive.idle_socket_ttl` 値が設定されていることを再確認してください。
* クライアント設定の `keep_alive.idle_socket_ttl` を 500 ミリ秒短くしてください。状況によっては、たとえばクライアントと server の間の network latency が高い場合に、server が閉じようとしているソケットを送信リクエストが取得してしまう状況を避けられるため、有効なことがあります。
* このエラーが、データの入出力がない長時間実行クエリ (たとえば長時間実行される `INSERT FROM SELECT`) の実行中に発生している場合、load balancer やその他のネットワーク components が長時間維持される connection や長時間実行リクエストを閉じている可能性があります。次の ClickHouse settings を組み合わせて使い、長時間実行クエリの実行中にも何らかのデータが流れるようにしてみてください。
```ts theme={null}
const client = createClient({
// ここでは、実行時間が 5 分を超える queries が存在すると仮定しています
request_timeout: 400_000,
/** これらの settings を組み合わせることで、データの入出力がない長時間実行クエリにおける LB の timeout 問題を回避できます。
* `INSERT FROM SELECT` などでは、connection が LB によって idle と見なされ、突然閉じられる可能性があります。
* この例では、LB の idle connection timeout が 120 秒であると仮定し、安全な値として 110 秒を設定しています。 */
clickhouse_settings: {
send_progress_in_http_headers: 1,
http_headers_progress_interval_ms: '110000', // UInt64。文字列として渡す必要があります
},
})
```
ただし、最近の Node.js バージョンでは、受信した headers の合計サイズに 16KB の上限がある点に注意してください。一定数の progress headers を受信すると (私たちのテストでは約 70～80 個) 、例外が発生します。
また、wire 上での待ち時間を完全になくす、まったく別のアプローチを使うこともできます。これは、connection が失われても mutations はキャンセルされないという HTTP interface の「feature」を活用する方法です。詳しくは [この例 (パート 2) ](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/long_running_queries_timeouts.ts) を参照してください。
* Keep-Alive 機能は完全に無効化することもできます。この場合、クライアントは各リクエストに `Connection: close` header も追加し、基盤となる HTTP agent は connections を再利用しません。idling sockets がなくなるため、`keep_alive.idle_socket_ttl` 設定は無視されます。その結果、リクエストごとに新しい connection が確立されるため、追加のオーバーヘッドが発生します。
```ts theme={null}
const client = createClient({
keep_alive: {
enabled: false,
},
})
```
* `curl` などを使って、同じ ClickHouse インスタンスと同じネットワーク経路 (つまり同じマシンまたはネットワークセグメント、たとえば Kubernetes ポッド) で単純なコマンドラインテストを実行し、Node.js 自体を含むネットワークスタックの残りの部分に潜在的な問題がないか切り分けてください。
```sh theme={null}
curl -is --user ':' --data-binary "SELECT 1"
```
数分間ループで実行してみるとよいでしょう。`curl` でも同様のエラーが見られる場合、問題はクライアント設定ではなく、ネットワークスタックまたは server configuration にある可能性が高いです。
* 素の Node.js 機能で connection をテストするには、組み込みの `fetch` API を使用して ClickHouse server に単純な HTTP request を作成してみてください。
```ts theme={null}
const response = await fetch('?query=SELECT+1', {
method: 'POST',
headers: {
'Authorization': 'Basic ' + Buffer.from(':').toString('base64'),
}
})
```
* 場合によっては、アプリケーションコードやフレームワークのアダプターが、実際のクエリ実行前に先行して `ping()` を追加することがあります。その結果、`ping()` リクエストは成功しても、アイドル接続に関する同じ根本原因により、後続のクエリリクエストが "socket hang up" エラーで失敗することがあります。ログにそのようなパターンが見られる場合は、フレームワークまたはアプリケーションコードで先行 `ping` を無効にするオプションがないか確認してください。これは、途中のネットワークコンポーネントによってレート制限を受ける可能性を下げるのにも役立ちます。
* アプリケーション自体に十分な CPU 時間が割り当てられており、ネットワークがホスティングプロバイダーによってスロットルされていないことを確認してください。GC pause メトリクス、event loop lag メトリクスなど、各種の監視手段も、潜在的なリソース不足の問題を切り分けるうえで役立ちます。
* [no-floating-promises](https://typescript-eslint.io/rules/no-floating-promises/) ESLint rule を有効にして、アプリケーションコードを確認してみてください。これにより、ぶら下がったままのストリームやソケットにつながる可能性がある、未処理の Promise を特定しやすくなります。
### 読み取り専用ユーザー
クライアントを [readonly=1 ユーザー](/ja/concepts/features/configuration/settings/permissions-for-queries#readonly) で使用する場合、`enable_http_compression` 設定が必要になるため、レスポンスの圧縮は有効にできません。次の設定ではエラーが発生します。
```ts theme={null}
const client = createClient({
compression: {
response: true, // readonly=1 ユーザーでは動作しません
},
})
```
readonly=1 ユーザーの制限事項についてさらに詳しく説明している[例](https://github.com/ClickHouse/clickhouse-js/blob/main/examples/node/security/read_only_user.ts)を参照してください。
### パス名付きプロキシ
ClickHouse インスタンスがプロキシの背後にあり、URL にたとえば [http://proxy:8123/clickhouse\_server](http://proxy:8123/clickhouse\_server) のようなパス名が含まれている場合は、`pathname` 設定オプションに `clickhouse_server` を指定してください (先頭のスラッシュの有無は問いません) 。これを `url` に直接指定すると、`database` オプションとして解釈されます。複数のセグメントにも対応しており、たとえば `/my_proxy/db` のように指定できます。
```ts theme={null}
const client = createClient({
url: 'http://proxy:8123',
pathname: '/clickhouse_server',
})
```
### 認証付きリバースプロキシ
ClickHouseデプロイの前段に認証付きのリバースプロキシがある場合は、`http_headers` 設定を使用して、そこで必要なヘッダーを指定できます。
```ts theme={null}
const client = createClient({
http_headers: {
'My-Auth-Header': '...',
},
})
```
### カスタム HTTP/HTTPS エージェント (実験的、Node.js のみ)
これは実験的な機能であり、今後のリリースで後方互換性のない変更が加えられる可能性があります。クライアントが提供するデフォルト実装と設定で、ほとんどのユースケースには十分対応できます。この機能は、本当に必要だと確信できる場合にのみ使用してください。
デフォルトでは、クライアントはクライアント設定 (`max_open_connections`、`keep_alive.enabled`、`tls` など) に基づいて、基盤となる HTTP または HTTPS エージェントを構成し、それが ClickHouse server への接続を処理します。さらに、TLS 証明書を使用する場合は、基盤となるエージェントに必要な証明書が設定され、適切な TLS 認証ヘッダーが適用されます。
1.2.0 以降では、カスタム HTTP または HTTPS エージェントをクライアントに渡して、デフォルトの基盤エージェントを置き換えることができます。これは、複雑なネットワーク構成で役立つ場合があります。カスタムエージェントが指定されている場合は、次の条件が適用されます。
* `max_open_connections` と `tls` オプションは基盤エージェントの設定の一部であるため、*効果はなく*、クライアントによって無視されます。
* `keep_alive.enabled` は、`Connection` ヘッダーのデフォルト値 (`true` -> `Connection: keep-alive`、`false` -> `Connection: close`) のみを制御します。
* アイドル状態の keep-alive ソケット管理は引き続き機能しますが (これはエージェントではなく個々のソケット自体に紐づいているため) 、`keep_alive.idle_socket_ttl` の値を `0` に設定することで、これを完全に無効化できるようになりました。
#### カスタムエージェントの使用例
証明書を使用しないカスタム HTTP または HTTPS Agent の例:
```ts theme={null}
const agent = new http.Agent({ // または https.Agent
keepAlive: true,
keepAliveMsecs: 2500,
maxSockets: 10,
maxFreeSockets: 10,
})
const client = createClient({
http_agent: agent,
})
```
basic TLS と CA 証明書を使用したカスタム HTTPS Agent:
```ts theme={null}
const agent = new https.Agent({
keepAlive: true,
keepAliveMsecs: 2500,
maxSockets: 10,
maxFreeSockets: 10,
ca: fs.readFileSync('./ca.crt'),
})
const client = createClient({
url: 'https://myserver:8443',
http_agent: agent,
// カスタムHTTPSエージェントを使用する場合、クライアントはデフォルトのHTTPS接続実装を使用しません。ヘッダーは手動で指定する必要があります
http_headers: {
'X-ClickHouse-User': 'username',
'X-ClickHouse-Key': 'password',
},
// 重要: 認証ヘッダーはTLSヘッダーと競合します。無効にしてください。
set_basic_auth_header: false,
})
```
相互 TLS で custom HTTPS Agent を使用する:
```ts theme={null}
const agent = new https.Agent({
keepAlive: true,
keepAliveMsecs: 2500,
maxSockets: 10,
maxFreeSockets: 10,
ca: fs.readFileSync('./ca.crt'),
cert: fs.readFileSync('./client.crt'),
key: fs.readFileSync('./client.key'),
})
const client = createClient({
url: 'https://myserver:8443',
http_agent: agent,
// カスタムHTTPSエージェントを使用する場合、クライアントはデフォルトのHTTPS接続実装を使用しません。ヘッダーは手動で指定する必要があります
http_headers: {
'X-ClickHouse-User': 'username',
'X-ClickHouse-Key': 'password',
'X-ClickHouse-SSL-Certificate-Auth': 'on',
},
// 重要: 認証ヘッダーはTLSヘッダーと競合します。無効にしてください。
set_basic_auth_header: false,
})
```
証明書 *と* カスタムの *HTTPS* Agent を併用する場合、TLS ヘッダーと競合するため、`set_basic_auth_header` 設定 (1.2.0 で導入) を使ってデフォルトの Authorization ヘッダーを無効にする必要がある可能性があります。TLS ヘッダーはすべて手動で指定する必要があります。
## 既知の制限事項 (Node.js/web)
* 結果セット向けのデータマッパーはないため、言語のプリミティブ型のみが使用されます。一部のデータ型マッパーは、[RowBinary フォーマットのサポート](https://github.com/ClickHouse/clickhouse-js/issues/216) とあわせて対応予定です。
* [Decimal\* および Date\* / DateTime\* データ型に関する注意点](/ja/integrations/language-clients/js#datedate32-types-caveats)がいくつかあります。
* JSON\* ファミリーのフォーマットを使用する場合、Int64+ 型の最大値は `Number.MAX_SAFE_INTEGER` より大きいため、Int32 を超える数値は文字列として表現されます。詳細は [整数型](/ja/integrations/language-clients/js#integral-types-int64-int128-int256-uint64-uint128-uint256) のセクションを参照してください。
## 既知の制限事項 (web)
* `select` クエリではストリーミングは機能しますが、`insert` では無効になっています (型レベルでも同様です) 。
* リクエストの圧縮は無効になっており、設定は無視されます。レスポンスの圧縮は機能します。
* まだログには対応していません。
## パフォーマンス最適化のヒント
* アプリケーションのメモリ使用量を減らすには、大量の insert (例: ファイルからの insert) や、該当する場合は select でストリームを使用することを検討してください。イベントリスナーなどのユースケースでは、クライアント側でのバッチ化を最小限に抑えたり、場合によっては完全に不要にしたりできるため、[非同期 INSERT](/ja/concepts/features/operations/insert/asyncinserts) も有力な選択肢です。非同期 INSERT の例は [クライアントリポジトリ](https://github.com/ClickHouse/clickhouse-js/tree/main/examples/node) にあり、ファイル名のプレフィックスは `async_insert_` です。
* クライアントでは、リクエストやレスポンスの圧縮はデフォルトで有効になっていません。ただし、大規模なデータセットを select または insert する場合は、`ClickHouseClientConfigOptions.compression` で有効化を検討できます (`request` のみ、`response` のみ、またはその両方) 。
* 圧縮には無視できないパフォーマンス低下があります。`request` または `response` に対して有効にすると、それぞれ insert または select の速度に悪影響がありますが、アプリケーションが転送するネットワークトラフィック量は削減できます。
## お問い合わせ
ご質問やサポートが必要な場合は、[Community Slack](https://clickhouse.com/slack) (`#clickhouse-js` チャンネル) または [GitHub issues](https://github.com/ClickHouse/clickhouse-js/issues) までお気軽にご連絡ください。