调研不代表实践, 谨慎采纳, 结论后续实践后放出. 本文主题:[存储上云] TiDB 和 Polardb.
MySQL 在达到一定数据量 (我的经验是 3T, 单表 1 亿) 时, 复杂查询会有明显的延迟. 继续分库分表, 会严重增加业务复杂性, 尤其对很多非互联网产品来说, 急需一个分布式存储.
MySQL 本身也做了一些努力, 那就是基于 Paxos 协议的 MGR. 但它没有 Sharding 的解决方案, 需要借助其他中间件. 在 《"分库分表" ? 选型和流程要慎重, 否则会失控》 https://mp.weixin.qq.com/s/U_pEF9sfnXeZ7RnhGFnqyg 一文中, 我们能够看到 Sharding 这个过程的复杂性. 如果一个 DB, 本身自带这些光环, 就耀眼的多.
这样的 DB 已经有很多, 其中, 以 Aurora 为代表的云数据库进入视野. 根据其流行度, 仅对 PorlarDB 和 TiDB 进行了调研.
其他产品, 包括但不限于:
- Greenplum
- Druid
- Aurora
- Taurus
- Spanner
- NuoDB
- Oracle Exadata
- Oracle RAC
如果你时间有限, 直接看初步结论即可. 下面的内容可以忽略.
初步结论
它们都支持 MySQL 协议, 现有业务迁移起来会比较平滑, 但对硬件的要求都较高. 部分一致性都有 Raft 协议的参与, 可靠性都有保证.
TiDB 是开源的, 某些组件强制要求 SSD, 且需配备 DBA, 造成了整体成本的上升. 但是使用案例较多, 经历过较大规模的应用.
PolarDB. 阿里新的明星产品, 价格相对合理, 但使用案例有限, 也无法窥视其源码, 只有零星宣传文档. 鉴于阿里喜好夸大的尿性, 需试用后进行深入评价. 但云端优势太明显, 已被优先考虑.
通过咨询已有经验的实践者, 普遍吐槽会遇到很多奇怪的问题, 并不像宣传中的那么美好.
以下.
来源: http://www.tuicool.com/articles/NZrMzyB