本文描述了 Snuba
查詢語言 (SnQL
)。
系列
- 1 分鐘快速使用 Docker 上手最新版 Sentry-CLI - 建立版本
- 快速使用 Docker 上手 Sentry-CLI - 30 秒上手 Source Maps
- Sentry For React 完整接入詳解
- Sentry For Vue 完整接入詳解
- Sentry-CLI 使用詳解
- Sentry Web 效能監控 - Web Vitals
- Sentry Web 效能監控 - Metrics
- Sentry Web 效能監控 - Trends
- Sentry Web 前端監控 - 最佳實踐(官方教程)
- Sentry 後端監控 - 最佳實踐(官方教程)
- Sentry 監控 - Discover 大資料查詢分析引擎
- Sentry 監控 - Dashboards 資料視覺化大屏
- Sentry 監控 - Environments 區分不同部署環境的事件資料
- Sentry 監控 - Security Policy 安全策略報告
- Sentry 監控 - Search 搜尋查詢實戰
- Sentry 監控 - Alerts 告警
- Sentry 監控 - Distributed Tracing 分散式跟蹤
- Sentry 監控 - 面向全棧開發人員的分散式跟蹤 101 系列教程(一)
- Sentry 監控 - Snuba 資料中臺架構簡介(Kafka+Clickhouse)
- Sentry 監控 - Snuba 資料中臺架構(Data Model 簡介)
- Sentry 監控 - Snuba 資料中臺架構(Query Processing 簡介)
- Sentry 官方 JavaScript SDK 簡介與除錯指南
- Sentry 監控 - Snuba 資料中臺架構(編寫和測試 Snuba 查詢)
以下是 SnQL
的查詢結構:
MATCH simple | join | subquery
SELECT [expressions] | [aggregations BY expressions]
ARRAY JOIN [column]
WHERE condition [[AND | OR] condition]*
HAVING condition [[AND | OR] condition]*
ORDER BY expressions ASC|DESC [, expressions ASC|DESC]*
LIMIT expression BY n
LIMIT n
OFFSET n
GRANULARITY n
TOTALS boolean
這些查詢作為字串傳送到 /:dataset/snql
端點,編碼為以下格式的 JSON body
:
{
"query": "<query>",
"dataset": "<dataset>",
"consistent": bool,
"turbo": bool,
"debug": bool,
}
資料集(dataset)
通過查詢使用的 url
隱含。在 JSON
主體中,除了 query
之外的所有欄位都是可選的。
MATCH
我們的資料模型由實體圖表示。該子句標識了我們正在查詢的子圖(subgraphs)
的模式。目前支援三種型別的 MATCH
子句:
Simple:
MATCH (<entity> [SAMPLE n])
這相當於我們當前的所有查詢。 這是從單個實體(事件、事務等)查詢資料。可以通過將其與實體一起新增來向查詢新增可選 sample
。
例如:MATCH (events)
Subquery:
MATCH { <query> }
花括號內可以是另一個完整的 SQL
查詢。子查詢的 SELECT/BY
子句中的任何內容都將使用指定的別名在外部查詢中公開。
例如:
MATCH {
MATCH (transactions)
SELECT avg(duration) AS avg_d BY transaction
}
SELECT max(avg_d)
Join(連線):
MATCH (<alias>: <entity> [SAMPLE n]) -[<join>]-> (<alias>: <entity> [SAMPLE n])
一個 join
代表一個多節點子圖(subgraph)
,是一個包含不同節點之間的多個關係的子圖。目前支援節點之間的 1..n
、n..1
和 1..1
有向關係。
對於 JOIN
,每個實體都必須有一個別名,這是一個唯一的字串。 抽樣(Sampling)
也可以應用於 join
中的任何實體。<join>
是在 Snuba
中的 Entity
中指定的字串,是一組 join
條件的簡寫。可以有多個 join
子句,用逗號分隔。
例如:
MATCH
(e: events) -[grouped]-> (g: groupedmessage),
(e: events) -[assigned]-> (a: groupassignee)
SELECT count() AS tot BY e.project_id, g.id
WHERE a.user_id = "somebody"
join
型別(left/inner
)和 join key
是資料模型的一部分,而不是查詢的一部分。它們被硬編碼在實體程式碼中。 這是因為沒有實體可以安全地與底層資料庫的分散式版本中的任何其他實體連線。
match
子句提供給 where
子句的元組(tuple)
看起來與傳統 join
子句生成的元組完全一樣:
[
{"e.project_id": 1, "g.id": 10}
{"e.project_id": 1, "g.id": 11}
{"e.project_id": 2, "g.id": 20}
...
]
SELECT .. BY
該子句指定應在輸出中返回哪些結果。如果存在聚合(aggregation
),則 BY
子句中的所有內容都被視為分組 key
。 如果我們想要聚合整個結果集,則可以在沒有 BY
子句的情況下進行聚合,但在這種情況下,SELECT
中只能包含聚合。即使有 BY
子句,空的 SELECT
子句也是無效的。
SELECT
子句中的表示式
可以是列
、算術
、函式
或三
者的任意組合。 如果查詢是 join
,則每一列都必須有一個符合條件的別名,該別名與 MATCH
子句中的實體別名之一匹配。
WHERE
這是在聚合之前發生的查詢的過濾器(如 SQL
中的 WHERE
)。
條件是 LHS OP RHS*
形式的中綴表示式,其中 LHS
和 RHS
是字面值
或表示式
。OP
指的是一個特定的運算子
來比較
兩個值。 這些運算子是 =
、!=
、<
、<=
、>
、>=
、IN
、NOT IN
、LIKE
、NOT LIKE
、IS NULL
、IS NOT NULL
之一。請注意,當使用像 IS NULL
這樣的運算子時,RHS
是可選的。
可以使用布林關鍵字 AND
或 OR
組合條件。它們也可以使用 ()
進行分組。
HAVING
像 WHERE
子句一樣工作,但它在 SELECT
子句中宣告的聚合之後應用。 所以我們可以在這裡對聚合函式的結果應用條件。
ORDER BY
指定對結果集進行排序的表示式。
LIMIT BY/LIMIT/OFFSET
不言自明,它們採用整數並在 Clickhouse
查詢中設定相應的值。 如果查詢未指定 limit
或 offset
,它們將分別預設為 1000
和 0
。
GRANULARITY
一個整數,表示對基於時間的結果進行分組的粒度。
TOTALS
如果設定為 True
,來自 Snuba
的響應將有一個 “totals”
key,其中包含所有選定行的總值。
SAMPLE
如果 MATCH
子句中的節點未提供取樣率
,則可以在此處指定。 在這種情況下,Snuba
會將 sample right
分配給查詢中的節點之一。sample
可以是介於 0
和 1
之間的浮點數,表示要取樣的行的百分比。
或者它可以是一個大於 1
的整數,表示要取樣的行數。