Aidan's Blog

軟體開發筆記、技術整理與個人興趣。

最新文章

沒索引:Seq Scan(全表掃) 列 1 列 2 列 3 列 4 列 5 ← 目標 列 6 逐列掃過才找到 → O(n),資料越多越慢 有索引:B-tree 根 節點 節點 葉 葉 目標 葉 沿樹往下幾步就到 → O(log n)

索引為什麼快 —— 也為什麼會失效

· tech · 約 2 分鐘 · 📚 SQL 我以為我懂 #9

進入第三幕:引擎與效能。第一個要懂的就是索引——為什麼加了它查詢快幾百倍,又為什麼有時加了卻好像沒用。這兩個問題的答案,都藏在它的資料結構裡:B-tree。 沒有索引時,WHERE id = 500 …

#sql#performance

直接 GROUP BY date_trunc 日期筆數 7/013 7/025 7/03 沒這列 ✗ 7/042 補洞 generate_series + COALESCE 0 7/013 7/025 7/030 7/042 GROUP BY 只產出「有資料」的桶 —— 沒訂單的 7/03 整列消失,時間序列就斷了

時間分桶與 SCD:SQL 處理時間的兩個坑

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #8

接著上一篇的「區間」,這篇收尾第二幕,講時間在 SQL 裡的兩個坑——它們都源自同一件事:時間是連續的,但你的資料是離散的事件。 中間必然有「什麼都沒發生」的空隙,以及「值變了但你沒記」的變化。SQL…

#sql#data-engineering

你的服務 ① Latency 延遲 請求要多久才回? 分開看「成功」與「失敗」的延遲 ② Traffic 流量 系統現在多忙? QPS / 每秒請求數 ③ Errors 錯誤 多少請求失敗了? 失敗率(含「回 200 但內容是錯的」) ④ Saturation 飽和度 離極限還有多近? 資源用了幾成 → 最能預警 前三個 = 使用者體感(可直接當 SLI);第四個「飽和度」= 還能撐多久的預警

監控:四個黃金訊號

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4

上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…

#sre#monitoring

是不是 toil?看這六個特徵 ✓手動 —— 要人一步步動手做 ✓重複 —— 做過很多次、之後還會再做 ✓可自動化 —— 機器能做,只是還沒有人去寫 ✓無長期價值 —— 做完,系統並沒有變得更好 ✓隨規模線性成長 —— 服務變大,它就跟著變多 ✓被動反應 —— 被觸發才做,不是主動規劃出來的 符合越多 → 越是 toil。注意:開會、規劃、寫文件是 overhead,不算 toil

消除 Toil:把重複的維運當成待消滅的 bug

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3

第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…

#sre#reliability

Tools · Guides