search

timestee / utterances-comments

0 stars 0 forks source link

Vitess、Kingshard调研、DBProxy、DataServer1.5性能对比 | Devcenter-Server #11

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

Vitess、Kingshard调研、DBProxy、DataServer1.5性能对比 | Devcenter-Server

一般来说，利用数据库中间件可以实现如下功能：

读写分离 分库分表 故障转移 动态配置 统计分析 SQL过滤 查询缓存

本文对比了DBProxy ,Vitess, DataServer1.5 和KingShard ，它们的主要特性如下图所示, 😃 是我们目前较为关注的特性。 …

https://devcenter.diandian.info/blog/2021/11/10/vitesskingshard%E8%B0%83%E7%A0%94dbproxydataserver1.5%E6%80%A7%E8%83%BD%E5%AF%B9%E6%AF%94/

timestee commented 2 years ago

Vitess的优势在于两段提交的事务支持，目前dbproxy, dataserver都不支持跨shared的事务，也建议在实际项目中少依赖于事务。

timestee commented 2 years ago

dataserver未来如果考虑事务支持，可以考虑独立支持，接入支持XA的一些三方工具如DTM：https://www.dtm.pub/practice/xa.html

renzihui commented 2 years ago

绝对不要考虑XA transaction。XA实现上的挑战超乎想象，很多号称支持XA的resource根本没有搞清楚XA，bug很多，支持不完全，更不用说XA对性能上带来的巨大冲击。(PS，我以前曾经就做和这个相关的工作，XA的最初规范就是就是当时的雇主以前提出来的)

解决类似的问题，可以参考一个 Saga distributed transactions pattern （google “saga pattern”）

具体问题也欢迎具体讨论，很多实际问题有简单的方法，我们以前用KevValue Store也有一样的情况，解决过一些相关的问题。

timestee commented 2 years ago

XA锁数据的时间的确很长，并发上不去，saga模式逻辑层要做的事儿就多一点了，这个具体是否引入还要再评估，目前Vitess的锁也是在不建议使用的范围内。不过从根儿上来说，能不引入分布式事务就不要引入，如果能从设计级别明确单个shard事务支持是最好的。