@my2019edc 戾气太重了，美团开源的东西并不少，Cat，Zebra，Octo，mpvue 等等，反哺社区的我知道的也有 Doris、Kylin、TiDB 这些

@winoros 嗯，不是说冲突，是猜着应该是要在标准 mysql protocol 上面做扩展了，比如指定哪些表需要列存，指定分区键，表之间会带上依赖关系这种...最后还是没走 PAX 啊，资源隔离这个问题没搞好

点个赞，谈到的问题基本上全都碰上了..
个人有几个小问题
1. 回到 AP 的场景，从文章里面看到的东西还是很多疑问，比如说楼上提到的 learner 转列存的...听起来很美好，但是 AP 追求的就是扫描性能，避免 shuffle，要有 co-located join，继续那一套标准的关系型数据模型行不通的，这个是怎么解决的呢，在建表的时候要额外带些信息？
2. 热点调度全球首创这个...Spanner 里面不是 PlacementDriver 也干这个活吗，是有什么很特殊的创新点吗？
3. 有的时候我会觉得 TiDB 的 Raft 这一层是不是做得太底了，Spanner 里面的 Paxos-group 在 Tablet 上面，粒度很大，这样一个是大部分时候都是走的 1PC，另外也不会出现几万数十万个 Raft-Group 弄得某个 KV 在处理这一块压力很大的情况
4. 其实实际使用的时候，资源浪费还是比较严重，很多业务不需要那么高的 HA，是不是也可以跟 Spanner 一样，搞 Witness 那种可选的部署类型，提升 Quorum 的速度？

当项目中不止 java 的时候就不该用了...比如混入了 groovy，不过大部分人吃不到这个亏..
仁者见仁智者见智吧，单纯自己玩的时候会用一下，但是团队合作会避免

@vjnjc 抱歉回复得晚了，最近比较忙..
对于存储引擎的选项来说，核心是从业务场景出发：
1. 数据应用层的类型到底是 OLTP （高频点查，明显的特征就是查询走索引，关心明细数据）还是 OLAP （指标分析类、海量数据聚合，关注扫描性能）
2. 冷热数据分离，数据量在持续增长，但如果其实有大量冷数据，没必要一直放在关系型数据库中，归档至 HIVE 也是不错的选择，即使临时碰到了需要查询的场景，不过是慢一些而已
3. 对可用性的要求是不是真的有那么高，其实 MySQL+MHA 的可用性也很高了，不是金融行业，挂个 30~60s 也能接受吧

下面再来结合谈谈 TiDB 本身：
1. TiDB 目前 OLAP 是不能看的，TiSpark 优势比起其他的传统 AP 没有啥优势，他们最近也在基于 Clickhouse 做新的一个 AP 引擎 TiFlash，不过稳定估计还是要过很长一段时间了....
2. 不考虑异地多 IDC 的情况，TiDB 的可用性并不一定比传统的 MySQL+MHA 好很多，如果 KV 层挂一个 node，其实也会有 60s （具体看配置，但肯定不会少于 15s ）左右的部分查询写入失败；
3. 小坑会比较多（一般都是参数配置相关的）...这个也没法具体展开讲，但核心就是碰到了问题网上资料会很少，你需要与官方去沟通，官方比较活跃的，但这个时间比起能在网上找到肯定长很多....所以最好要有相关的知识储备，它复杂的架构不是一般开发能 cover 住的，多达 700 多个监控指标...所以运维门槛比较高
4. 成本，这个就不多谈了
5. 很关注读写延迟就不用考虑用这个了

其实现在 sharding-proxy 的框架挺多的，tddl、zebra 等等，10 亿的数据量做 sharding 也还好
对于 NewSQL 除了强大的 scale-out 能力外，还有一个优势就是分布式事务
可以结合自身的实际情况尝尝鲜，先从非核心业务慢慢迁移和熟悉，后面自己心里应该就有答案了

这个数据量不建议上 TiDB，成本太高了，overkill
其实不涉及到复杂 SQL 偏 AP 的查询，纯粹的点查即使 MySQL 存储 4~5 亿行的数据也能良好工作
磁盘务必 SSD 这个观点很奇怪...这个是与你使用数据库的底层数据结构强相关的
我有负责过组内每天过 TB 吞吐和单表百亿行的场景到 TiDB，TiDB 有他的好，也有他的坏，我个人还是很喜欢这个数据库，也看好他，不说实话实说，目前这家的坑不少，不要盲目追求新的技术（ NewSQL ），适合自己最好

1.选 he 举 xie 完并不能保证 follower 和 leader commit logs 一致，保证的是如果某个日志条目在某个 term 中已经被提交，那么这个条目必然出现在更大 term 的所有 leader 中
2. 读必须走 leader，最原始的 logRead 还需要落一次盘，indexRead 才可以不落盘，leaseRead 不用走 raft-roundtrip，但也还是需要读 leader。所以单 raft 读也无法 scale-out
3. multi-raft 可以做读写的 scale-out

@hilbertz 摆配置吧，TiDB 本来追求的就是吞吐不是 latency，还可以 scale-out

点赞，反馈的问题在 3.0 都解决了，TiFlash Beta 找个机会看看公司愿不愿意现在试一试，越做越好了👍

@zjsxwc 没错坑很多，泪目

楼上显然在误导人，大的公司都有比较完善的基础设施，可以提高写业务的效率，不用浪费精力去重复造轮子。这些基建的设计文档都是开放的，构建并维护他们的人的水平也是高于平均值的，你乐意学习的话，有数不清的开放资源和前辈能帮助你学习。螺丝钉怎么了，大公司的螺丝钉想当好还不是件容易的事情呢

神终端圣无线，你问问大爷软海屌丝的就不这么想了....

慎入游戏行业啊....

所以哪里强迫你使用了？没有任何的商品与服务？？？？

楼主这惊人的表达能力.....第一句话我是真的没看懂....