Skip to main content

database-clickhouse-weaviate

ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths.

Quellinformationen

Repository
latitude-dev/latitude-llm
Letzte Quellaktivität
12. Juni 2026 um 08:16
Erkannte Sprache von SKILL.md
Englisch
Sterne
4.722
Forks
402

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
database-clickhouse-weaviate
description
ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths.
# ClickHouse **When to use:** ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths. ## ClickHouse queries ClickHouse adapter stack remains SQL-oriented in `packages/platform/db-clickhouse`. **All ClickHouse queries must use parameterized bindings** (`{name:Type}` syntax with `query_params`) — never interpolate user-supplied values directly into SQL strings. ## ClickHouse migrations (Goose) **Install goose** (if not already installed): ```bash brew install goose ``` Migration files live in `packages/platform/db-clickhouse/clickhouse/migrations/`: - `unclustered/` — single-node deployments (local dev, default) - `clustered/` — distributed deployments (`LAT_CLICKHOUSE_CLUSTER_ENABLED=true`) Goose tracks applied migrations automatically in the `goose_db_version` table. The repo also keeps `packages/platform/db-clickhouse/clickhouse/.migration-lock`, regenerated by `ch:create`, solely to force git conflicts when developers create migrations in parallel. ### Migration execution safety (agents) Same rule as Postgres: **do not run** `ch:*` or `ch:schema:dump` unless the user explicitly asked in this conversation. **Commands (run from repo root):** ```bash # Apply all pending migrations pnpm --filter @platform/db-clickhouse ch:up # Roll back last migration pnpm --filter @platform/db-clickhouse ch:down # Show migration status pnpm --filter @platform/db-clickhouse ch:status # Create a new migration (creates the next sequential file in both unclustered/ and clustered/) pnpm --filter @platform/db-clickhouse ch:create <migration_name> # Roll back ALL migrations (equivalent to drop) pnpm --filter @platform/db-clickhouse ch:drop # Reset ClickHouse volume and re-migrate (nuclear option) pnpm --filter @platform/db-clickhouse ch:reset # Seed sample span data pnpm --filter @platform/db-clickhouse ch:seed ``` ### Creating migrations 1. `ch:create <name>` — creates the next sequential migration (for example `00016_name.sql`) in both `unclustered/` and `clustered/`, and updates `clickhouse/.migration-lock` 2. Fill in both files (see rules below) 3. Commit both migration files plus `clickhouse/.migration-lock` ### Migration file rules - Each migration is a single `.sql` file with `-- +goose Up` and `-- +goose Down` sections - Always include `-- +goose NO TRANSACTION` (ClickHouse does not support transactions) - ClickHouse migration history is append-only in this repository. Do not edit existing Goose migration files; add a new migration in both `unclustered/` and `clustered/` instead. - For additive changes to existing tables, prefer ordinary `ALTER TABLE` or additive projection migrations with sensible defaults unless the change truly requires a table rebuild. - `unclustered/`: use standard table engines (e.g. `ReplacingMergeTree`) - `clustered/`: add `ON CLUSTER default` and use `Replicated*` engines ### Clustered migration reliability (replica lag / Code 517) In clustered ClickHouse, replicas can temporarily lag DDL metadata propagation. A migration can fail with: - `code: 517` - `Code: 517` - `doesn't catchup with latest ALTER query updates` Use these authoring rules to reduce failures: - Keep migrations idempotent (`IF EXISTS` / `IF NOT EXISTS`) so retries are safe. - Prefer additive schema changes over destructive rewrites. - Keep DDL batches small; avoid chaining many dependent `ALTER` statements in one migration. - For tightly-coupled changes on the same table in replicated clusters, prefer one `ALTER TABLE ...` with multiple actions over multiple dependent ALTER statements. - If statement B depends on metadata introduced by statement A, prefer splitting them into separate migration files. - Avoid coupling view rebuilds and many base-table changes in one large migration when possible. - Run one migration runner per environment (never concurrent `ch:up` against the same cluster). Execution safety: - `packages/platform/db-clickhouse/clickhouse/scripts/up.sh` retries transient replica lag errors from `goose ... up`. - In clustered mode, migration sessions set `alter_sync`, `distributed_ddl_task_timeout`, and `replication_wait_for_inactive_replica_timeout` to improve DDL convergence. - Retry tuning env vars: - `LAT_CLICKHOUSE_MIGRATION_MAX_RETRIES` (default `20`) - `LAT_CLICKHOUSE_MIGRATION_RETRY_DELAY_SECONDS` (default `5`) - `LAT_CLICKHOUSE_MIGRATION_MAX_RETRY_DELAY_SECONDS` (default `30`) - Clustered DDL tuning env vars: - `LAT_CLICKHOUSE_MIGRATION_ALTER_SYNC` (default `2`) - `LAT_CLICKHOUSE_MIGRATION_DISTRIBUTED_DDL_TASK_TIMEOUT_SECONDS` (default `300`) - `LAT_CLICKHOUSE_MIGRATION_REPLICA_WAIT_TIMEOUT_SECONDS` (default `300`)
Auf GitHub ansehen