上篇回顾
分布式可观测性 Logging 浅谈
分布式可观测性 Structured Log
分布式可观测性 Metrics 浅谈
继续浅谈Observability的最後一个基石
单体架构下, 基本上调用关系仅在同一个process的记忆体内做调用, 通常都是透过stack trace做调用链路的trace.
将这些资讯给汇出後, 再通过类似Flame Graph的工具, 进行可观测性的分析. 也可透过图, 来得知调用关系.
但是在Distributed System下常常, 服务之间相互调用, 其调用的机器与网路甚至不是同一个.
一样也是要透过调用链路收集的工具, 把Distributed System的调用链路整成一个跟stack trace很像的结构与资讯. 其中也包含每个调用链路的耗时时长.
这就是Distributed Tracing, 能参考去年我的文章Distributed Tracing & OpenTelemetry介绍
前面两个维度讲的资料, 都是以Time Series Data的方式呈现.
Time Series Data反应的是Metric指标在某一个时间点上的状态.
这种资料与MySQL这类的OLTP资料有所不同.
Time Series Data会有一些独特的概念
所以 Metric+Label决定了一个计量的单位.
如果以MySQL来存放, 那一个Metric就会是一张表了, Label则是里面的栏位, 可能还会有其他栏位像是Timestamp.
再来MySQL这类的资料库, 通常以B+Tree做资料存储结构, 通常会以读取的顺序依序做排序,
因为B+Tree预设是为了对磁碟做存取操作的, 它所有资料都存在Leaf叶子节点中.
每次查询时, 需要从Root节点查询到Leaf节点, 在从Leaf节点对应的位子进行读取, 其存放的顺序刚好跟读取所需要的顺序是一致的. 然後Leaf节点的资料是放在磁碟内的Page, 读取一整个page出来後放到Memory中.
但没人说物理Page刚好位子都是相邻的.
这样的结构好处是插入删除的时间复杂度是O(log2N), 查询要看情况, 可以非常好也能很不好.
这种随机读写的场景蛮常见的, 会导致时间大多花在磁盘寻址上.
大家应该组机很常去跑CrystalDisskMark这工具, 来看磁碟的随机读写与顺序读写的速度快慢.
可以发现顺序读写的效率跟俗机读写的效率不是一个量级的
哪怕你是SSD
但Time Series Data的另一个特徵是海量的资料量
, 这些资料量在写入是挑战,
如果几十万笔, Log2N才多少, 但若是1亿笔就可怕了
所以有下面结构的资料库
所以有令一种资料库很适合存放Time Series Data, 它叫LSM-Tree (Log Structured Merge Tree)
核心思想是 将离散的随机
写入请求都转成批量的顺序
写入请求
透过在记忆体整理後, 只要确保在记忆体时, 资料是按照顺序排列的,
当记忆体的资料累积到一个量时, 会做一些归并整理, 在直接写到硬碟中.
这样子就不用一直的写入了, 毕竟写到记忆体是非常高效率的.
为了避免资料在资料库当机後遗失, 也是会采取WAL(Write Ahead Log)的机制.
虽然它没解决掉查找还是随机位置的问题,
但记得 监控在意的是过去短时间内的聚合资料而已. 近期的资料会在记忆体中, 查询依然非常高效率.
这类的介绍, 明年看有否机会深入.
>>: 30天学习笔记-day 23- Dagger (上篇)
一日客语:中文:不好意思 客语:paiˇse! ㄆㄞˇ 厶ㄟ 1.set 是一个集合 2.集合没有索...
Creational 建立相关的 patterns 已经告一段落,接下来要进入 Structural...
ItemTouchHelper 接续昨天的RecyclerView,今天来让RecyclerView...
我把它分成使用基本款 (可安装 Agent)、通用款 (支援监控类通讯协定)、简易款 (无法安装 A...
tags: 铁人赛 Git GitHub 版本控制 概述 碎念时间 为什麽我们需要 版本控制 ? 每...