"Cockroachdb"
- 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 容量規劃顆粒
- 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 → CockroachDB：三維皆 High 的多重歸類 migration
PostgreSQL → CockroachDB 是 Schema / Operational / Paradigm 三維皆 High 的 multi-axis migration、實證 [#127](/report/content-structure-by-max-diff-dimension/) 的「多重歸類跟 tie-breaking」規則；主結構走 Type E paradigm shift、Schema 差 + Operational redesign 抽出獨立段；涵蓋 transaction model 重設計、SQL dialect gap、5 個 production 踩雷
- 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 規模