首页   注册   登录
 EmdeBoas 最近的时间轴更新

EmdeBoas

V2EX 第 207060 号会员,加入于 2016-12-22 11:12:03 +08:00
今日活跃度排名 4269
EmdeBoas 最近回复了
P8 都能在北京扎根了...为啥要回长沙...
18 天前
回复了 songhongxin 创建的主题 酷工作 [北京] 美团点评诚招后端研发工程师
@my2019edc 戾气太重了,美团开源的东西并不少,Cat,Zebra,Octo,mpvue 等等,反哺社区的我知道的也有 Doris、Kylin、TiDB 这些
21 天前
回复了 PingCAP 创建的主题 推广 势高,则围广: TiDB 的架构演进哲学
@winoros 嗯,不是说冲突,是猜着应该是要在标准 mysql protocol 上面做扩展了,比如指定哪些表需要列存,指定分区键,表之间会带上依赖关系这种...最后还是没走 PAX 啊,资源隔离这个问题没搞好
24 天前
回复了 PingCAP 创建的主题 推广 势高,则围广: TiDB 的架构演进哲学
点个赞,谈到的问题基本上全都碰上了..
个人有几个小问题
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 的速度?
47 天前
回复了 cmower 创建的主题 Java Lombok 到底应不应该使用?
当项目中不止 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 ),适合自己最好
94 天前
回复了 mggis0or1 创建的主题 程序员 实现 raft 的时候一些思考, 求 v 友印证下
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
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   880 人在线   最高记录 5043   ·   Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 9ms · UTC 21:59 · PVG 05:59 · LAX 14:59 · JFK 17:59
♥ Do have faith in what you're doing.
沪ICP备16043287号-1