上周日提到一个问题，就是在某个群里面说 POLARDB 不稳定，虽然我和阿里云仅仅客户的关系，或者连客户的关系都算不算，就算一个使用者，但本着实话实说，和不愿意一个好的产品被不公正的评论的因素，谈谈我们为什么在应用中，开始大量使用POLARDB 而不是 MYSQL ，并且作为数据库部门，我们也在尽力对适合的应用建议采用POLARDB FOR MYSQL 而不是MYSQL 。
在说这个问题之前，我们需要说明什么是POLARDB，POLARDB 本身是一个统称，是作为新一代计算和存储节点分离的阿里云原生数据库的统称，作为一个阿里主推的数据库，我这里的POLARDB 并不是指的以 POSTGRESQL 为上层数据处理引擎的POLARDB ，这里我们要说的POLARDB 是 以MYSQL为上层处理引擎的 POLARDB ，这里我们全称为 POLARDB FOR MYSQL .
所以以下的文字，均与POLARDB FOR MYSQL 有关，与POLARBB FOR POSTGRESQL ，或者 POLARDB FOR ORACLE，POLAR-X 均没有关系。
说到选择，其实有一个核心，一个产品的比另一个产品好，我们才能选择，并且他们之间还需要有雷同项,学习成本不能太高。
下面我从以下 5点来说明，为什么我们不选择MYSQL在某些应用，而是去使用了POLARDB FOR MYSQL。
1 灵活性：说到灵活性其实这里蕴含一个深刻的问题，节点的本身的伸缩性，和节点扩展的伸缩性。 这里我提出一个问题，无论是 RDS 产品还是自建的MYSQL 数据库，如果在业务突发性的需求中，我们并没有预估的情况下，我们多久才能建立起一个只读节点，或进行配置的提升，并且在业务高峰过去后，，我们怎么能在快速的收缩节点。
其实这里并没有一个可以准确说出到底需要多长时间的准确值，这与数据量有关，相信DBA 同学都能体会， 无论我是使用8.0 的CLONE 从库的方式，还是使用XTRABACKUP + 复制的方式，或者使用云厂商通用的做从节点的方式，这些都存在一个时间的问题。
那么这里的灵活性在 POLARDB FOR MYSQL 就可以体现出来优势，不会因为你的数据库是 1T 或者 2T 在进行从节点的复制中，而产生延迟或更长的时间才能获得从节点，数据量的大小本身和你产生从节点没有关系。
也就是说，POLARDB 在产生从节点的时候，他的产生的时间大致是固定的，具体的时间我们操作过的最快的时间在7分钟，一个崭新的节点就已经出现，并可以开始工作。最慢的一次也不到9分钟。
这是与POLARDB for mysql 的存储的设计理念有关，你的从节点的产生无非就是一个计算节点而已，你需要等待的时间，无非是REDO LOG 的复制和内存数据的加载。
在目前的商业环境中，变态的需求，在应用端可以快速扩展，通过DOCKER 或者其他的方式，但数据库作为有状态的服务，扩展节点是一件困难的事情，所以如果此时你经常被 变态的应用要求扩展数据库节点而困扰的情况下，POLARDB for mysql 是一个好的选择。
高效，快速，扩展性强，同时取消一个节点同样的容易。
2 数据恢复的粒度细
相信这个问题在应用中也会被提到，那个开发搞错了语句，修改了数据库导致大批不应该被修改的数据，被修改了，那么数据此时就需要恢复，当然我们可以有规范，守则，甚至我们在数据库上做一个 BACKUP的DATABASE，来先做预防，但完事都有万一，如果此时我们这些都没有的情况下，我们怎么回滚数据，或者说，我们怎么找回数据。
基于POLARDB 通过REDO LOG 进行数据复制的方式，以及备份的方式让POLARDB 基于时间，或事件进行恢复成为一个可以你自己调整的细粒度的事情，相对于通过BINLOG 来重做数据的方式，速度不是一个量级。所以在数据的恢复的速度上，POLARDB 也相对于 MYSQL 有很大的优势，在粒度上也是借用了REDO LOG 的事务等级的粒度。（当然还有一个POLARDB for mysql 的数据闪回功能，我们没有使用）
3 POLARDB 的中间件让读写分离不是笑话
POLARDB FOR MYSQL 并不是一个单纯的数据库产品，他是一个解决方案，一个一体化的解决方案，如果你使用了POLARDB 那么你一定是要强行使用他们的 PROXY ，当然这里的强制可不是贬义词，如果你是一个行家，你使用过POLARDB 就会懂得，如果 要比喻的话，这二者可以用 俞伯牙与钟子期来比拟。 如果在直白一点，没有代理的POLARDB 就如同一个没有方向盘的汽车。
这还是基于POLARDB REDO LOG 复制的原理和他可以通过代理快速界定从库中的数据是否与主库是一致的特性，并且这个判断的速度是非常快的，通过REDO LOG 中的LSN 符合MVCC 多版本控制技术，你的一条命令下去，他可以通过分析将你的SELECT 语句与其他事物无关判断后，并且在确认从库的数据与主库一致的情况下（当前事务），将从库作为你动态的读写分离中的 读请求的目的地。
所以开发根本不用关心你的数据复制是否有延迟，从库是否能读到数据，并且将读节点在整体系统中的性能分担到最强。所以MYSQL 如果是一个人在战斗，POLARDB 至少是同时两个人在战斗。
4 数据的安全性，不会丢失数据
在金融场景下，我们最忌讳的就是丢失数据，举例MYSQL 还是POSTGRESQL ，如果我的数据还没有复制到从节点，主节点就挂了，那么这段数据就丢失了，当然POSTGRESQL 有办法可以使用强同步，但MYSQL 在普通复制的情况下，能使用的是半同步，虽然包含同步二字，但还是有半，所以MYSQL 的普通应用中，数据可能会丢失一定是别的数据库攻击他的有利点。
POLARDB FOR MYSQL 本身的数据安全性，在两点保证
1 数据的三份写，也就是在存储的底层通过POLARFS 系统将我们的数据库的数据一次写三份，通过parallel raft 的方式将数据尽快的写入到磁盘，所以保证POLARDB 数据不丢失的，并不是通过网络传输的方式，而是通过底层存储的三分写的保证，所以数据写丢失就不存在。
2 在硬件上有相关的原子锁，保证数据写入的时候不会不顺序，写错误的发生大概率是不可能。（这点还需要研究）
所以POALRDB 从底层来规避了数据丢失的可能性，而放弃使用网络建立从节点的方式保证数据的不丢失。这是二者层次不一，这也是POLARDB 为什么能保证数据不丢失的保证。
5 成本的因素
基于存储包和计算包的方式在POLARDB 的推广，如果你的数据量小，在POLARDB 上是有成本的优势，并不是向大家想的，大型的数据库要使用POLARDB 的并行提高大型数据库的计算性能，其实从成本的因素，POALRDB 相对于同级的产品，在小微应用的成本低也是一个让我们选择的理由。
当然在另一个维度上，成本有会有变化。
所以基于上面的5个层面，POLARDB 的确符合现在一些商业的 “变态” 需求造就的应用，而让其他的一些数据库黯然失色。那么这个数据库有没有缺点，和人一样，任何数据库都不是万金油，但凭空说一个数据库不稳定，并且是听说，还在一个大群里面散播信息，这就需要另一些声音，或者说真实的使用者，大批量的使用者来说说这个问题。
当然这也有一些建议针对POLARDB 的产品
1 请让使用者或者想了解POLARDB 的DB 人员，尽快明白 POLARDB 的产品系列，什么是 POALRDB FOR MYSQL ,POLARDB FOR POSTGRESQL ,POLARDB FOR ORALE, 什么又是POLARDB-X 。相信弄清楚这些产品，和上层建筑的同学还是 少数，否则也不会有人在群里面说 POLARDB 是开源产品（部分是开源，大部分不是）， 造成POLARDB 系列产品阵列中，之间互相影响。
2 更多的开放性加入，OPEN 的展示，用户要的是真实，而不是一味的夸赞，或无可奉告，没有没有问题的产品，只有不识货的买主，和封闭的产品。所以真实的展示一个产品，应该拿出一个 OPEN的精神。
3 更好的服务，对POLARDB 产品系列是否有必要提供单独的服务体系，技术是一个拳头， 服务是一个让产品走的更远的基石。
此时如果你问我，POLARDB for mysql 是一个好的产品吗，作为他真实客户，我的回复也很简单，我不后悔选择了polardb for mysql， 至少现在不。
注：POLARDB for mysql 作为客户的我们，还有很多的东西没有用出来，如强力的并行，列式存储，OLAP + OLTP 的解决方案，以及有意思的代理在不同业务需求中的各种调配。
另也很乐意分享一些POALRDB for mysql 的经验，以及一些避坑，但必须是私下的，非公开的方式，毕竟现在是法制社会。
