"Distributed-Sql"
- CockroachDB HLC + Raft Consensus：軟體時鐘 + per-range 共識的 latency 與容量結構
CockroachDB 用 Hybrid Logical Clock + per-range Raft 做跨節點線性化、不靠 TrueTime 原子鐘。本文走 HLC / Raft / range / leaseholder 四層機制、寫入 latency 構造、failure mode（clock skew panic / Raft majority lost / hot range）、引用 DoorDash Aurora 撞牆訊號（1.636 M QPS 屬 Aurora 痛點而非 CockroachDB 容量證明）+ Netflix 380+ artery of small DBs 容量規劃顆粒
- Aurora PG/MySQL vs Aurora DSQL 取捨：何時 single-region managed 夠用、何時跨到 distributed
Aurora DSQL 不是 Aurora 的升級版而是不同 paradigm；本文聚焦『standard Aurora（single-region managed SQL）什麼時候夠用、什麼時候需要跨到 active-active distributed』的升級門檻決策，切分『怎麼遷』（migrate-to-aurora-dsql）與『DSQL vs Spanner vs CockroachDB 三方選型』（decision-tree）兩個既有 SSoT
- CockroachDB Survival Goals：zone 級 vs region 級配置與業務 SLO 倒推流程
CockroachDB 用 SURVIVE ZONE FAILURE / SURVIVE REGION FAILURE 兩種 survival goal 宣告式控制 Raft replica 分佈、決定 RTO / RPO。本文走 Hard Rock Digital bet placement RPO=0 倒推流程、Netflix Gaming 48-node 跨 4 region 「為求 survival 而非 latency」的反直覺判讀、配置語法、寫入 latency 暴漲跟 cost 暴漲兩條失敗模式、合規邊界對比
- PostgreSQL → Aurora DSQL Migration：PG wire-compatible Distributed SQL 的 Paradigm Shift
Aurora DSQL（2024-12 re:Invent preview / 2025-05 GA）是 AWS 推的 PG wire-compatible *active-active distributed SQL*、跟 self-managed PG / Aurora PG 不同 paradigm（OCC + snapshot isolation + multi-region strong consistency）。Migration 結構是 *protocol drop-in + paradigm shift*：app SQL 不太改、但 transaction retry / extension 缺位 / 多 region 一致性需重設計。本文走 DSQL vs Aurora PG vs self-managed PG 三軸對比、為什麼遷的三條 driver（global write / operational zero-touch / region resiliency）、Type E phased plan、5 production 踩雷（transaction retry 沒處理 / extension 缺位 / sequence throughput 限制 / Aurora PG 直升 DSQL 不可行 / region failover semantic）、跟 PG → Aurora 跟 PG → CockroachDB 對比
- CockroachDB Transaction Retry Pattern：serializable default 與 application contract 重塑
CockroachDB default SERIALIZABLE、application 必須包 retry loop 處理 40001 serialization_failure。本文走 PG → CockroachDB application contract 重塑視角、SAVEPOINT cockroach_restart 語法、5 種失敗模式（retry storm / 非冪等 / cross-statement state / hot row / long-running transaction）。**整篇是跨 case 合成 frame**：DoorDash case 沒揭露 retry pattern、只揭露 PG wire protocol 相容 + SQL 行為仍要 audit、本章 retry contract 重塑屬通用工程議題從 Cockroach Labs 官方 docs 合成
- CockroachDB Locality-Aware Schema：跨州合規 + 邏輯一個 cluster 的 region placement 策略
Hard Rock Digital 跨 8 州 sportsbook、用 AWS Outposts + region placement 把運算釘在州內、邏輯上仍是一個 CockroachDB cluster。本文走 REGIONAL BY ROW / REGIONAL BY TABLE / GLOBAL 三種 locality、Hard Rock 拓樸創新對比 Standard Chartered Aurora 7 cluster fleet、AWS Outposts 是合規工具不是 latency 工具的反直覺判讀
- CockroachDB Multi-region Table 配置：三種 table locality 的選擇與 latency / 一致性取捨
CockroachDB 把 multi-region table 抽象成 REGIONAL BY TABLE / REGIONAL BY ROW / GLOBAL 三種 locality、每種對 read / write latency 跟一致性付不同成本。本文走三種 locality 的判讀軸、survival goal 怎麼跟 locality 一起決定副本拓樸（機制本身 cross-link survival-goals）、配置與驗證流程、選錯要重配的高代價回退、容量觀測訊號
- CockroachDB Cloud Serverless 適用判斷：按用量 vs dedicated 的取捨與 RU 計費結構
CockroachDB Cloud 的 serverless（按用量 RU 計費、自動 scale-to-zero）跟 dedicated（固定 cluster、自管容量）解不同的容量壓力。本文走 serverless 的 RU 計費結構與冷啟動 / scale 行為、何時 serverless 何時 dedicated 的判讀軸、用量暴衝的成本失控回退、跟 self-managed（Netflix Platform Team / Hard Rock 賽季擴縮）的責任對照
- CockroachDB vs Aurora DSQL vs Spanner：撞牆訊號分型 + 七問題決策樹
Distributed SQL 三選一決策樹。先用撞牆訊號分型識別 driver path（DoorDash 單主寫入撞牆 / Netflix Cassandra 缺口 / Hard Rock 合規驅動）、再走七問題（跨雲 / 雲商生態 / 風險預算 / PG 相容 / 管理負擔 / team size / vendor sizing barrier）。PostgreSQL 相容性 audit checklist 4 項、Spanner 100 pu sizing barrier、Hard Rock 「省 10-20 工程師」機會成本警示、Netflix Database Platform Team 規模
- PostgreSQL to YugabyteDB / TiDB Migration
PostgreSQL 轉向 YugabyteDB、TiDB 類 distributed SQL 的 compatibility audit、data topology、transaction、cutover 與 rollback