aws mycat mysql_可否对比一下 TiDB 与 AWS Aurora ？

前一种认为性能瓶颈在存储，所以分库分表sharding就是解药。坏处就是sql处理引擎也要大改来算清楚要访问哪些地方的存储，毕竟不是KV。

后一种认为性能瓶颈在计算不在存储(存储慢？明明是你用来缓存的内存不够多～你敢说内存不够快么)，所以把计算节点和存储节点分开之后可以快乐的狂加计算节点来提升性能。好处就是只需要一个单机存储内核(计算节点)访问一个带多副本备份复制的分布式文件系统(存储节点)就搞定存储了。可以把RO计算节点看成内存缓存副本节点(注意进度是可能有滞后的)，使用者对各个RO的使用如果能做到各自热点集中就能最大的发挥这种架构的性能。

前者基本都是从无到有的写一个DB，毕竟改动量除了存储还有sql解析，例如Ti例如OB，我知道的例外是tdsql；后者一般就是修改现有DB 存储引擎的日志部分，让日志成为分布式通信的管道(每个计算节点内存中都有自己的管道读取游标)，只读计算节点的内存永远被binlog或者redolog的游标逼着修改。

前者想要达到100%兼容mysql简直就是不可能(但是可以100%的自主知识产权倒是真的)，tdsql在一些情况下性能也比原版mysql差很多(这一类方案在面对复杂sql和真正事务时性能都不咋的)；后者可以基于某个版本来做修改然后实现对某个mysql版本的100%兼容。

我从来不能理解前者号称也做到存储和计算分离到底是什么个概念，明明计算和存储有本质的耦合才做到扩容能提升性能的。。不过2者都能做到不把复杂大sql产生的临时表，临时文件放到分布式存储中而只存放在本地。

前者基本只能一切都自己研发(tdsql也又是一个特例，毕竟设计之初就已经定好了要能不断merge上游最新内核的目标)；而后者可以不断merge现有开源数据库的最新变更为自己所用，毕竟在原始版本上的修改量其实不大也很集中。所以老有人骂云服务商是吸血鬼。。

在超大规模数据集的存储和写入上，前者可以显示出来相当的性能优势，毕竟设计原则就是为这种场景优化和sharding的；而后者则会遇到瓶颈，写入节点内存可能开始吃紧(因为需要确保写入内容被每个计算节点内存缓存后才能落盘，所以RO太多之后RW可能会比较郁闷)，而单机缓存则可能越来越不足以覆盖热点数据(毕竟每一个计算节点都是准备着缓存所有数据的)。所以从不考虑成本的理论性能上限来讲，前者的天花板比后者要高出不少。

因为性能导致的扩容成本上，前者比后者要高出不少。毕竟前者可能因为性能问题而扩大存储集群，而后者则此时只需要找低存储配置的计算节点来做扩容(高性能存储的服务器比大内存的服务器普遍贵好多)，存储节点基本是固定副本数量。所以云服务商偏向后者我觉得可以理解。不过后者这种“增加一个RO实例”的扩容方式比较传统，做不到对用户完全透明，因为RO的进度会比RW慢，用户必须接受这个事实(也是传统认知)才能接受这种扩容(需要线性一致性时必须去读RW)，但这种不透明恰好对应“云”这种一分性能一分钱这种场景，比较好定价：前者不太好给用户解释清楚为什么10T的时候为了性能而扩容的成本会比1T的时候多出不少，毕竟用户心里也会有种你只需要给我扩cpu就能提升性能的意识。

扩容运维难度上来讲，前者多一种划分而带来一种需要维护一致性hash关系的热扩容，这并不简单，尤其是要处理好这个过程中可能发生的故障；后者则是传统的分布式复制过程。

总体来说，前一种替用户做的多，用户可以不怎么操心性能和容量以及一致性；后者替用户做的少，用户还是得手工在代码中去制定访问RO，并且要自己保证进度落后不要影响自己的业务，总之就好像还是在写传统的读写分离代码。前者因为做的多，导致只能做一个DB；后者因为做的少，同时支持mysql&PG 这些开源DB并不难。