s16 行键不是索引，是物理布局 [card×1]: 论点=Bigtable 行键前缀决定数据落在哪个分片: 时间戳/自增 ID 做前缀会把所有新写集中到最后一个分片(写入热点), 加散列前缀后同样的写入均匀落到全部分片; 计算节点与 Colossus 存储分离, 扩容不搬数据。hero: 一条明亮的数据中心走廊, 一长排整齐的存储机架沿透视线延伸, 最末一台机架亮着醒目的暖色指示灯而其余机架均匀闪着蓝绿点, 两位工程师中景站在走廊中段查看平板, 白底, 左侧 40% 留白。stickers: 卡片 a=行键分片示意(16:9 横幅): 上下两排各八格的架子, 上排所有彩色方块全部堆在最右一格里溢出, 下排彩色方块均匀分布在八格中, 纯几何插画, 无任何文字
s17 便利建立在三条必须提前知道的约束上 [card×3]: 论点=Firestore 三条硬约束: 复合索引必须预先建(不支持 JOIN, 多字段组合查询需预建复合索引, 查询耗时只与返回文档数成正比); 单文档约 1 次/秒写入, 新集合 500/50/5 爬坡(热点文档需分片计数); 双模式(Native 有实时监听与子集合, Datastore 模式面向服务端)与 MongoDB 兼容层(翻译层, 底座仍是 Firestore)。hero: 一间明亮的移动应用工作室, 墙上三块玻璃白板并排写着抽象图形, 几位开发者中景围着长桌讨论手机原型, 白底, 左侧 40% 留白。stickers: 卡片 a=预建复合索引: 图书馆式的多层卡片目录柜, 抽屉按颜色分组, 一只手正把一张索引卡插入正确抽屉; 卡片 b=写入爬坡: 一段向上的阶梯坡道, 台阶从 500 起每级加高, 台阶上均匀排着蓝绿方块, 顶端一个计数器表盘; 卡片 c=双模式与兼容层: 两个并排的门, 左门通向实时脉冲信号房间, 右门通向服务器机柜, 门前一个翻译转接头连接着绿色叶子标志的接口
s20 向量不是专用库的专利: 论点=六个 Google Cloud 数据库引擎(AlloyDB AI ScaNN+pgvector, Cloud SQL pgvector, Spanner 向量索引, Firestore KNN, Memorystore 内存向量, BigQuery 向量检索)各自的向量能力、延迟规模特征与典型落点; 结论=不要为向量新增一套系统, 让嵌入贴着业务主数据走。hero: 一间明亮的研究实验室, 长桌上并排六个透明圆柱容器, 每个容器里悬浮着彩色点云, 一位研究员中景用平板比对, 白底, 左侧 40% 留白。stickers: 运维与开发两条线: 一块统一的仪表盘面板连接着多个小型数据库圆柱, 旁边一把带绿色接口的工具箱通过一根受控管道接向数据库 1张
s21 难的不是搬数据，是搬逻辑: 论点=迁移四步(评估与转换、全量搬迁、持续追平、割接)与两条路径: 关系型 Oracle/SQL Server → PG(DMS 转换 + Gemini 改写存储过程 + Datastream CDC 追平, 人工审核工时决定工期); 非关系型宽列与文档(Cassandra/HBase 经 Dataflow 模板入 Bigtable 且行键必须重设; MongoDB/DynamoDB 经 Firestore 兼容层直连)。hero: 一座明亮的现代物流转运中心, 一条长传送带把不同颜色的箱子从旧式仓库运向发光的云端站台, 几位工作人员中景在传送带旁核对清单, 白底, 左侧 40% 留白。stickers: 关系型迁移: 一组咬合的齿轮被拆开重新装配, 旁边一头蓝色的大象轮廓接住齿轮; 宽列与文档双路径: 两条并行传送带, 一条运着宽宽的彩色条状卡片, 另一条运着一叠文档, 两条带汇入同一个云端站台 2张
s22 把 SLA 换算成停机分钟再谈架构: 论点=可用性承诺与年/月停机分钟换算表(99.9% = 525.6 分钟/年, 99.95% = 262.8, 99.99% = 52.6, 99.999% = 5.3)及对应典型配置; 结论=先定 RTO/RPO 再反推拓扑, 而不是先选产品再解释可用性。hero: 一间明亮的运维指挥室, 大屏上是一排从高到低的柱状指示, 桌上一只精密的机械计时表盘, 两位工程师中景在桌前讨论, 白底, 左侧 40% 留白。stickers: 先定 RTO/RPO: 一只干净的圆形仪表盘, 表盘上一小段红色扇区代表停机分钟, 其余为绿色, 指针指向红色扇区边缘 1张
