Read-only by default. When the server runs with write mode enabled
(--allow-write / GREPTIMEDB_ALLOW_WRITE), destructive SQL (DDL/DML) is
also permitted.

Use it when deciding how to query an unfamiliar table. When the right table
is not known yet, search_table_semantics first; describing candidates one
by one is slower than querying the data.

The semantic profile says what the table means, not what its data says.
signal_type is metric, log, trace, or event; source and source_version name
the ingestion protocol; pipeline names the schema that shaped the rows;
semantic_options carries signal-specific facts such as metric type and
unit. metadata_quality describes how the metric type was obtained --
`declared` by the protocol or `inferred` from the name -- and says nothing
about telemetry quality. entity_declarations lists the entities the table
contributes to the semantic graph. A null or missing semantic field means
unknown, not the opposite fact.

Searches table names, semantic options, and entity declarations, and ranks
tables by how many query terms they matched. Use it before describe_table
when the schema is wide or table names do not say what they hold.

It searches schema metadata only, never telemetry row values, so it can say
which table holds Redis memory usage but not which row belongs to
`Redis02`. It ranks on the values in that metadata, not on the schema's own
key names, so search for `gauge` or `bytes` rather than `metric type`. Once
it returns candidates, query their data or describe one of them; do not
describe every candidate in turn.

It covers only the database this server is connected to, unlike
describe_table, which accepts a schema-qualified name.

Only tables carrying a `greptime.semantic.*` option, or one a built-in
convention derives a declaration for, are visible here. A table absent from
the results may still exist and hold the data, so fall back to SHOW TABLES
rather than concluding it is not there.

Use view=summary when the entity and relationship types in this graph are
not known yet; it reports them with the endpoint type pairs each
relationship connects. With a type or an id already in hand, query
entities or relationships directly.

The window is required and half-open, [start_time, end_time), over
observed_at -- the 60-second bucket an observation was recorded in. Rows
are aggregated across the buckets in the window, and the result echoes the
window and the limit it used.

relationships returns one row per edge per confidence. The database reports
confidence 1.0 for a bucket whose client and server spans paired and 0.5
for one where only the client was seen, and it switches request_count,
error_count and the durations to whichever population that bucket
describes: paired requests timed by the server span, or unmatched clients
timed by their own. An edge observed both ways therefore comes back as two
rows. unmatched_count reports client spans with no paired server span.
Durations are in seconds.

entities returns one row per distinct set of attributes, so an entity whose
descriptive attributes changed inside the window appears more than once;
item_count counts rows, not entities. first_seen and last_seen bound where
the row was observed inside this window, not when the entity first existed.

Ordering is by type and endpoint. Only `calls` edges carry request, error
and duration counts, so pass rel_type=calls to order by error and request
count instead. When complete is false, more rows matched than the limit and
later types may be absent entirely rather than merely cut short.

A missing edge is not evidence that two entities are unrelated: it can also
mean the call was not instrumented, was sampled out, or fell outside this
window. Entities are not deduplicated across identity schemes, so one
process can appear under two ids if two sources named it differently.

entity_id_attrs names the attributes an id was assembled from and
source_tables names the telemetry tables that witnessed it. Identifiers
from alerts and other tools are not graph ids unless a query here returned
that exact string.

When masking is on, a returned field is hidden if its own name matches a
sensitive pattern, and an attribute map is also masked by the names inside
it. entities additionally hides entity_id when a masked attribute helped
build it; relationships cannot do the same, because its view does not carry
attribute names, so such a value can still appear there as src_id or
dst_id.

You can test a pipeline in two ways:
- Provide 'pipeline' with inline YAML configuration
- Provide 'pipeline_name' to test a previously saved pipeline

Args:
    pipeline: Pipeline YAML configuration (inline)
    pipeline_name: Name of saved pipeline (mutually exclusive with pipeline)
    data: Test data in JSON/NDJSON format
    data_type: Optional content type (e.g., 'application/x-ndjson')