Greptime 技术

4 篇内容

技术文章Greptime 技术

JSON Is No Longer a Blob: Inside GreptimeDB 1.2's New JSON Type

文章深入解析 GreptimeDB 1.2 新增的 JSON2 类型,针对传统 JSONB 按整文档存储、分析查询需读取并解析完整 JSON 的问题。其核心是有界自动 shredding:高频路径展开为独立列,并分为静态类型路径、预算内动态路径和 Parquet Variant 余量三层;查询时通过类型具体化从 SQL 推断所需结构类型,类型提示可固定路径类型并拒绝不匹配写入。结论是 JSON2 适合日志、trace 等可观测性场景,能按路径裁剪读取且保留原始嵌套;但冷路径仍需读余量,类型推断可能出错,自动展开有上限,1.2 中修改配置尚未正式支持。

推荐收录:文章不仅介绍功能,还给出 JSONB 与 JSON2 的读写差异、三层存储、类型具体化、类型提示和完整 SQL 示例,并引用 JSONBench 数据说明边界。适合数据库、存储引擎、可观测性平台工程师理解半结构化数据的列式化设计;可迁移到日志/trace 分析中的路径裁剪、列式存储和类型约束设计,但需留意冷路径读取与类型推断错误风险。

技术文章Greptime 技术

JSON Is No Longer a Blob: Inside GreptimeDB 1.2's New JSON Type

文章解析 GreptimeDB 1.2 新增的 JSON2 类型,面向日志、Trace 等路径繁多但查询只访问少数路径的 JSON 数据。传统 JSONB 按整文档存储,读一个字段也需扫描和解析完整文档,索引无法消除这类 I/O 与 CPU 放大。JSON2 采用有界自动 shredding,将热路径展开为独立 Parquet 列,长尾写入 Parquet Variant remainder,并支持 type hints 固定类型;查询端通过 query type concretization 从 SQL 推导结构化类型,实现列裁剪与向量化执行。局限是类型推断依赖 SQL 表达式,写错可能返回无意义结果,且 1.2.x 不能修改已有 JSON2 配置。该方案适合可观测性分析,但冷路径仍需读 remainder,自动展开预算默认 100。

推荐收录。文章基于 GreptimeDB 1.2.1 的真实实现,清晰给出 JSONB 整文档读放大、JSON2 有界 shredding、Parquet Variant remainder、query type concretization 与 type hints 的设计细节和 SQL 示例,并明确说明类型推断错误、冷路径成本和 1.2.x 配置不可变等边界。适合数据库内核、存储引擎和可观测性平台开发者参考,其“热路径列化+长尾归并+查询驱动类型推导”的取舍可迁移到其他半结构化分析系统。

工程实践Greptime 技术

Building a Unified Observability Platform on GreptimeDB: A Reference Architecture

文章提出在 GreptimeDB 上构建统一可观测性平台的参考架构,将指标、日志和追踪汇入同一数据库,同时保留现有采集器协议。作者以 OpenTelemetry Astronomy Shop 为验证环境,用单个 GreptimeDB 实例替换 Jaeger、OpenSearch 和 Prometheus,详述写入端点、按信号分表、Flow 物化视图、TTL/WAL、查询接口及三档集群拓扑。核心决策包括按信号分表、按量分区、用 Flow 隔离仪表盘告警热路径,并展示基于 trace_id 的跨信号 SQL 关联与延迟自连接分析。边界是 Loki 仅兼容写入、Elasticsearch 开源版仅 _bulk,亚毫秒指标查询弱于 VictoriaMetrics,部分隔离与告警属企业版。验证以单机演示和有限基准为主,生产需按自身负载验证。

推荐收录:文章给出可直接复用的参考架构、写入端点表、表设计、Flow/TTL/WAL 与三档拓扑,并用 OTEL Demo 实际数据展示跨 trace_id 日志关联和延迟自连接,工程证据具体。适合负责可观测性平台、数据库选型和 SRE/平台工程落地的读者。需注意来源为厂商博客且验证以单机演示和厂商基准为主,大规模生产收益应结合自身负载验证。

工程实践Greptime 技术

Building a Unified Observability Platform on GreptimeDB: A Reference Architecture

文章提出用单个 GreptimeDB 统一承载 metrics、logs、traces 的参考架构,并在 OpenTelemetry Astronomy Shop 演示环境中验证。它给出 Prometheus remote write、OTLP、Loki、Elasticsearch _bulk 等写入协议与端点,讨论 Metric Engine、表/分区设计、Flow 物化视图、TTL、WAL 和查询接口的工程取舍。文中用真实 SQL 展示从告警到 trace、日志的跨信号排障及客户端/服务端延迟自连接,并按 standalone、小集群、大集群三档给出拓扑建议。作者也列出迁移路径、开源/企业版边界,并承认亚毫秒热指标查询不如 VictoriaMetrics、Loki/Elasticsearch 读兼容有限。整体偏 GreptimeDB 产品指南,但架构流程与验证数据有可迁移价值。

推荐收录。文章以 OTel Demo 实测数据给出统一观测平台的写入协议、表设计、Flow 热冷路径隔离、TTL/WAL 和规模分层,并用真实 trace_id 串联日志与 span 排障,适合可观测性平台和 SRE 读者迁移参考。主要风险是内容来自 GreptimeDB 厂商,部分性能与 Agent 对比结论带有产品视角,需结合自建基准验证。